Skip to main content

No Further Fast Reroute for SRv6 Service SID
draft-liu-bess-srv6-service-sid-nffrr-flag-02

Document Type Active Internet-Draft (individual)
Authors Yisong Liu , Changwang Lin , Mengxiao Chen , Yao Liu
Last updated 2024-10-21
Replaces draft-liu-bess-multihome-srv6-service-sid-flag
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-liu-bess-srv6-service-sid-nffrr-flag-02
BESS                                                         Yisong Liu
Internet Draft                                             China Mobile
Intended status: Standards Track                                 C. Lin
Expires: April 28, 2025                                         M. Chen
                                                   New H3C Technologies
                                                                 Y. Liu
                                                                    ZTE
                                                       October 21, 2024

               No Further Fast Reroute for SRv6 Service SID
               draft-liu-bess-srv6-service-sid-nffrr-flag-02

Abstract

   In some multihoming SRv6 L3VPN and EVPN scenarios, once fast reroute
   has taken place, a second fast reroute is undesirable and may cause
   looping. This document proposes a mechanism to prevent further fast
   reroutes by advertising No-Further-FRR flags for SRv6 Service SIDs
   in BGP messages.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 28, 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with

Liu, et al.             Expire April 28, 2025                 [Page 1]
Internet-Draft   SRv6 Service SID No-Further-FRR Flag     October 2024

   respect to this document.  Code Components extracted from this
   document must include Revised BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Revised BSD License.

Table of Contents

   1. Introduction...................................................2
      1.1. Requirements Language.....................................2
   2. Use Case.......................................................3
      2.1. SRv6 L3VPN Multihoming....................................3
      2.2. SRv6 EVPN Multihoming.....................................5
   3. Solution.......................................................5
      3.1. Consideration for EVPN Single-Active Mode.................7
   4. Extensions for BGP.............................................7
   5. Backward Compatibility.........................................8
   6. Security Considerations........................................8
   7. IANA Considerations............................................9
   8. References.....................................................9
      8.1. Normative References......................................9
   Authors' Addresses................................................9

1. Introduction

   [RFC9252] defines procedures and messages for SRv6-based BGP
   services, including Layer 3 Virtual Private Network (L3VPN),
   Ethernet VPN (EVPN), and Internet services. In some multihoming
   scenarios, two egress PEs may establish a backup path between them
   and use it as the protection of PE-CE link failure. Once fast
   reroute (FRR) has taken place, a second fast reroute is undesirable
   and may cause looping.

   This document defines the No-Further-FRR flag for SRv6 Service SIDs
   carried in BGP messages and proposes a mechanism using the No-
   Further-FRR flag to prevent further fast reroutes.

1.1. Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

liu, et al.            Expires April 28, 2025                 [Page 2]
Internet-Draft   SRv6 Service SID No-Further-FRR Flag     October 2024

2. Use Case

2.1. SRv6 L3VPN Multihoming

   In the multihoming SRv6 L3VPN scenarios, two egress PEs may
   establish a backup path between them and use it as the protection of
   PE-CE link failure.

   Take the network in Figure 1 as an example. When traffic goes from
   CE1 to CE2, it may be load-balanced between PE2 and PE3 or only
   forwarded to the main egress PE. If the link PE2-CE2 fails, PE2 can
   still forward the traffic for CE2 by sending it over the backup path
   to PE3 (and similarly for PE3 if link2 fails).

                          +-----+
                          | CE1 |
                          +-----+
                             |
                             |
                          +-----+
      ------------------- | PE1 |***************
         ^                +-----+               *
         |             /           \             *
         |           /               \            *
         |         P1                 P2           *
         |         .                   .       +------+
     SRv6 VPN      .      *************.*******|BGP-RR|
         |         .     *             .       +------+
         |         P3   *             P4           *
         |         |   *               |          *
         |         |  *                |         *
         v      +-----+   Backup    +-----+     *
      --------- | PE2 |#############| PE3 |*****
                +-----+    Path     +-----+
                       \           /
                         \       /
                          +-----+
                          | CE2 |
                          +-----+

                          Figure 1

   Examples of BGP routes advertised by PE2 and PE3 are as following:

liu, et al.            Expires April 28, 2025                 [Page 3]
Internet-Draft   SRv6 Service SID No-Further-FRR Flag     October 2024

      BGP Route by PE2:
        VPN Prefix of CE2:
          BGP Prefix SID Attr:
            SRv6 L3 Service TLV:
              SRv6 SID Information sub-TLV:
                SID: SID-2
                  Behavior: End.DT46

      BGP Route by PE3:
        VPN Prefix of CE2:
          BGP Prefix SID Attr:
            SRv6 L3 Service TLV:
              SRv6 SID Information sub-TLV:
                SID: SID-3
                  Behavior: End.DT46

   Examples of FIB entries for L3VPN service SID on PE2 and PE3 are as
   following:

      FIB on PE2:
        SID-2:
          Primary Next-hop: CE2
          Backup Next-hop: Service SRv6 SID-3

      FIB on PE3:
        SID-3:
          Primary Next-hop: CE2
          Backup Next-hop: Service SRv6 SID-2

   However, suppose CE2 is down. PE2 will think PE2-CE2 link is down
   and send traffic to PE3 over the backup path. PE3 will also think
   PE3-CE3 link is down and send the traffic back to PE2 over the
   backup path. So, traffic will loop between PE2 and PE3 until BGP
   convergence.

   The traffic forwarding when CE2 fails is as following:

liu, et al.            Expires April 28, 2025                 [Page 4]
Internet-Draft   SRv6 Service SID No-Further-FRR Flag     October 2024

      +======+=============+=======+==============+
      | Node | Packet      | Next  | Comment      |
      +======+=============+=======+==============+
      | PE1  | <SID-2> pkt | PE2   |              |
      +------+-------------+-------+--------------+
      | PE2  | pkt         | CE2   | PE2-CE2 down |
      +------+-------------+-------+--------------+
      | PE2  | <SID-3> pkt | PE3   | FRR          |
      +------+-------------+-------+--------------+
      | PE3  | pkt         | CE2   | PE3-CE2 down |
      +------+-------------+-------+--------------+
      | PE3  | <SID-3> pkt | PE2   | FRR          |
      +------+-------------+-------+--------------+
      | PE2  | --          | CE2   | PE2-CE2 down |
      +------+-------------+-------+--------------+
      | PE2  | <SID-3> pkt | PE3   | FRR          |
      +------+-------------+-------+--------------+
      | ...  |             |       | Loop!        |
      +------+-------------+-------+--------------+

2.2. SRv6 EVPN Multihoming

   The EVPN services include Designated Forwarder (DF) election
   procedure.

   In All-Active mode, all PEs are allowed to forward unicast traffic,
   which is similar with the L3VPN case in Section 2.1.

   In Single-Active mode, only DF is allowed to forward unicast
   traffic, and it requires additional considerations in FRR.

3. Solution

   Each egress PE advertises an additional SRv6 Service SID in BGP
   routes which is called No-Further-FRR SID.

   The owner of No-Further-FRR SID will not provide local FRR for it.
   When the next-hop of No-Further-FRR SID is down, like PE-CE link
   failure or CE node failure, the PE will drop packets rather than
   apply FRR.

   The No-Further-FRR SID can used by other PE as the protection of
   local PE-CE link failure, without worrying about the looping
   problem.

   To support backwards compatibility and BGP RR deployment, both the
   normal SRv6 Service SID and the No-Further-FRR SID MAY be advertised

liu, et al.            Expires April 28, 2025                 [Page 5]
Internet-Draft   SRv6 Service SID No-Further-FRR Flag     October 2024

   together. A No-Further-FRR flag is used to indicate the No-Further-
   FRR SID.

   Detailed BGP extensions will be described in Section 4.

   Still taking the network in Figure 1 as an example, the BGP routes
   advertised by PE2 and PE3 are as following:

      BGP Route by PE2:
        VPN Prefix of CE2:
          BGP Prefix SID Attr:
            SRv6 L3 Service TLV:
              SRv6 SID Information sub-TLV:
                SID: SID-21
                  Behavior: End.DT46(L3VPN) or End.DX2/End.DT2U(EVPN)
              SRv6 SID Information sub-TLV:
                SID: SID-22
                  Behavior: End.DT46(L3VPN) or End.DX2/End.DT2U(EVPN)
             Flag: No-Further-FRR

      BGP Route by PE3:
        VPN Prefix of CE2:
          BGP Prefix SID Attr:
            SRv6 L3 Service TLV:
              SRv6 SID Information sub-TLV:
                SID: SID-31
                  Behavior: End.DT46(L3VPN) or End.DX2/End.DT2U(EVPN)
              SRv6 SID Information sub-TLV:
                SID: SID-32
                  Behavior: End.DT46(L3VPN) or End.DX2/End.DT2U(EVPN)
             Flag: No-Further-FRR

   The FIB entries for L3VPN service SID on PE2 and PE3 are as
   following:

liu, et al.            Expires April 28, 2025                 [Page 6]
Internet-Draft   SRv6 Service SID No-Further-FRR Flag     October 2024

      FIB on PE2:
        SID-21:
          Primary Next-hop: CE2
          Backup Next-hop: Service SRv6 SID-32
        SID-22 (No-Further-FRR):
          Primary Next-hop: CE2

      FIB on PE3:
        SID-31:
          Primary Next-hop: CE2
          Backup Next-hop: Service SRv6 SID-22
        SID-32 (No-Further-FRR):
          Primary Next-hop: CE2

   After adopting the proposed solution, if CE fails, PE2 will think
   PE2-CE2 link is down and send traffic to PE3 by using the No-
   Further-FRR SID-32. PE3 will also think PE3-CE3 link is down, but
   PE3 will drop the packets rather than apply FRR.

   The traffic forwarding when CE2 fails is as following:

      +======+==============+=======+==============+
      | Node | Packet       | Next  | Comment      |
      +======+==============+=======+==============+
      | PE1  | <SID-21> pkt | PE2   |              |
      +------+--------------+-------+--------------+
      | PE2  | pkt          | CE2   | PE2-CE2 down |
      +------+--------------+-------+--------------+
      | PE2  | <SID-32> pkt | PE3   | FRR          |
      +------+--------------+-------+--------------+
      | PE3  | pkt          | CE2   | PE3-CE2 down |
      +------+--------------+-------+--------------+
      | PE3  | -            | -     | Drop         |
      +------+--------------+-------+--------------+

3.1. Consideration for EVPN Single-Active Mode

   The processing of the No-Further-FRR SID should apply an override to
   EVPN DF-Election and bypass the local blocking state on the AC,
   until EVPN control plane reconverges.

4. Extensions for BGP

   This document defines a new flag in the SRv6 Service SID Flags field
   of the SRv6 SID Information Sub-TLV [RFC9252]:

liu, et al.            Expires April 28, 2025                 [Page 7]
Internet-Draft   SRv6 Service SID No-Further-FRR Flag     October 2024

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SRv6 Service  |    SRv6 Service               |               |
   | Sub-TLV       |    Sub-TLV                    |               |
   | Type=1        |    Length                     |  RESERVED1    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SRv6 SID Value (16 octets)                                  //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Svc SID Flags |   SRv6 Endpoint Behavior      |   RESERVED2   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SRv6 Service Data Sub-Sub-TLVs                              //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Svc SID Flags:

      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |N|             |
     +-+-+-+-+-+-+-+-+

   o N-flag: No-Further-FRR flag. When set, the associated SID has no
      fast reroute protection.

   The new-defined flag can be used for the SRv6 Service SIDs of L3 and
   L2 services, such as End.DX4, End.DT4, End.DX6, End.DT6, End.DT46.
   End.DX2, End.DX2V, End.DT2U, etc.

5. Backward Compatibility

   According to [RFC9252],

   o Any unknown flags in the SRv6 Service SID Flags field MUST be
      ignored by the receiver.

   o When multiple SRv6 SID Information Sub-TLVs are present, the
      ingress PE SHOULD use the SRv6 SID from the first instance of the
      Sub-TLV.

   When the egress PE advertises multiple service SIDs, the normal
   service SID SHOULD be carried in the first instance of Sub-TLV. If
   there are some other PE routers not supporting the flag defined in
   this document, the egress PE MAY expect those routers to use the
   first SID and ignore the new-defined flag.

6. Security Considerations

   TBD.

liu, et al.            Expires April 28, 2025                 [Page 8]
Internet-Draft   SRv6 Service SID No-Further-FRR Flag     October 2024

7. IANA Considerations

   This document defines the following bit in the SRv6 Service SID
   Flags field of SRv6 SID Information Sub-TLV:

   TLV Code Point    Value
   --------------------------------------------------------
   TBD               N-flag

8. References

8.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
             2119 Key Words", BCP 14, RFC 8174, May 2017

   [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
             B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
             Based on Segment Routing over IPv6 (SRv6)", RFC 9252, DOI
             10.17487/RFC9252, July 2022, <https://www.rfc-
             editor.org/info/rfc9252>.

Authors' Addresses

   Yisong Liu
   China Mobile
   China
   Email: liuyisong@chinamobile.com

   Changwang Lin
   New H3C Technologies
   China
   Email: linchangwang.04414@h3c.com

   Mengxiao Chen
   New H3C Technologies
   China
   Email: chen.mengxiao@h3c.com

liu, et al.            Expires April 28, 2025                 [Page 9]
Internet-Draft   SRv6 Service SID No-Further-FRR Flag     October 2024

   Yao Liu
   ZTE
   China
   Email: liu.yao71@zte.com.cn

liu, et al.            Expires April 28, 2025                [Page 10]