| Network Working Group | Z. Hu |
| Internet-Draft | Huawei Technologies |
| Intended status: Standards Track | H. Chen |
| Expires: May 1, 2020 | Futurewei |
| H. Chen | |
| China Telecom | |
| P. Wu | |
| Huawei Technologies | |
| October 29, 2019 |
SRv6 Path Egress Protection
draft-hu-rtgwg-srv6-egress-protection-03
This document describes protocol extensions for protecting the egress node of a Segment Routing for IPv6 (SRv6) path or tunnel.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
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 May 1, 2020.
Copyright (c) 2019 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 respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The fast protection of a transit node of a Segment Routing (SR) path or tunnel is described in [I-D.ietf-rtgwg-segment-routing-ti-lfa] and [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8400] specifies the fast protection of egress node(s) of an MPLS TE LSP tunnel including P2P TE LSP tunnel and P2MP TE LSP tunnel in details. However, these documents do not discuss the fast protection of the egress node of a Segment Routing for IPv6 (SRv6) path or tunnel.
This document fills that void and presents protocol extensions for the fast protection of the egress node of an SRv6 path or tunnel. Egress node and egress, fast protection and protection as well as SRv6 path and SRv6 tunnel will be used exchangeably below.
The following terminologies are used in this document.
Locator: A3:1::/64
******* ******* VPN SID: A3:1::B100
[PE1]-----[P1]-----[PE3]
/ | |& | \ PE3 Egress
/ | |& | \ CEx Customer Edge
[CE1] | |& | [CE2] Px Non-Provider Edge
\ | |& | / *** SR Path
\ | |& &&&&& | / &&& Backup Path
[PE2]-----[P2]-----[PE4]
Locator: A4:1::/64
VPN SID: A4:1::B100
Mirror SID: A4:1::3, protect A3:1::/64
Figure 1: Protecting SR Path Egress PE3
Figure 1 shows an example of protecting egress PE3 of a SR path, which is from ingress PE1 to egress PE3.
When PE3 fails, P1 detects the failure through BFD and forwards the packet to PE4 via the backup path. When PE4 receives the packet, it sends the packet to the same CE2.
In Figure 1, CE2 is 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 a VPN SID A4:1::B100. A mirror SID A4:1::3 is configured on PE4 for protecting PE3 with locator A3:1::/64.
After the mirror SID is configured on a local PE (e.g., PE4), when the local PE (e.g., BGP on the local PE) receives a prefix whose VPN SID belongs to a remote PE (e.g., PE3) with the locator that is protected by the local PE through mirror SID, the local PE (e.g., PE4) creates a mapping from the remote PE's (e.g., PE3's) VPN SID and the mirror SID to the local PE's (e.g., PE4's) VPN SID. The remote PE is protected by the local PE.
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 creates a mapping from remote PE3's VPN SID and the mirror SID (i.e., "A3:1::B100, A4:1::3") to local PE4's VPN SID (i.e., "A4:1::B100").
Node P1's pre-computed TI-LFA backup path for destination PE3 having locator A3:1::/64 is from P1 to PE4 having mirror SID A4:1::3. It is installed as a T.Insert transit behavior. 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.
When PE3 fails, node P1 protects PE3 through sending the packet to PE4 via the backup path pre-computed. P1 modifies the packet before sending it to PE4. The modified packet has destination PE4 with mirror SID A4:1::3, and SRH with PE3's VPN SID A3:1::B100 and the mirror SID A4:1::3 (i.e., "A3:1::B100, A4:1::3; SL=1").
When PE4 receives the packet, it forwards the packet to CE2 through executing END.M instruction according to the local VPN SID (i.e., A4:1::B100).
This section describes extensions to IS-IS and OSPF for advertising the information about SRv6 path egress protection.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | SRv6 Endpoint Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IS-IS SRv6 End.M SID sub-TLV
A new sub-TLV, called IS-IS SRv6 End.M SID sub-TLV, is defined. It is used in the SRv6 Locator TLV defined in [I-D.ietf-lsr-isis-srv6-extensions] to advertise SRv6 Segment Identifiers (SIDs) with END.M function for SRv6 path egress protection. The SRv6 End.M SIDs inherit the topology/algorithm from the parent locator. The format of the sub-TLV is illustrated below.
Two sub-TLVs are defined. One is the protected locators sub-TLV, and the other is the protected SIDs sub-TLV.
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Locator-Size | Locator (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IS-IS Protected Locators sub-TLV
A protected locators sub-TLV is used to carry the Locators to be protected by the SRv6 mirror SID. 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 (TBD3) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IS-IS Protected SIDs sub-TLV
A protected SIDs sub-TLV is used to carry the SIDs to be protected by the SRv6 mirror SID. 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 (TBD4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | SRv6 Endpoint Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: OSPF SRv6 End.M SID sub-TLV
Similarly, a new sub-TLV, called OSPF SRv6 End.M SID sub-TLV, is defined. It is used to advertise SRv6 Segment Identifiers (SIDs) with END.M function for SRv6 path egress protection. Its format is illustrated below.
Two sub-TLVs are defined. One is the protected locators sub-TLV, and the other is the protected SIDs sub-TLV.
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) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: OSPF Protected Locators sub-TLV
A protected locators sub-TLV is used to carry the Locators to be protected by the SRv6 mirror SID. 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 (TBD6) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (16 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: OSPF Protected SIDs sub-TLV
A protected SIDs sub-TLV is used to carry the SIDs to be protected by the SRv6 mirror SID. It has the following format.
End.M: Mirror protection
When N receives a packet destined to S and S is a local End.M SID,
N does:
IF NH=SRH and SL = 1 ;; Ref1
SL--
Map to a local VPN SID based on Mirror SID and SRH[SL] ;; Ref1
forward according to the local VPN SID ;; Ref2
ELSE
drop the packet
Figure 8: SRv6 Mirror SID Procedure
The "Endpoint with mirror protection to a VPN SID" function (End.M for short) is a variant of the End function. The End.M is used for SRv6 VPN egress protection. It is described below.
The extensions to OSPF and IS-IS described in this document should not cause extra security issues.
+==============+========================+===============+ | Sub-TLV Type | Sub-TLV Name | Reference | +==============+========================+===============+ | 8 | SRv6 End.M SID Sub-TLV | This document | +--------------+------------------------+---------------+
Under "Sub-TLVs for TLVs 27, 135, 235, 236 and 237 registry" [I-D.ietf-lsr-isis-srv6-extensions], IANA is requested to add the following new Sub-TLV:
Value Sub-Sub-TLV Name Definition ----- ----------------------- ------------- 0 Reserved 1 Protected Locators Sub-Sub-TLV This Document 2 Protected SIDs Sub-Sub-TLV 3-255 Unassigned
IANA is requested to create and maintain a new registry for sub-sub-TLVs of the SRv6 End.M SID Sub-TLV. The suggested registry name is [RFC5226].
Initial values for the registry are given below. The future assignments are to be made through IETF Review
+==============+========================+===============+ | Sub-TLV Type | Sub-TLV Name | Reference | +==============+========================+===============+ | 8 | SRv6 End.M SID Sub-TLV | This document | +--------------+------------------------+---------------+
Under registry "OSPFv3 Locator LSA Sub-TLVs" [I-D.li-ospf-ospfv3-srv6-extensions], IANA is requested to assign the following new Sub-TLV:
Value Sub-Sub-TLV Name Definition ----- ----------------------- ------------- 0 Reserved 1 Protected Locators Sub-Sub-TLV This Document 2 Protected SIDs Sub-Sub-TLV 3-65535 Unassigned
IANA is requested to create and maintain a new registry for sub-sub-TLVs of the SRv6 End.M SID Sub-TLV. The suggested registry name is [RFC5226].
Initial values for the registry are given below. The future assignments are to be made through IETF Review
The authors would like to thank Peter Psenak, Bruno Decraene and Jeff Tantsura for their comments to this work.
| [I-D.hu-spring-segment-routing-proxy-forwarding] | Hu, Z., Chen, H., Yao, J., Bowers, C. and Y. Zhu, "SR-TE Path Midpoint Protection", Internet-Draft draft-hu-spring-segment-routing-proxy-forwarding-06, October 2019. |
| [I-D.ietf-isis-segment-routing-extensions] | Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H. and B. Decraene, "IS-IS Extensions for Segment Routing", Internet-Draft draft-ietf-isis-segment-routing-extensions-25, May 2019. |
| [I-D.ietf-lsr-isis-srv6-extensions] | Psenak, P., Filsfils, C., Bashandy, A., Decraene, B. and Z. Hu, "IS-IS Extension to Support Segment Routing over IPv6 Dataplane", Internet-Draft draft-ietf-lsr-isis-srv6-extensions-03, October 2019. |
| [I-D.ietf-ospf-segment-routing-extensions] | Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W. and J. Tantsura, "OSPF Extensions for Segment Routing", Internet-Draft draft-ietf-ospf-segment-routing-extensions-27, December 2018. |
| [I-D.li-ospf-ospfv3-srv6-extensions] | Li, Z., Hu, Z., Cheng, D., Talaulikar, K. and P. Psenak, "OSPFv3 Extensions for SRv6", Internet-Draft draft-li-ospf-ospfv3-srv6-extensions-05, August 2019. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7356] | Ginsberg, L., Previdi, S. and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014. |
| [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. |
| [I-D.hegde-spring-node-protection-for-sr-te-paths] | Hegde, S., Bowers, C., Litkowski, S., Xu, X. and F. Xu, "Node Protection for SR-TE Paths", Internet-Draft draft-hegde-spring-node-protection-for-sr-te-paths-05, July 2019. |
| [I-D.ietf-rtgwg-segment-routing-ti-lfa] | Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Francois, P., daniel.voyer@bell.ca, d., Clad, F. and P. Camarillo, "Topology Independent Fast Reroute using Segment Routing", Internet-Draft draft-ietf-rtgwg-segment-routing-ti-lfa-01, March 2019. |
| [I-D.ietf-spring-segment-routing-policy] | Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A. and P. Mattes, "Segment Routing Policy Architecture", Internet-Draft draft-ietf-spring-segment-routing-policy-03, May 2019. |
| [I-D.sivabalan-pce-binding-label-sid] | Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., Previdi, S. and C. Li, "Carrying Binding Label/Segment-ID in PCE-based Networks.", Internet-Draft draft-sivabalan-pce-binding-label-sid-07, July 2019. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008. |
| [RFC5462] | Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009. |