SRv6 Path Egress Protection

3.1. Mechanism

Figure 1 is used to explain the mechanism of SR path egress node and egress link protection.¶

            *******  *******   SIDa
        [PE1]-----[P1]-----[PEA]---[CE2]    PEA Egress
        / |        |&        | \   /        PEB Backup Egress
       /  |        |&        |  \ /         CEx Customer Edge
  [CE1]   |        |&        |   X          Px  Non-Provider Edge
       \  |        |&        |  / \         *** SR Path
        \ |        |& &&&&&  | /   \        &&& Backup Path
        [PE2]-----[P2]-----[PEB]---[CE3]
                        Mirror SID

    S01. If (Upper-Layer header type == 41(IPv6) ) {
    S02.    Remove the outer IPv6 header with all its extension headers
    S03.    Set the packet's associated FIB table to Tm
    S04.    Submit the packet to the egress IPv6 FIB lookup for
               transmission to the new destination
    S05. } Else {
    S06.    Process as per Section 4.1.1 of RFC8986
    S07. }

3.2. Example

Figure 2 shows an example of fast protecting egress node PE3 of an SR path, which is from ingress node PE1 to egress node PE3.¶

                                Locator: A3:1::/64
              *******  *******  VPN SID: A3:1::B100
          [PE1]-----[P1]-----[PE3]---[CE2]      PE3 Egress
          / |        |&        | \   /          PE4 Backup Egress
         /  |        |&        |  \ /           CEx Customer Edge
    [CE1]   |        |&        |   X            Px  Non-Provider Edge
         \  |        |&        |  / \           *** SR Path
          \ |        |& &&&&&  | /   \          &&& Backup Path
          [PE2]-----[P2]-----[PE4]---[CE3]
                                Locator: A4:1::/64
                                VPN SID: A4:1::B100
                             Mirror SID: A4:1::3, protect A3:1::/64

Desired Pathways in Figure 2:¶

Node P1's pre-computed backup path for PE3 is from P1 to PE4 via P2. In normal operations, after receiving a packet with destination PE3, P1 forwards the packet to PE3 according to its FIB. When PE3 receives the packet, it sends the packet to CE2.¶

When PE3 fails, P1 as PLR detects the failure through using a failure detection mechanism such as BFD and forwards the packet to PE4 via the backup path. When PE4 receives the packet, it sends the packet to the same CE2.¶

When P1's IGP converges on the failure of PE3, P1 as PLR needs to retain the route to PE3 for a period of time. Thus the backup path for PE3 will be used when the other nodes (such as PE1) still send the packet to PE3 via P1 since their IGPs do not converge on the failure.¶

In Figure 2, Both CE2 and CE3 are dual home to PE3 and PE4. PE3 has a locator A3:1::/64 and a VPN SID A3:1::B100. PE4 has a locator A4:1::/64 and VPN SID A4:1::B100. A Mirror SID A4:1::3 is configured on PE4 for protecting PE3 with locator A3:1::/64.¶

Steps in Creating the Pathways:¶

Step 1: Normal Pathway Set-up [PEB is PE4, PEA is PE3]¶

Step 2: Backup Pathway Set-up¶

Step 2a: PE4 (aka PEB) Announces to Protect PE3 (aka PEA)¶

After the configuration, PE4 advertises this information through an IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE3's locator and Mirror SID A4:1::3. Every node in the SR domain will receive this IGP LS, which indicates that PE4 wants to protect PE3 (indicated by PE3's locator) with Mirror SID A4:1::3.¶

Step 2b: PE4 (aka PEB) Gets Forwarding Behavior of PE3 (aka PEA)¶

When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs to PE3 that is protected by PE4 through Mirror SID A4:1::3, it finds PE4's VPN SID corresponding to PE3's VPN SID. For example, local PE4 has Prefix 1.1.1.1 with VPN SID A4:1::B100, when PE4 receives prefix 1.1.1.1 with remote PE3's VPN SID A3:1::B100, it knows that they are for the same VPN.¶

The forwarding behaviors for these two VPN SIDs are the same from function's point of view. If the behavior for PE3's VPN SID in PE3 forwards the packet with it to CE2, then the behavior for PE4's VPN SID in PE4 forwards the packet to the same CE2; and vice versa.¶

Step 2c: PE4 (aka PEB) Creates FIB for PE3 (aka PEA)¶

PE4 creates a forwarding entry for PE3's VPN SID A3:1::B100 in the FIB table identified by Mirror SID A4:1::3 according to the forwarding behavior for PE4's VPN SID A4:1::B100.¶

Step 2d: P1 Prepares to Protect PE3 (aka PEA) by PE4 (aka PEB)¶

Node P1's pre-computed backup path for destination PE3 is from P1 to PE4 having mirror SID A4:1::3. When P1 receives a packet destined to PE3's VPN SID A3:1::B100, in normal operations, it forwards the packet with source A1:1:: and destination PE3's VPN SID A3:1::B100 according to the FIB using the destination PE3's VPN SID A3:1::B100.¶

Step 3: Backup Path Is Engaged upon PE3 (aka PEA) Failure¶

Step 3a: P1 Detects PE3 (aka PEA) Failure via BFD¶

Step 3b: P1 Sends Packet with SIDa to Backup Egress PE4 (aka PEB)¶

When PE3 fails, P1 as PLR sends the packet to PE4 via the backup path pre-computed. P1 encapsulates the packet using H.Encaps before sending it to PE4.¶

Suppose that the packet received by P1 is represented by Pkt = (SA = A1:1::, DA = A3:1::B100)Pkt0, where DA = A3:1::B100 is PE3's VPN SID, and Pkt0 is the rest of the packet. The encapsulated packet Pkt' will be one of the following:¶

o

Pkt' = (T, Mirror SID A4:1::3) (A1:1::, A3:1::B100)Pkt0 if the LFA is the next hop node to PE4 along the shortest path to PE4; or (otherwise)¶

o

Pkt' = (T, S1)(Mirror SID A4:1::3, Sn, ..., S1; SL=n) (A1:1::, A3:1::B100)Pkt0.¶

where T is a Source Address, <S1, ..., Sn> is the TI-LFA Repair List to PE4 computed by P1.¶

Step 3c: PE4 (aka PEB) Decapsulates Packet and Forwards It¶

When PE4 receives the re-routed packet, it decapsulates the packet and forwards the decapsulated packet by executing the behavior of End.M for the Mirror SID that is associated with the IPv6 FIB table for PE3. The packet received by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID A3:1::B100)Pkt0.¶

PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the packet, removes this outer IPv6 header, and then processes the inner IPv6 packet (A1:1::, A3:1::B100)Pkt0. It finds the FIB table for PE3 using Mirror SID A4:1::3 as the context ID, gets the forwarding entry for PE3's VPN SID A3:1::B100 from the table, and forwards the packet to CE2 using the entry.¶

4.1. Extensions to IS-IS

A new sub-TLV, called IS-IS SRv6 Mirror SID sub-TLV, is defined. It is used in the SRv6 Locator TLV defined in [RFC9352] to advertise SRv6 Mirror SID and the locators of the nodes to be protected. The SRv6 Mirror SID inherit the topology/algorithm from the parent locator. The format of the sub-TLV is illustrated below.¶

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type (TBD1)   |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Reserved    |    SRv6 Endpoint Function     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         SID (16 octets)                       |
 :                                                               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         sub-sub-TLVs                          |
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

TBD1 (suggested value 8) is to be assigned by IANA.¶

Length:

1 octet. Its value MUST NOT be less than 23. 23 is 19 (i.e., the size of Reserved, SRv6 Endpoint Function and SID) plus 4 (i.e., the minimum size of a IS-IS protected locators sub-sub-TLV). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if the length is less than 23.¶

Reserved:

1 octet. This octet MUST be set to zero on transmit, and ignored on receipt.¶

SRv6 Endpoint Function:

2 octets. It MUST contain the endpoint function 74 for Mirror SID. The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if it does not contain the endpoint function 74.¶

SID:

16 octets. This field contains the SRv6 Mirror SID to be advertised. It MUST NOT be zero (0). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if it contains zero (0).¶

A protected locators sub-sub-TLV is defined and used to carry the Locators of the egress node to be protected by the SRv6 mirror SID. The IS-IS SRv6 Mirror SID sub-TLV MUST include one IS-IS protected locators sub-sub-TLV. It has the following format.¶

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type (TBD2)  |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   SID-Size    |         SID (variable)                        ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   SID-Size    |         SID (variable)                        ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

TBD2 (suggested value 1) is to be assigned by IANA.¶

Length:

1 octet. Its value MUST NOT be less than 2. The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if the length is less than 2.¶

Locator-Size:

1 octet. Number of bits in the Locator field, which MUST be from the range (1-128). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if the Loc-Size is outside this range.¶

Locator:

1-16 octets. This field encodes an SRv6 Locator of an egress node to be protected by the SRv6 mirror SID. The Locator is encoded in the minimal number of octets for the given number of bits. Trailing bits MUST be set to zero and ignored when received.¶

When node B advertises that B wants to protect node A with a Mirror SID through an LSP, the LSP MUST have an SRv6 Locator TLV containing an IS-IS SRv6 Mirror SID sub-TLV, which includes the Mirror SID and node A's locators in an IS-IS Protected locators sub-sub-TLV.¶

4.2. Extensions to OSPF

Similarly, a new sub-TLV, called OSPF Mirror SID sub-TLV, is defined. It is used in the SRv6 Locator TLV defined in [I-D.ietf-lsr-ospfv3-srv6-extensions] to advertise SRv6 Mirror SID and the locators of the nodes to be protected. Its format is illustrated below.¶

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type (TBD4)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |             Reserved          |    SRv6 Endpoint Function     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         SID (16 octets)                       |
 :                                                               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            sub-TLVs                           |
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

TBD4 (suggested value 8) is to be assigned by IANA.¶

Length:

2 octets. Its value MUST NOT be less than 26. 26 is 20 (i.e., the size of Reserved, SRv6 Endpoint Function and SID) plus 6 (i.e., the minimum size of a OSPF protected locators sub-TLV). The entire OSPF SRv6 Mirror SID sub-TLV MUST be ignored if the length is less than 26.¶

Reserved:

2 octets. It MUST be set to zero for transmission and ignored on reception.¶

SRv6 Endpoint Function:

2 octets. It MUST contain the endpoint function 74 for End.M SID. The entire OSPF SRv6 Mirror SID sub-TLV MUST be ignored if it does not contain the endpoint function 74.¶

SID:

16 octets. This field contains the SRv6 Mirror SID to be advertised. It MUST NOT be zero (0). The entire OSPF SRv6 Mirror SID sub-TLV MUST be ignored if it contains zero (0).¶

A protected locators sub-TLV is defined and used to carry the locators of the node to be protected by the SRv6 Mirror SID. The OSPF SRv6 Mirror SID sub-TLV MUST include one OSPF protected locators sub-TLV. It has the following format.¶

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type (TBD5)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Locator-Size  |           Locator (variable)                  ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Locator-Size  |           Locator (variable)                  ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:

TBD5 (suggested value 1) is to be assigned by IANA.¶

Length:

2 octets. Its value MUST NOT be less than 2. The entire OSPF SRv6 Mirror SID sub-TLV MUST be ignored if the Length is less than 2.¶

Locator-Size:

1 octet. Number of bits (1 - 128) in the Locator field. Number of bits in the Locator field, which MUST be from the range (1-128). The entire OSPF SRv6 Mirror SID sub-TLV MUST be ignored if the Loc-Size is outside this range.¶

Locator:

1-16 octets. This field encodes an SRv6 Locator of an egress node to be protected by the SRv6 mirror SID. The Locator is encoded in the minimal number of octets for the given number of bits. Trailing bits MUST be set to zero and ignored when received.¶

When node B advertises that B wants to protect node A with a Mirror SID through an LSA, the LSA MUST have an SRv6 Locator TLV containing an OSPF SRv6 Mirror SID sub-TLV, which includes the Mirror SID and node A's locators in an OSPF Protected Locators sub-TLV.¶

7.1. Normative References

[I-D.ietf-lsr-ospfv3-srv6-extensions]

Li, Z., Hu, Z., Talaulikar, K., and P. Psenak, "OSPFv3 Extensions for SRv6", Work in Progress, Internet-Draft, draft-ietf-lsr-ospfv3-srv6-extensions-15, 21 June 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospfv3-srv6-extensions-15>.

[ISO10589]

ISO, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, November 2002.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4552]

Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.

[RFC5304]

Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.

[RFC5310]

Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC5340]

Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.

[RFC7166]

Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, <https://www.rfc-editor.org/info/rfc7166>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8362]

Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.

[RFC8400]

Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, "Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June 2018, <https://www.rfc-editor.org/info/rfc8400>.

[RFC8402]

Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8667]

Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, <https://www.rfc-editor.org/info/rfc8667>.

[RFC8679]

Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., Michel, C., and H. Chen, "MPLS Egress Protection Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, <https://www.rfc-editor.org/info/rfc8679>.

[RFC8986]

Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

[RFC9256]

Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.

[RFC9352]

Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, February 2023, <https://www.rfc-editor.org/info/rfc9352>.

7.2. Informative References

[I-D.ietf-rtgwg-segment-routing-ti-lfa]

Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-11, 30 June 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-segment-routing-ti-lfa-11>.

[RFC3107]

Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, <https://www.rfc-editor.org/info/rfc3107>.

[RFC4364]

Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC5226]

Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-editor.org/info/rfc5226>.

[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>.