Internet DRAFT - draft-gong-spring-ping-path-consistency-over-srv6

draft-gong-spring-ping-path-consistency-over-srv6



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                         .
       .  <P-Flag=1, PathSegment, Segment List>        .
       .                                               .
       +-----------------------------------------------+
       |                                               |
       .  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                                .
       .  <Segment List>                                      .
       .                                                      .
       +------------------------------------------------------+
       |                                                      |
       . 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, <https://www.rfc-
             editor.org/info/rfc2119>.

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





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, <https://www.rfc-editor.org/info/rfc8402>.

   [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,
             <https://www.rfc-editor.org/info/rfc8754>.

   [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, <https://www.rfc-
             editor.org/info/rfc8986>.

































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]