SPRING Working Group L. Gong Internet Draft China Mobile Intended status: Standards Track C. Lin Expires: July 6, 2024 Y. Qiu New H3C Technologies January 6, 2024 Ping Path Consistency over SRv6 draft-gong-spring-ping-path-consistency-over-srv6-01 Abstract In the SRv6 network, the headend node could use Ping (ICMPv6 Echo) to detect the connectivity of the SRv6 path to implement path switching. When a headend use Ping to detect the segment list/CPath of SRv6 Policy, the forward path of ICMPv6 Echo Request message is indicated by segment list, the reverse path of ICMPv6 Echo Reply message is via the shortest path from the destination node to the source as determined by routing. The forward path and reverse path of ICMPv6 message are likely inconsistent going through different intermediate nodes or links. This document describes how to ensure the consistency of the forward path and the reverse path when using ICMPv6 Echo messages to detect SRv6 Policy. 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 Gong, et al. Expire July, 2024 [Page 1] Internet-Draft SRv6 Ping Path Consistency January 2024 This Internet-Draft will expire on July 6 2024. Copyright Notice Copyright (c) 2023 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 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 ................................................ 3 1.1. Requirements Language .................................. 3 2. Requirement of Path Consistency for Ping .................... 4 3. Correlate Bidirectional Path Using Path Segment ............. 5 3.1. procedure of Ping Detection Initiator .................. 7 3.2. Procedure of Ping's destination Node ................... 8 4. IANA Considerations ........................................ 10 5. Security Considerations .................................... 10 6. References ................................................. 10 6.1. Normative References .................................. 10 Authors' Addresses ............................................ 12 Gong, et al. Expires July, 2024 [Page 2] Internet-Draft SRv6 Ping Path Consistency January 2024 1. Introduction Segment Routing (SR) allows a headend node to steer a packet flow along any path. Per-path states of Intermediate nodes are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. SR can be instantiated on the MPLS data plane (MPLS-SR) and the IPv6 data plane (SRv6). On the SRv6 data plane, a segment is encoded as an IPv6 address (SRv6 SID) [RFC8986], and an ordered list of segments is encoded as an ordered list of SRv6 SIDs in the SR header (SRH) [RFC8754]. In the SRv6 network, the headend node could use Ping (ICMPv6 Echo) to detect the connectivity of the SRv6 path to implement path switching. When a headend use Ping to detect the segment list/CPath of SRv6 Policy, the forward path of ICMPv6 Echo Request message is indicated by segment list, the reverse path of ICMPv6 Echo Reply message is via the shortest path from the destination node to the source as determined by routing. The forward path and reverse path of ICMPv6 message are likely inconsistent going through different intermediate nodes or links. The inconsistency impacts the detecting result. If the forward path is up and reverse path is down, then the ICMPV6 Echo Reply message will not be able to be sent to the source, and Ping detection will timeout. If there are multiple path (segment list) in a SRv6 policy between a headend (local system) node and a tailend (remote system) node, Ping detection instance will be created for each path. Each Ping detection instance uses corresponding path to send ICMPV6 Echo Request message, but the reverse path is identical. If the reverse path is down, all Ping detection instances will be down. Then the SRv6 policy is down. The transmission path of forward ICMPV6 Echo Request messages and reverse ICMPV6 Echo Reply messages for the same Ping detection instance should be consistent. This document describes how to ensure the consistency of the forward path and the reverse path when using ICMPV6 Echo messages to detect SRv6 policy. 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 Gong, et al. Expires July, 2024 [Page 3] Internet-Draft SRv6 Ping Path Consistency January 2024 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Requirement of Path Consistency for Ping Detecting the connectivity of SRv6 policy using Ping is usually based on segment list. Ping detection instance is created for each segment list and associated with the segment list. Referring to the topology in Figure 1, there are two paths between Node A and D, and All nodes allocate end.x Segments on SRv6 data plane or adjacency SIDs on SR-MPLS data plane. Node A and D are headend and tailend nodes of each other, and SRv6 policy is created on A and D respectively. SID-B1 SID-B2 SID-C1 SID-C2 +--------B-----------------C-----------+ SID-A1/ \ SID-D1 / \ A D \ / SID-A2\ SID-E1 SID-E2 /SID-D2 +-------------------E-------------------+ Figure 1 Assuming that the deployed SRv6 policy has one candidate path and each path has two segment lists. Node A: Node D: SR Policy A-D SR Policy D-A Candidate Path1 Candidate Path2 Segment list1-1 Segment list2-1 SID-A1, SID-B2, SID-C2 SID-D1, SID-C1, SID-B1 Segment list1-2 Segment list2-1 SID-A2, SID-E2 SID-D2, SID-E1 List1-1 and List2-1 correspond to a forward and reverse SR forwarding path between node A and node D. List2-1 and List2-2 also correspond to another forward and reverse forwarding path between node A and node D. Both Node A and Node D serve as head nodes and need to detect the connectivity of the segment list of a SRv6 policy. When node A is the Ping detection initiator, Ping detection instances for segment list1 and segment list2 will be created respectively. Node A uses the associated segment list to encapsulate IPv6 header and SRH of the ICMPV6 Echo Request messages. Gong, et al. Expires July, 2024 [Page 4] Internet-Draft SRv6 Ping Path Consistency January 2024 After Node D receives an ICMPV6 Echo Request message to its local address (or SID), the ICMPV6 Echo Reply message should be able to return along the same path to avoid the false detection of the Ping instance caused by the inconsistency of the forward and reverse paths. The ICMPV6 Echo Request messages associated with the segment list1-1 is forwarded to node D according to the segment list1-1 of node A. The corresponding ICMPV6 Echo Reply messages of node D need to be sent to node A according to the segment list2-1 of node D. Thus, the forward and reverse paths of ICMPV6 message are ensured to be consistent. 3. Correlate Bidirectional Path Using Path Segment This draft proposes a method to achieve consistency in the forward and reverse paths of Ping detection packets using path segment. A Path Segment is defined to identify an SR path. In SR for MPLS data plane (SR-MPLS), Path Segment is defined in [I-D.ietf-spring- mpls-path-segment]. In SR for IPv6 data plane (SRv6), Path Segment is defined in [I-D.ietf-spring-srv6-path-segment]. Path segments can be used to correlate the two unidirectional SR paths at both ends of the paths. [I-D.ietf-idr-sr-policy-path-segment] proposes an extension to BGP SR Policy distribute SR policies carrying Path Segment and bidirectional path information. Through this extension, when distributing SRv6 policy to the headend node, reverse path information and path segment of segment list can be carried together. Gong, et al. Expires July, 2024 [Page 5] Internet-Draft SRv6 Ping Path Consistency January 2024 Node A Node D SR Policy A-D SR Policy D-A Candidate Path1 Candidate Path2 Segment list1-1 Segment list2-1 SID-A1, SID-B2, SID-C2 SID-D1, SID-C1, SID-B1 Path Segment: SID-Path-1 Path Segment: SID-Path-2 Reverse Path Segment: Reverse Path Segment: SID-Path-2 SID-Path-1 Segment list1-2 Segment list2-2 SID-A2, SID-E2 SID-D2, SID-E1 Path Segment: SID-Path-3 Path Segment: SID-Path-4 Reverse Path Segment: Reverse Path Segment: SID-Path-4 SID-Path-3 In this way, on the headend node in both directions of the forward and reverse paths, the path segment of the paths in both directions can be obtained, and the paths in both directions use the same intermediate links. The headend node can use path segment in two directions to establish a mapping table. Using this mapping table, the headend node can get the reverse path through the path segment of the forward path. The mapping table of Node A and Node D is shown below: Node A: +-----------------+ +--------------------+ | Path Segment | |Reverse Path Segment| +-----------------+ +--------------------+ | SID-Path-1 |-+ | SID-Path-2 |--+ +-----------------+ | +--------------------+ | | SID-Path-3 | | | SID-Path-4 |--|-+ +-----------------+ | +--------------------+ | | | | | | | | +-----------------------+ | | | | | segment List | | | | | +-----------------------+ | | | +->|SID-A1, SID-B2, SID-C2 |<----+ | | +-----------------------+ | +-------------->|SID-A2, SID-E2 |<------+ +-----------------------+ Figure 2: Mapping Table on Node A Gong, et al. Expires July, 2024 [Page 6] Internet-Draft SRv6 Ping Path Consistency January 2024 Node D: +-----------------+ +--------------------+ | Path Segment | |Reverse Path Segment| +-----------------+ +--------------------+ | SID-Path-2 |-+ | SID-Path-1 |--+ +-----------------+ | +--------------------+ | | SID-Path-4 | | | SID-Path-3 |--|-+ +-----------------+ | +--------------------+ | | | | | | | | +-----------------------+ | | | | | segment List | | | | | +-----------------------+ | | | +->|SID-D1, SID-C1, SID-B1 |<----+ | | +-----------------------+ | +-------------->|SID-D2, SID-E1 |<------+ +-----------------------+ Figure 3: Mapping Table on Node D For instance, the Ping detection initiator is Node A in Figure 1, and the Ping detection instance is bounded with Segment List1-1 of Policy A-D. 3.1. procedure of Ping Detection Initiator When path segment is used, the encapsulation format of ICMPV6 Echo Request message from Node A to Node D is as follows: +-----------------------------------------------+ | IPv6 Header | . Source IP Address = Initiator's IPv6 Address . . Destination IP Address = SegmentList[SL] . . Next-Header = SRH (43) . . . +-----------------------------------------------+ | SRH as specified in RFC 8754 | . Next-Header = ICMPv6 . . . . . +-----------------------------------------------+ | | . ICMPv6 Echo Request . | | +-----------------------------------------------+ Figure 4: ICMPv6 Echo Request Message Format Node A Encapsulates the path segment of segment list1-1 in SRH and sets SRH.P-Flag. Gong, et al. Expires July, 2024 [Page 7] Internet-Draft SRv6 Ping Path Consistency January 2024 The ICMPv6 Echo Request message is encapsulated and forwarded as follows: A------------->B------------>C---------->D +-----------------+ +-----------------+ | SA=A's Ipv6Addr | | SA=A's Ipv6Addr | +-----------------+ +-----------------+ | DA=SID-B1 | | DA=D's ipv6Addr | +-----------------+ +-----------------+ | SL=2 | P-Flag=1 | | SL=0 | P-Flag=1 | +-----------------+ +-----------------+ | D's ipv6Addr | | D's ipv6Addr | +-----------------+ +-----------------+ | SID-C2 | | SID-C2 | +-----------------+ +-----------------+ | SID-B2 | | SID-B2 | +-----------------+ +-----------------+ | SID-A1 | | SID-A1 | +-----------------+ +-----------------+ | SID-Path-1 | | SID-Path-1 | +-----------------+ +-----------------+ | ICMPv6 Echo | | ICMPv6 Echo | | Request | | Request | +-----------------+ +-----------------+ Figure 5: Example of ICMPv6 Echo Request Message 3.2. Procedure of Ping's destination Node ICMPv6 Echo Request message is forwarded along the path A->B->C-D. While packet arrives at Node D, SRH.SL is 0 and the destination address is IPv6 address of Node D. Packet is delivered up to control plane. Control plane detects SRH.P-flag is set, extracts the path segment of the forward path from SRH, gets the path segment of the reverse path through the mapping table. Then use the segment list associated with path segment of the reverse path to encapsulate SRH of ICMPv6 Echo Reply message. The encapsulation format of ICMPv6 Echo Reply message is as follows: Gong, et al. Expires July, 2024 [Page 8] Internet-Draft SRv6 Ping Path Consistency January 2024 +------------------------------------------------------+ | IPv6 Header | . Source IP Address = Ping Destination's IPv6 Address . . Destination IP Address = SegmentList[SL] . . Next-Header = SRH (43) . . . +------------------------------------------------------+ | SRH as specified in RFC 8754 | . Next-Header = ICMPv6 . . . . . +------------------------------------------------------+ | | . ICMPv6 Echo Reply . | | +------------------------------------------------------+ Figure 6: ICMPv6 Echo Reply Message Format The ICMPv6 Echo Reply message is encapsulated and forwarded as follows: D------------->C------------>B---------->A +-----------------+ +-----------------+ | SA=D's IPv6Addr | | SA=D's IPv6Addr | +-----------------+ +-----------------+ | DA=SID-C1 | | DA=A's IPv6Addr | +-----------------+ +-----------------+ | SL=2 | P-Flag=0 | | SL=0 | P-Flag=0 | +-----------------+ +-----------------+ | A's ipv6Addr | | A's ipv6Addr | +-----------------+ +-----------------+ | SID-B1 | | SID-B1 | +-----------------+ +-----------------+ | SID-C1 | | SID-C1 | +-----------------+ +-----------------+ | SID-D1 | | SID-D1 | +-----------------+ +-----------------+ | ICMPv6 Echo | | ICMPv6 Echo | | Reply | | Reply | +-----------------+ +-----------------+ Figure 7: Example of ICMPv6 Echo Reply Message The ICMPv6 Echo Reply message will be forward along the path D->C- >B->A. In this way, the forward and reverse paths of ICMPV6 packets are guaranteed to be consistent. Gong, et al. Expires July, 2024 [Page 9] Internet-Draft SRv6 Ping Path Consistency January 2024 4. IANA Considerations This document has no IANA actions. 5. Security Considerations The security requirements and mechanisms described in [RFC8402] and [RFC8754] also apply to this document. This document does not introduce any new security consideration. 6. References 6.1. Normative References [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", draft-ietf- idr-segment-routing-te-policy-20 (work in progress), July 2022 [I-D.ietf-spring-mpls-path-segment] Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, "Path Segment in MPLS Based Segment Routing Network",draft-ietf-spring-mpls-path- segment-08 (work in progress), September 2022. [I-D.ietf-spring-srv6-path-segment] Li, C., Cheng, W., Chen, M., Dhody, D., and Zhu, Y., "Path Segment for SRv6 (Segment Routing in IPv6)", draft-ietf-spring-srv6-path-segment-06 (work in progress), May 2023. [I-D.ietf-idr-sr-policy-path-segment] Li, C., Li, Z., Yin, Y., Cheng, W., Talaulikar, K., "SR Policy Extensions for Path Segment and Bidirectional Path", draft-ietf-idr-sr-policy- path-segment-07(work in progress), February 2023. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Gong, et al. Expires July, 2024 [Page 10] Internet-Draft SRv6 Ping Path Consistency January 2024 [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, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [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 0.17487/RFC8986, February 2021, . Gong, et al. Expires July, 2024 [Page 11] Internet-Draft SRv6 Ping Path Consistency January 2024 Authors' Addresses Liyan Gong China Mobile China Email: gongliyan@chinamobile.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Yuanxiang Qiu New H3C Technologies China Email: qiuyuanxiang@h3c.com Gong, et al. Expires July, 2024 [Page 12]