[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
IPPM Working Group                                             S. Weng
Internet Draft                                                W. Cheng
Intended status: Informational                            China Mobile
Expires: Sep 3, 2022                                            C. Lin
                                                  New H3C Technologies
                                                         March 3, 2022



                      SRPM Path Consistency over SRv6
               draft-weng-ippm-srpm-path-consistency-over-srv6-00


Abstract

   Twamp can be used to measure the performance of end-to-end paths in
   networks. Stamp [rfc8762] and twamp light are more lightweight
   measurement methods. In the SRv6 network, it is also necessary to
   measure the performance of SRv6 policy. This document describes a
   method to measure srv6 policy through stamp and twamp light.

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 September 3 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors. All rights reserved.



Weng, et al.            Expire September, 2022                 [Page 1]


Internet-Draft          Srpm Path Consistecy                 March 2022


   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 ................................................ 2
      1.1. Requirements Language .................................. 3
      1.2. Terminology ............................................ 3
   2. Requirement for consistent path ............................. 4
   3. Correlate bidirectional path using Path Segment ............. 5
   4. STAMP/TWAMP light Procedure with Path segment ............... 7
      4.1. Stamp/twamp light Session-sender procedure ............. 7
      4.2. Stamp/twamp light Session-reflector procedure .......... 8
   5. IANA Considerations ........................................ 10
   6. Security Considerations .................................... 10
   7. References ................................................. 10
      7.1. Normative References .................................. 10
   Contributors .................................................. 12
   Authors' Addresses ............................................ 13

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 policy is used to
   forward messages, so the quality of SR policy, such as packet loss
   and delay, also needs to be measured.

   The Simple Two-Way Active Measurement Protocol (STAMP) provides
   capabilities for the measurement of various performance metrics in
   IP networks [RFC8762] without the use of a control channel to pre-
   signal session parameters. [RFC8972] defines optional extensions in
   the form of TLVs for STAMP.

   The STAMP test packets are transmitted along an IP path between a
   Session-Sender and a Session-Reflector to measure performance delay

Weng, et al.           Expires September, 2022                 [Page 2]


Internet-Draft          Srpm Path Consistecy                 March 2022


   and packet loss along that IP path.  It may be desired in SRv6
   networks that the consistent path (same set of links and nodes)
   between the Session-Sender and Session-Reflector is used for the
   STAMP test packets in both directions.

   [ietf-ippm-stamp-srpm] defines the Return Path TLV, Using Return
   Path TLV, The Session-Sender can request this in the test packet to
   the Session-Reflector.

   Twamp light is also widely deployed, and stamp supports interworking
   with twamp light. So there are four possible combinations to deploy
   stamp and twamp light:

   STAMP Session-Sender with STAMP Session-Reflector.

   STAMP Session-Sender with TWAMP Light Session-Reflector.

   TWAMP Light Session-Sender with STAMP Session-Reflector.

   TWAMP Light Session-Sender with TWAMP Light Session-Reflector.

   Twamp light does not support the TLV of stamp, so in order to meet
   various deployment combinations, this document proposes a method to
   realize the same path between Session-Sender and session-reflector
   using path segment, which is also applicable to all scenarios where
   twamp light and stamp are deployed.



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.

1.2. Terminology

   STAMP:      Simple Two-way Active Measurement Protocol

   TWAMP:      Two-Way Active Measurement Protocol

   PTP:        Precision Time Protocol

   SR:         Segment Routing



Weng, et al.           Expires September, 2022                 [Page 3]


Internet-Draft          Srpm Path Consistecy                 March 2022


2. Requirement for consistent path

   In the reference topology shown below, the procedure of stamp and
   twamp light is similar. The Session-Sender S1 initiates a test
   packet and the Session-Reflector R1 transmits a reply test packet.
   The reply test packet may be transmitted to the Session-Sender S1 on
   the consistent path (same set of links and nodes) or a different
   path in the reverse direction from the path taken towards the
   Session-Reflector R1.

                                    T1                T2
                                   /                   \
                          +-------+     Test Packet     +-------+
                          |       | - - - - - - - - - ->|       |
                          |   S1  |=====================|   R1  |
                          |       |<- - - - - - - - - - |       |
                          +-------+  Reply Test Packet  +-------+
                                   \                   /
                                    T4                T3
                      Session-Sender           Session-Reflector

                     Figure 1: reference topology1


   By recording the time stamp in the test packet, the delay of one-way
   and two-way path can be measured. In the interaction process of a
   test, the sender inserts the sending timestamp T1 into the test
   packet. The reflector records the receiving timestamp T2 when
   receiving the request message. Then reflector creates a reply packet
   and inserts T1, T2 and the sending timestamp T3 of the reply packet
   into the reply packet. Finally the sender receives the reply packet
   and records the receiving timestamp T4.

   In this way, the sender gets four timestamps. Bidirectional delay
   can be obtained through t4-t1. If the one-way delay is calculated
   through t2-t1, PTP is required to be deployed between sender and
   reflector to ensure high-precision time synchronization, which is
   not easy to achieve for existing networks.

   Therefore, if the test packets in both directions can be guaranteed
   to pass along the consistent path, the two-way delay can be obtained
   by T4-T1, minus the time of processing packet on the reflector
   calculated by T3-T2, and the final data is the sum of the delays in
   two directions of transmitting packets along the consistent path.





Weng, et al.           Expires September, 2022                 [Page 4]


Internet-Draft          Srpm Path Consistecy                 March 2022


3. Correlate bidirectional path using Path Segment

   A Path Segment is defined to identify an SR path in [draft-ietf-
   spring-srv6-path-segment]. SRv6 Path segments can be used to
   correlate the two unidirectional SRv6 paths at both ends of the
   path.

   [draft-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, reverse path information and path segment of segment list
   can be carried together.

                    SID-B1  SID-B2     SID-C1   SID-C2
                 +--------B-----------------C-----------+
          SID-A1/                                         \ SID-D1
               /                                           \
              A                                             D
               \                                           /SID-D2
         SID-A2\           SID-E1      SID-E2            /
                 +-------------------E-------------------+
                     Figure 2: reference topology2


   In this way, on the headend 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 link.

   Refer to the reference topology2. There are two paths between NodeA
   and NodeD, and All nodes allocate end.x Segments.

   SRv6 policy is distributed to NodeA and NodeD respectively as the
   headend to build symmetrical two-way paths. SRv6 policy includes a
   candidate path, which contains two segment lists.

   Each segment list contains both the corresponding path segment and
   the reverse path segment of the reverse path:

    NodeA                         NodeD

     SRv6 Policy A-D                     SRv6 Policy D-A
       Candidate Path1                    Candidate Path1
        Segment list1                     Segment list1
         SID-A1, SID-B2, SID-C2            SID-D1, SID-C1, SID-B1
         Path Segment: SID-Path-A1         Path Segment: SID-Path-D1

Weng, et al.           Expires September, 2022                 [Page 5]


Internet-Draft          Srpm Path Consistecy                 March 2022


         Reverse Path Segment:             Reverse Path Segment:
            SID-Path-D1                         SID-Path-A1
        Segment list2                     Segment list2
         SID-A2, SID-E2                    SID-D2, SID-E1
         Path Segment: SID-Path-A2         Path Segment: SID-Path-D2
         Reverse Path Segment:             Reverse Path Segment:
             SID-Path-D2                        SID-Path-A2


   The headend can use path segment in two directions to establish a
   mapping table. Using this mapping table, the headend can index the
   reverse path through the path segment of the forward path.

   NodeA:
            +-----------------+          +--------------------+
            |  Path Segment   |          |Reverse Path Segment|
            +-----------------+          +--------------------+
            | SID-Path-A1     |-+        | SID-Path-D1        |--+
            +-----------------+ |        +--------------------+  |
            | SID-Path-A2     | |        | SID-Path-D2        |--|-+
            +-----------------+ |        +--------------------+  | |
                   |            |                                | |
                   |            |  +-----------------------+     | |
                   |            |  | segment List          |     | |
                   |            |  +-----------------------+     | |
                   |            +->|SID-A1, SID-B2, SID-C2 |<----+ |
                   |               +-----------------------+       |
                   +-------------->|SID-A2, SID-E2         |<------+
                                   +-----------------------+

   NodeD:
            +-----------------+          +--------------------+
            |  Path Segment   |          |Reverse Path Segment|
            +-----------------+          +--------------------+
            | SID-Path-D1     |-+        | SID-Path-A1        |--+
            +-----------------+ |        +--------------------+  |
            | SID-Path-D2     | |        | SID-Path-A2        |--|-+
            +-----------------+ |        +--------------------+  | |
                   |            |                                | |
                   |            |  +-----------------------+     | |
                   |            |  | segment List          |     | |
                   |            |  +-----------------------+     | |
                   |            +->|SID-D1, SID-C1, SID-B1 |<----+ |
                   |               +-----------------------+       |
                   +-------------->|SID-D2, SID-E1         |<------+
                                   +-----------------------+
                     Figure 3: mapping table


Weng, et al.           Expires September, 2022                 [Page 6]


Internet-Draft          Srpm Path Consistecy                 March 2022


4. STAMP/TWAMP light Procedure with Path segment

   This document proposes that the test packets in the two directions
   of stamp/twamp light are transmitted along the consistent path
   through path segment.

   Twamp light does not need to parse the TLV of stamp. Neither stamp
   nor twamp light needs to modify the packet structure. Using SRH to
   carry path segment, stamp and twamp light need to add some relevant
   adaptation processing to meet the requirement.

4.1. Stamp/twamp light Session-sender procedure

   For instance, the session-sender is Node A in Figure 2, and the
   session is bounded with Segment List1 of Policy A-D. The test packet
   is as follow:

       +-----------------------------------------------------------+
       | IPv6 Header                                               |
       .  Source IP Address = Session-Sender IPv6 Address          .
       .  Destination IP Address = SegmentList[SL]                 .
       .  Next-Header = SRH (43)                                   .
       .                                                           .
       +-----------------------------------------------------------+
       | SRH as specified in RFC 8754                              |
       .  Next-Header = IPv6                                       .
       .  <PathSegment, Segment List>                              .
       .                                                           .
       +-----------------------------------------------------------+
       | IPv6 Header                                               |
       .  Source IP Address = Session-Sender IPv6 Address          .
       .  Destination IP Address = Session-Reflector IPv6 Address  .
       .  Next-Header = UDP                                        .
       .                                                           .
       +-----------------------------------------------------------+
       | UDP Header                                                |
       .                                                           .
       +-----------------------------------------------------------+
       | Payload                                                   |
        .                                                          .
       +-----------------------------------------------------------+
               Figure 4: Encapsulation format of test packet


   NodeA Encapsulates the path segment of segment list1 in SRH, and set
   SRH.P-Flag.


Weng, et al.           Expires September, 2022                 [Page 7]


Internet-Draft          Srpm Path Consistecy                 March 2022


   The test packet is as follows:

                A------------->B------------>C---------->D
        +-----------------+                      +-----------------+
        | SA=A's Ipv6Addr |                      | SA=A's Ipv6Addr |
        +-----------------+                      +-----------------+
        | DA=SID-A1       |                      | DA=D's ipv6Addr |
        +-----------------+                      +-----------------+
        | SL=3 | 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-A1     |                      | SID-Path-A1     |
        +-----------------+                      +-----------------+
        | test-payload    |                      | test-payload    |
        |                 |                      |                 |
        +-----------------+                      +-----------------+
                     Figure 5: Example of test packet


4.2. Stamp/twamp light Session-reflector procedure

   The test packet is forwarded along the path A->B->C-D. While packet
   arrives at nodeD, SRH.SL is 0 and the destination address is the
   IPv6 address of NodeD. Packet is delivered up to the stamp/twamp
   light module in control plane.

   Stamp/twamp light module on NodeD 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. When
   reply test packet, stamp/twamp light module use the segment list
   associated with path segment of the reverse path to encapsulate SRH.










Weng, et al.           Expires September, 2022                 [Page 8]


Internet-Draft          Srpm Path Consistecy                 March 2022


       +-----------------------------------------------------------+
       | IPv6 Header                                               |
       .  Source IP Address = Session-Reflector IPv6 Address       .
       .  Destination IP Address = SegmentList[SL]                 .
       .  Next-Header = SRH (43)                                   .
       .                                                           .
       +-----------------------------------------------------------+
       | SRH as specified in RFC 8754                              |
       .  Next-Header = IPv6                                       .
       .  <Segment List>                                           .
       .                                                           .
       +-----------------------------------------------------------+
       | IPv6 Header                                               |
       .  Source IP Address = Session-Reflector IPv6 Address       .
       .  Destination IP Address = Session-Sender IPv6 Address     .
       .  Next-Header = UDP                                        .
       .                                                           .
       +-----------------------------------------------------------+
       | UDP Header                                                |
       .                                                           .
       +-----------------------------------------------------------+
       | Payload                                                   |
        .                                                          .
       +-----------------------------------------------------------+
            Figure 6: Encapsulation format of reply test packet



   The Example of reply test packet is as follows:



















Weng, et al.           Expires September, 2022                 [Page 9]


Internet-Draft          Srpm Path Consistecy                 March 2022


                D------------->C------------>B---------->A

        +-----------------+                      +-----------------+
        | SA=D's Ipv6Addr |                      | SA=D's Ipv6Addr |
        +-----------------+                      +-----------------+
        | DA=SID-D1       |                      | DA=A's ipv6Addr |
        +-----------------+                      +-----------------+
        | SL=3 | 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          |
        +-----------------+                      +-----------------+
        | reply test      |                      | reply test      |
        |   payload       |                      |   payload       |
        +-----------------+                      +-----------------+
                  Figure 7: Example of reply test packet


   The reply test packet will be forward along the path D->C->B->A. In
   this way, the forward and reverse paths of test packet are
   guaranteed to be consistent.

5. IANA Considerations

   This document has no IANA actions.

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

7. References

7.1. Normative References

   [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C.,
             Talaulikar, K., Mattes, P.,Rosen, E., Jain, D., and S.
             Lin, "Advertising Segment Routing Policies in BGP", draft-
             ietf-idr-segment-routing-te-policy-11 (work in progress),
             November 2020


Weng, et al.           Expires September, 2022                [Page 10]


Internet-Draft          Srpm Path Consistecy                 March 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-07 (work in progress), December 2021.

   [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar,
             K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment
             Routing Policy Architecture", draft-ietf-spring-segment-
             routing-policy-17 (work in progress),February 2022.

   [I-D.ietf-spring-srv6-path-segment] Li, C., Cheng, W., Chen, M.,
             Dhody, D., and Y. Zhu, "Path Segment for SRv6 (Segment
             Routing in IPv6)", draft-ietf-spring-srv6-path-segment-03
             (work in progress),November 2021.

   [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-05(work in progress), January 2022.

   [I-D.ietf-spring-stamp-srpm] Gandhi, R., Filsfils, C., Voyer, D.,
             Chen, M., Janssens, B., and R. Foote, "Performance
             Measurement Using Simple TWAMP (STAMP) for Segment Routing
             Networks", Work in Progress, Internet-Draft, draft-ietf-
             spring-stamp-srpm-03, 1 February 2022,
             <https://www.ietf.org/archive/id/draft-ietf-spring-stamp-
             srpm-03.txt>.

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

   [RFC8762] Greg Mirsky, Guo Jun, Henrik Nydell, Richard Foote,
             "Simple Two-Way Active Measurement Protocol", RFC 8762,
             DOI: 10.17487/RFC8762, March 2020, <https://www.rfc-
             editor.org/info/rfc8762>.

   [RFC8972]  Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
             and E. Ruffini, "Simple Two-Way Active MeasurementProtocol
             Optional Extensions", RFC 8972, DOI 10.17487/RFC8972,
             January 2021, <https://www.rfc-editor.org/info/rfc8972>.


Weng, et al.           Expires September, 2022                [Page 11]


Internet-Draft          Srpm Path Consistecy                 March 2022


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

Contributors

   Yisong Liu contributed to the content of this document.







































Weng, et al.           Expires September, 2022                [Page 12]


Internet-Draft          Srpm Path Consistecy                 March 2022


Authors' Addresses

   Wengsijun
   China Mobile
   Beijing
   CN

   Email: wengsijun@chinamobile.com


   Weiqiang Cheng
   China Mobile
   Beijing
   CN

   Email: chengweiqiang@chinamobile.com


   Changwang Lin
   New H3C Technologies
   Beijing
   China

   Email: linchangwang.04414@h3c.com


   Hao Li
   New H3C Technologies
   Beijing
   China

   Email: lihao@h3c.com
















Weng, et al.           Expires September, 2022                [Page 13]