Network Working Group Y. Liu Internet Draft China Mobile Intended status: Informational C. Lin Expires: August 21, 2024 M. Chen New H3C Technologies February 23, 2024 Path-aware Remote Protection Framework draft-liu-rtgwg-path-aware-remote-protection-00 Abstract This document describes the framework of path-aware remote protection. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 21, 2024. 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 (http://trustee.ietf.org/license-info) in effect on the date of Liu, et al. Expire August 21, 2024 [Page 1] Internet-Draft Path-aware Remote Protection February 2024 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. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 2. Use Case.......................................................3 2.1. Spine-leaf Network........................................3 2.2. Dragonfly Network.........................................4 3. Framework......................................................5 3.1. Path-Aware Forwarding Plane...............................5 3.2. Path-Aware Routing Plane..................................6 3.3. Remote Fault Detection....................................7 4. Security Considerations........................................7 5. IANA Considerations............................................7 6. References.....................................................7 6.1. Normative References......................................7 6.2. Informational References..................................7 Authors' Addresses................................................8 1. Introduction Current IP network protection mechanisms can be mainly divided into local protection and end-to-end protection. Local protection technologies, such as ECMP, LFA [RFC5714], and TI-LFA [I-D.ietf- rtgwg-segment-routing-ti-lfa], can only perceive local faults and perform fast reroute. End-to-end protection technologies are usually targeted at end-to-end TE paths, where the head-end detects TE path faults and performs rapid switchover. There is no mechanism to quickly detect remote faults for non-TE paths and invoke repairs. In addition, local protection such as TI- LFA technology relies on IGP deployment. For certain networks, current protection mechanisms may not meet the requirements. A typical scenario is the Spine-Leaf network, such as the AI-DC network, which is usually a two-layer architecture. Detecting remote faults and invoking fast repairs can provide protection against link or node failure and reduce the disruption time. This paper proposes a path-aware remote protection mechanism and describes its framework. Liu, et al. Expires August 21, 2024 [Page 2] Internet-Draft Path-aware Remote Protection February 2024 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. 2. Use Case 2.1. Spine-leaf Network +--+ +--+ Spine |R1| |R2| +--+ +--+ | \ /| | \ / | | \/ | | /\ X <- Fault | / \ | | / \| +--+ +--+ Leaf |R3| |R4| +--+ +--+ ^ | | v Source Destination Figure 1 In the network shown in Figure 1, assuming that the R2-R4 link fails, R3 will continue to send traffic to both R1 and R2, and half of the traffic will be dropped by R2. It is not until R2 sends BGP withdrawn routes to R3 and the control plane converges that the traffic is fully restored. The convergence speed would be slow when there is a large number of BGP routes. In some Spine-leaf networks, such as DC networks, only the BGP protocol is deployed without IGP, and thus TI-LFA cannot be applied. On the other hand, if TI-LFA is used, the traffic path during the protection period will be R3->R2->R3->R1->R4, which additionally increases the traffic in the direction of R2->R3 and may cause congestion. The objective of path-aware remote protection is for R3 to detect R2-R4 link failure and then adjust ECMP quickly. Liu, et al. Expires August 21, 2024 [Page 3] Internet-Draft Path-aware Remote Protection February 2024 2.2. Dragonfly Network Source | v +---------+ | | | Group 1 |------------+ | | | +---------+ | | +---------+ | | | X<- Fault | Group 3 | | | | | +---------+ +---------+ | | | | | Group 2 |------------+ | | +---------+ | v Destination Figure 2 In the network shown in Figure 1, the primary path for the traffic is from Group 1 to Group 2, while the backup path detours from Group1 through Group3 and then to Group2. The objective of path-aware remote protection is for the routers in Group 1 to detect the link failure between Group 1 and Group 2 and then invoke the backup path quickly. Liu, et al. Expires August 21, 2024 [Page 4] Internet-Draft Path-aware Remote Protection February 2024 3. Framework +-------------+ |Routing Plane| +-------------+ | | Path Info v +----------------+ |Forwarding Plane| +----------------+ ^ | Element Failure in Path | +----------------------+ |Remote Fault Detection| +----------------------+ Figure 3 The framework of path-aware remote protection is shown in Figure 3. On the routing plane, the route calculation is not limited to the next hop, but requires path awareness. And then the path information is downloaded to the forwarding plane. When a fault occurs in any component along the path, it is required to quickly detect the fault and invoke repairs. 3.1. Path-Aware Forwarding Plane Figure 4 shows the forwarding entries for ECMP next-hops. When detecting any failure in the path, the corresponding next-hop will be removed from ECMP immediately. Liu, et al. Expires August 21, 2024 [Page 5] Internet-Draft Path-aware Remote Protection February 2024 +------+ +---------------+ |Prefix|---+-->|Next-hop: to R1| +------+ | +---------------+ | | +----------------+ | +---------->|Path: R3->R1->R4| | +----------------+ | +---------------+ +-->|Next-hop: to R2| +---------------+ | +----------------+ +---------->|Path: R3->R2->R4| +----------------+ Figure 4 Figure 5 shows the forwarding entries for primary and backup next- hops. When detecting any failure in the path related with the primary next-hop, the traffic next-hop will be invoked immediately. +------+ +-----------------------+ |Prefix|---+-->|Primary Next-hop: to G2| +------+ | +-----------------------+ | | +------------+ | +---------->|Path: G1->R2| | +------------+ | +----------------------+ +-->|Backup Next-hop: to G3| +----------------------+ | +----------------+ +---------->|Path: G1->G3->G2| +----------------+ Figure 5 3.2. Path-Aware Routing Plane When calculating routes, the path is perceived and the path information is added into the next hop. It may be achieved through routing protocol extensions. For example, in figure 1, when R2 advertises R4's routes to R3 through BGP, it carries the router-id of R4, and R3 adds R4 into the path information when calculating those received routes. For another example, IGP can easily get the path information during the SPF calculation. The detailed mechanisms will not be included in this document. Liu, et al. Expires August 21, 2024 [Page 6] Internet-Draft Path-aware Remote Protection February 2024 3.3. Remote Fault Detection The failure of the components in the path associated with the next hop should be detected, and then rapid repairs are invoked. It may be achieved through the use of non-routing protocol announcements by neighbors. For example, in Figure 1, R2 can notify R3 of the R2-R4 failure using UDP-based protocol or Ethernet LLC. It may also be achieved through a traffic-based mechanism. For example, when the traffic packets are dropped, a notification is triggered and is sent to neighbors in the direction of the incoming traffic. The detailed mechanisms will not be included in this document. 4. Security Considerations TBD. 5. IANA Considerations TBD. 6. References 6.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 6.2. Informational References [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, . [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", draft-ietf-rtgwg-segment-routing-ti-lfa-13 (work in progress), January 2024. Liu, et al. Expires August 21, 2024 [Page 7] Internet-Draft Path-aware Remote Protection February 2024 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 August 21, 2024 [Page 8]