IPPM Working Group S. Weng Internet Draft W. Cheng Intended status: Informational China Mobile Expires: January 9, 2023 C. Lin New H3C Technologies X. Min ZTE Corp July 8, 2022 SRPM Path Consistency over SRv6 draft-weng-ippm-srpm-path-consistency-over-srv6-01 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 January 9 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Weng, et al. Expire January, 2023 [Page 1] Internet-Draft Srpm Path Consistecy July 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 .......... 9 5. IANA Considerations ........................................ 11 6. Security Considerations .................................... 11 7. References ................................................. 11 7.1. Normative References .................................. 11 Contributors .................................................. 13 Authors' Addresses ............................................ 14 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 delay and packet Weng, et al. Expires September, 2023 [Page 2] Internet-Draft Srpm Path Consistecy July 2022 loss along that IP path. It may be desired in SRv6 networks that the path between the Session-Sender and Session-Reflector for the STAMP test packets in both directions are consistent (same set of links and nodes). [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: o STAMP Session-Sender with STAMP Session-Reflector. o STAMP Session-Sender with TWAMP Light Session-Reflector. o TWAMP Light Session-Sender with STAMP Session-Reflector. o 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 consistent path between Session-Sender and session- reflector using path segment, which is 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, 2023 [Page 3] Internet-Draft Srpm Path Consistecy July 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 packet. 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, 2023 [Page 4] Internet-Draft Srpm Path Consistecy July 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 links. Refer to the reference topology2, there are two paths between Node A and D, and All nodes allocate End.x Segments. Node A and D are headend and tailend nodes of each other, and SRv6 policy is created on A and D respectively. Assuming that the deployed SRv6 policy has one candidate path and each path has two segment lists. For ease of description, segment lists with the same number on Node A and D are forward and reverse paths to each other.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 Weng, et al. Expires September, 2023 [Page 5] Internet-Draft Srpm Path Consistecy July 2022 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 list2 Segment list2 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 The headend can use path segment in two directions to establish a mapping table. Using this mapping table, the headend can get the reverse path through the path segment of the forward path. NodeA: +-----------------+ +--------------------+ | 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 |<------+ +-----------------------+ Weng, et al. Expires September, 2023 [Page 6] Internet-Draft Srpm Path Consistecy July 2022 NodeD: +-----------------+ +--------------------+ | 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 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 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: Weng, et al. Expires September, 2023 [Page 7] Internet-Draft Srpm Path Consistecy July 2022 +-----------------------------------------------------------+ | 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 . . . . . +-----------------------------------------------------------+ | 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. The test packet is as follows: Weng, et al. Expires September, 2023 [Page 8] Internet-Draft Srpm Path Consistecy July 2022 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-1 | | SID-Path-1 | +-----------------+ +-----------------+ | 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, 2023 [Page 9] Internet-Draft Srpm Path Consistecy July 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 . . < P-Flag=0,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, 2023 [Page 10] Internet-Draft Srpm Path Consistecy July 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., Jain, D., and S. Lin, "Advertising Segment Routing Policies in BGP", draft-ietf- idr-segment-routing-te-policy-18 (work in progress), June 2022. Weng, et al. Expires September, 2023 [Page 11] Internet-Draft Srpm Path Consistecy 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-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, . [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, . [RFC8762] Greg Mirsky, Guo Jun, Henrik Nydell, Richard Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI: 10.17487/RFC8762, March 2020, . [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, . Weng, et al. Expires September, 2023 [Page 12] Internet-Draft Srpm Path Consistecy July 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, . Contributors Yisong Liu contributed to the content of this document. Weng, et al. Expires September, 2023 [Page 13] Internet-Draft Srpm Path Consistecy July 2022 Authors' Addresses Sijun Weng 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 Xiao Min ZTE Corp. Nanjing China Email: xiao.min2@zte.com.cn Weng, et al. Expires September, 2023 [Page 14]