Internet-Draft SRv6 Midpoint Protection February 2023
Chen, et al. Expires 12 August 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-chen-rtgwg-srv6-midpoint-protection-11
Published:
Intended Status:
Experimental
Expires:
Authors:
H. Chen
China Telecom
Z. Hu
Huawei Technologies
H. Chen
Futurewei
X. Geng
Huawei Technologies
Y. Liu
China Mobile
G. Mishra
Verizon Inc.

SRv6 Midpoint Protection

Abstract

The current local repair mechanism, e.g., TI-LFA, allows local repair actions on the direct neighbors of the failed node or link to temporarily route traffic to the destination. This mechanism does not work properly for SRv6 TE path after the failure happens in the destination point and IGP converges on the failure. This document defines midpoint protection for SRv6 TE path, which enables other nodes on the network to perform endpoint behaviors for the faulty node, update the IPv6 destination address to the next endpoint after the faulty node, and choose the next hop based on the new destination address.

Requirements Language

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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 12 August 2023.

Table of Contents

1. Introduction

The current local repair mechanism, e.g., Topology-Independent Loop-Free Alternate (TI-LFA) ([I-D.ietf-rtgwg-segment-routing-ti-lfa]), allows local repair actions on the direct neighbors of the failed node or link to temporarily route traffic to the destination. This mechanism does not work properly after the failure happens in the destination point and IGP converges on the failure.

In SRv6 TE, the IPv6 destination address (DA) in the outer IPv6 header could be the segment endpoint of the TE path rather than the destination of the TE path ([RFC8986]). After the endpoint fails and IGP converges, the packet with the failed endpoint as DA will be dropped since there is no route to this endpoint. The direct neighbors of the failed endpoint will not receive the packet. [I-D.ietf-spring-segment-protection-sr-te-paths] and [I-D.hu-spring-segment-routing-proxy-forwarding] propose midpoint protection for SR-MPLS TE path after IGP converges on the failure of a node along the path.

This document defines midpoint protection for SRv6 TE path after IGP converges on the failure of an endpoint on the path, which enables other nodes on the network to perform endpoint behaviors for the faulty node, update the IPv6 destination address to the next endpoint after the faulty node along the path, and choose the next hop based on the new destination address.

2. SRv6 Midpoint Protection Mechanism

When an endpoint node fails, the packet needs to bypass the failed endpoint node and be forwarded to the next endpoint node of the failed endpoint. Only endpoint node can process SRH, Therefore, only endpoint nodes can perform midpoint protection. There are two stages or time periods after an endpoint node fails. The first is the time period from the failure until the IGP converges on the failure. The second is the time period after the IGP converges on the failure.

During the first time period, the packet will be sent to the direct neighbor of the failed endpoint node. After detecting the failure of its interface to the failed endpoint node, the neighbor forwards the packets around the failed endpoint node. It changes the IPv6 destination address with the IPv6 address of the next endpoint node (or the last or other reasonable endpoint node) which could avoid going through the failed endpoint.

During the second time period. There is no route to the failed endpoint node after the IGP converges. When a previous hop node of the failed endpoint node finds out that there is no route to the IPv6 destination address (of the failed endpoint node), it changes the IPv6 destination address with the IPv6 address of the next endpoint node. Note that the previous hop node may not be the direct neighbor of the failed endpoint node.

3. SRv6 Midpoint Protection Example

The topology in Figure 1 illustrates an example of network topology with SRv6 enabled on each node.

                   +-----+           +-----+
                   |  N5 |-----------|  N6 |--------------+
                   +-----+           +-----+              |
                      |                 |                 |
                      |                 |                 |
                      |                 |                 |
 +-----+           +-----+           +-----+           +-----+
 |  N1 |-----------|  N2 |-----------|  N3 |-----------|  N4 |
 +-----+           +-----+           +-----+           +-----+

Figure 1: An example of network for midpoint protection

In this document, an end SID at node n with locator block B is represented as B:n. An end.x SID at node n towards node k with locator block B is represented as B:n:k. A SID list is represented as <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID to visit and S3 is the last SID to visit along the SRv6 TE path.

In the reference topology, suppose that Node N1 is an ingress node of SRv6 TE path going through N3 and N4. Node N1 steers a packet into a segment list < B:2, B:3, B:4>.

When node N3 fails, the packet needs to bypass the failed endpoint node and be forwarded to the next endpoint node after the failed endpoint in the TE path. When outbound interface failure happens in the Repair Node (which is not limited to the previous hop node of the failed endpoint node), it performs the proxy forwarding as follows:

During the first time period (i.e., before the IGP converges), node N2 (direct neighbor of N3) as a Repair Node forwards the packets around the failed endpoint N3 after detecting the failure of the outbound interface to the endpoint B:3. It changes the IPv6 destination address with the next sid B:4. N2 detects the failure of outbound interface to B:4 in the current route, it could use the normal Ti-LFA repair path to forward the packet, because it is not directly connected to the node N4. N2 encapsulates the packet with the segment list < B:5, B:6> as a repair path.

During the second time period (i.e., after the IGP converges), node N2 does not have any route to the failed endpoint N3 in its FIB. Node N2, as a Repair Node, forwards the packets around the failed endpoint N3 to the next endpoint node (e.g., N4) directly. There is no need to check whether the failed endpoint node is directly connected to N2. N2 changes the IPv6 destination address with the next sid B:4. Since IGP has completed convergence, it forwards packets directly based on the IGP SPF path.

4. SRv6 Midpoint Protection Behavior

A node N protecting the failure of an endpoint node on a SRv6 path may be one of the following types:

This section describes the behavior of each of these nodes as a repair node for the two time periods after the endpoint node fails.

4.1. Endpoint Node as Repair Node

When the Repair Node is an endpoint node, it provides fast protections for the failure through executing the following procedure after looking up the FIB for the updated DA.

     IF the primary outbound interface used to forward the packet failed
       IF NH = SRH && SL != 0 and
          the failed endpoint is directly connected to Repair Node THEN
         SL decreases; update the IPv6 DA with SRH[SL];
         FIB lookup on the updated DA;
         forward the packet according to the matched entry;
       ELSE
         forward the packet according to the backup nexthop;
     ELSE IF there is no FIB entry for forwarding the packet THEN
       IF NH = SRH && SL != 0 THEN
         SL decreases; update the IPv6 DA with SRH[SL];
         FIB lookup on the updated DA;
         forward the packet according to the matched entry;
       ELSE
         drop the packet;
     ELSE
       forward accordingly to the matched entry;

4.2. Endpoint x Node as Repair Node

When the Repair Node is an endpoint x node, it provides fast protections for the failure through executing the following procedure after updating DA.

     IF the layer-3 adjacency interface is down THEN
       FIB lookup on the updated DA;
       IF the primary interface used to forward the packet failed THEN
         IF NH = SRH && SL != 0 and
            the failed endpoint directly connected to Repair Node THEN
           SL decreases; update the IPv6 DA with SRH[SL];
           FIB lookup on the updated DA;
           forward the packet according to the matched entry;
         ELSE
           forward the packet according to the backup nexthop;
       ELSE IF there is no FIB entry for forwarding the packet THEN
         IF NH = SRH && SL != 0 THEN
           SL decreases; update the IPv6 DA with SRH[SL];
           FIB lookup on the updated DA;
           forward the packet according to the matched entry;
         ELSE
           drop the packet;
     ELSE
       forward accordingly to the matched entry;

5. Determining whether the Endpoint could Be Bypassed

SRv6 Midpoint Protection provides a mechanism to bypass a failed endpoint. But in some scenarios, some important functions may be implemented in the bypassed failed endpoints that should not be bypassed, such as firewall functionality or In-situ Flow Information Telemetry of a specified path. Therefore, a mechanism is needed to indicate whether an endpoint can be bypassed or not. [I-D.li-rtgwg-enhanced-ti-lfa] provides method to determine whether enable SRv6 midpoint protection or not by defining a "no bypass" flag for the SIDs in IGP.

6. Security Considerations

This section reviews security considerations related to SRv6 Midpoint protection processing discussed in this document. To ensure that the Repair node does not modify the SRH header Encapsulated by nodes outside the SRv6 Domain. Only the segment within the SRH is same domain as the repair node. So it is necessary to check the skipped segment have same block as repair node.

7. IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

8. References

8.1. Normative References

[I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over IPv6 Dataplane", Work in Progress, Internet-Draft, draft-ietf-lsr-isis-srv6-extensions-19, , <https://www.ietf.org/archive/id/draft-ietf-lsr-isis-srv6-extensions-19.txt>.
[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-09, , <https://www.ietf.org/archive/id/draft-ietf-lsr-ospfv3-srv6-extensions-09.txt>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC7356]
Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, , <https://www.rfc-editor.org/info/rfc7356>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[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, , <https://www.rfc-editor.org/info/rfc8986>.

8.2. Informative References

[I-D.hu-spring-segment-routing-proxy-forwarding]
Hu, Z., Chen, H., Yao, J., Bowers, C., Zhu, Y., and Y. Liu, "SR-TE Path Midpoint Restoration", Work in Progress, Internet-Draft, draft-hu-spring-segment-routing-proxy-forwarding-22, , <https://www.ietf.org/archive/id/draft-hu-spring-segment-routing-proxy-forwarding-22.txt>.
[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-09, , <https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-routing-ti-lfa-09.txt>.
[I-D.ietf-spring-segment-protection-sr-te-paths]
Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, "Segment Protection for SR-TE Paths", Work in Progress, Internet-Draft, draft-ietf-spring-segment-protection-sr-te-paths-03, , <https://www.ietf.org/archive/id/draft-ietf-spring-segment-protection-sr-te-paths-03.txt>.
[I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", Work in Progress, Internet-Draft, draft-ietf-spring-segment-routing-policy-22, , <https://www.ietf.org/archive/id/draft-ietf-spring-segment-routing-policy-22.txt>.
[I-D.li-rtgwg-enhanced-ti-lfa]
Li, C., Hu, Z., Zhu, Y., and S. Hegde, "Enhanced Topology Independent Loop-free Alternate Fast Re-route", Work in Progress, Internet-Draft, draft-li-rtgwg-enhanced-ti-lfa-07, , <https://www.ietf.org/archive/id/draft-li-rtgwg-enhanced-ti-lfa-07.txt>.
[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.", Work in Progress, Internet-Draft, draft-sivabalan-pce-binding-label-sid-07, , <https://www.ietf.org/archive/id/draft-sivabalan-pce-binding-label-sid-07.txt>.
[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, , <https://www.rfc-editor.org/info/rfc5462>.

Acknowledgments

The authors would like to thank Bruno Decraene, Jeff Tantsura, Ketan Talaulikar and Parag Kaneriya for their comments to this work.

Authors' Addresses

Huanan Chen
China Telecom
109, West Zhongshan Road, Tianhe District
Guangzhou
510000
China
Zhibo Hu
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Huaimo Chen
Futurewei
Boston, MA,
United States of America
Xuesong Geng
Huawei Technologies
Yisong Liu
China Mobile
Gyan S. Mishra
Verizon Inc.
13101 Columbia Pike
Silver Spring, MD 20904
United States of America
Phone: 301 502-1347