Network Working Group X. Geng Internet-Draft K. Zhu Intended status: Experimental T. Zhou Expires: 3 March 2025 Huawei 30 August 2024 SRv6 Service Benchmarking Guideline draft-geng-bmwg-srv6-service-guideline-01 Abstract This document serves as a comprehensive guideline for SRv6 service benchmarking, outlining a core set of test cases that can be employed as a foundation for further benchmarking work. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 3 March 2025. 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 (https://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 Geng, et al. Expires 3 March 2025 [Page 1] Internet-Draft Abbreviated-Title August 2024 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Test Case Guidance . . . . . . . . . . . . . . . . . . . . . 3 3.1. Basic SRv6 E2E Service . . . . . . . . . . . . . . . . . 3 3.1.1. SRv6 BE E2E Service . . . . . . . . . . . . . . . . . 3 3.1.2. Basic Function Test of SRv6 Policy Tunnel . . . . . . 4 3.2. SRv6 Compression E2E Service . . . . . . . . . . . . . . 5 3.3. EVPN L2/L3VPN over SRv6 . . . . . . . . . . . . . . . . . 6 3.3.1. EVPN VPWS over SRv6 . . . . . . . . . . . . . . . . . 6 3.3.2. EVPN L3VPN over SRv6 . . . . . . . . . . . . . . . . 7 3.4. SRv6 OAM . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4.1. Y.1731 for SRv6 L2-service . . . . . . . . . . . . . 7 3.4.2. SRv6 SID Ping . . . . . . . . . . . . . . . . . . . . 8 3.4.3. SRv6 SID Tracert . . . . . . . . . . . . . . . . . . 8 3.5. SRv6 Reliability . . . . . . . . . . . . . . . . . . . . 9 3.5.1. SRv6 BE Reliablity . . . . . . . . . . . . . . . . . 9 3.5.2. SRv6 Policy Reliablity . . . . . . . . . . . . . . . 9 3.6. SRv6 Service Performance . . . . . . . . . . . . . . . . 10 3.6.1. SRv6 SRH Layer Number . . . . . . . . . . . . . . . . 10 3.6.2. SRv6 Forwarding Performance . . . . . . . . . . . . . 11 3.6.3. SRv6 Tunnel Number . . . . . . . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Normative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. To ensure easier deployment and show the potential capability of SRv6, tests for SRv6 service is important, besides the existing work of SRv6 forwarding. This document serves as a comprehensive guideline for SRv6 service benchmarking, outlining a core set of test cases that can be employed as a foundation for further benchmarking work. Geng, et al. Expires 3 March 2025 [Page 2] Internet-Draft Abbreviated-Title August 2024 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, RFC 8174. 3. Test Case Guidance Ingress Node Endpoint Egress Node +--+ +--+ +--+ |PE|------------| P|------------|PE| +--+ +--+ +--+ Test Topology 3.1. Basic SRv6 E2E Service 3.1.1. SRv6 BE E2E Service Objective: Basic Function Test of SRv6 BE Tunnel Procedure:  Build the test network according to the topology with basic IGP/BGP configuration ready.  Deploy L3VPN over SRv6-BE tunnel, the tester generates traffic, and there is expected result 1.  Deploy EVPNv4 over SRv6-BE tunnel, the tester generates traffic, and there is expected result 2.  Deploy EVPNv6 over SRv6-BE tunnel, the tester generates traffic, and there is expected result 3.  Deploy EVPN VPWS over SRv6-BE tunnel, the tester generates traffic, and there is expected result 4. Expected Results: 1. The device supports L3VPN over SRv6-BE tunnel, and the traffic is forwarded normally without packet loss. 2. The device supports EVPNv4 over SRv6-BE tunnel, and the traffic is forwarded normally without packet loss. Geng, et al. Expires 3 March 2025 [Page 3] Internet-Draft Abbreviated-Title August 2024 3. The device supports EVPNv6 over SRv6-BE tunnel, and the traffic is forwarded normally without packet loss. 4. The device supports EVPN VPWS over SRv6-BE tunnel, and the traffic is forwarded normally without packet loss. 3.1.2. Basic Function Test of SRv6 Policy Tunnel Objective: Basic Function Test of SRv6 Policy Tunnel Procedure:  Build the test network according to the diagram, and ensure that the basic IGP/BGP configuration is correct.  Deploy L3VPN over SRv6 Policy tunnel, generate traffic using the tester, and verify that the expected result 1 is achieved.  Deploy EVPNv4 over SRv6 Policy tunnel, generate traffic using the tester, and verify that the expected result 2 is achieved.  Deploy EVPNv6 over SRv6 Policy tunnel, generate traffic using the tester, and verify that the expected result 3 is achieved.  Deploy EVPN VPWS over SRv6 Policy tunnel, generate traffic using the tester, and verify that the expected result 4 is achieved.  Adjust the SRv6 Policy tunnel labels to implement tunnel selection, generate traffic using the tester, and verify that the expected result 5 is achieved.  Use BGP color to steer traffic to the SRv6 Policy tunnel and verify that the expected result 6 is achieved.  Use DSCP to steer traffic to the SRv6 Policy tunnel and verify that the expected result 7 is achieved. Expected Results: 1. The device supports L3VPN over SRv6 Policy tunnel carrying capability, and the traffic is forwarded normally without packet loss. 2. The device supports EVPNv4 over SRv6 Policy tunnel carrying capability, and the traffic is forwarded normally without packet loss. Geng, et al. Expires 3 March 2025 [Page 4] Internet-Draft Abbreviated-Title August 2024 3. The device supports EVPNv6 over SRv6 Policy tunnel carrying capability, and the traffic is forwarded normally without packet loss. 4. The device supports EVPN VPWS over SRv6 Policy tunnel carrying capability, and the traffic is forwarded without packet loss. 5. The device supports the ability to adjust the path of SRv6 Policy tunnels. 6. The device supports BGP color-based traffic steering to SRv6 Policy tunnels. 7. The device supports DSCP-based traffic steering to SRv6 Policy tunnels. 3.2. SRv6 Compression E2E Service Objective: Verify whether the device supports SRv6 packet header compression Procedure:  Set up SRv6 Policy explicit path, the intermediate node is based on END/END.X forwarding. There are 5 hops in the SRv6 tunnel, and the tunnel is able to transport the stream from the tester with the expected result 1;  Set up SRv6 Policy explicit path with compression; There are 5 hops in the SRv6 tunnel, and the tunnel is able to transport the stream from the tester with the expected result 2;  Capture packets at the intermediate node, with expected result 3; Expected Results: 1. traffic is forwarded normally; Record the percentage of SRH overhead in the overall packet; 2. traffic is forwarded normally, SRH packet header overhead is reduced; Record the percentage of SRH overhead in the overall packet; 3. Capture the packet at intermediate nodes, and the SRv6 compression packet header is as expected which is the same as draft- ietf-spring-srv6-srh-compression; Geng, et al. Expires 3 March 2025 [Page 5] Internet-Draft Abbreviated-Title August 2024 3.3. EVPN L2/L3VPN over SRv6 3.3.1. EVPN VPWS over SRv6 Objective: Verify that in the CPE supports SRv6 scenarios, private line services (EVPN VPWS over SRv6) could be carried by SRv6-BE tunnels and SRv6 policy tunnels. Procedure:  Set up the test network, configure SRv6 BEs on CPE1 and CPE2, and if the intermediate traversing devices are existing IPv6 devices, carry out dual-stack deployment to pass the locator and loopback routes of CPE1 and CPE2, and establish BGP EVPN peers directly on CPE1 and CPE2. 2;  create EVPN VPWS instances on CPE1 and CPE2 respectively. in the VPN instance view of BGP. enable SRv6 forwarding to draw services into SRv6;  connect a tester between CPE1 and CPE2, configure the IP address, and send bidirectional test traffic. There are expected results 1. use the meter to test delay, delay jitter, and packet loss rate. There are expected results 2;  the intermediate device supports SRv6, establishes BGP neighbors through ASG/RR reflection, establishes an end-to-end EVPN VPWS over SRv6-BE tunnel, and the tester hits the flow with expected result 1. Tests the latency, latency jitter, and packet loss rate with the meter. There are expected results 2;  with controller scenario, establish end-to-end EVPN VPWS over SRv6-Policy tunnel by issuing SRv6-Policy tunnel through the controller or manually specifying the display path method, the tester hits the flow with expected result 1, test the delay, delay jitter and packet loss rate with meter. There are expected results 2; Expected Results: 1. traffic is forwarded normally; Record the percentage of SRH overhead in the overall packet; 2. traffic is forwarded normally, SRH packet header overhead is reduced; Record the percentage of SRH overhead in the overall packet; Geng, et al. Expires 3 March 2025 [Page 6] Internet-Draft Abbreviated-Title August 2024 3. Capture the packet at intermediate nodes, and the SRv6 compression packet header is as expected which is the same as draft- ietf-spring-srv6-srh-compression; 3.3.2. EVPN L3VPN over SRv6 TBD 3.4. SRv6 OAM Objective: Verify that the device supports OAM technologies such as SRv6 PING/TRACE Procedure:  build the test network according to the figure to ensure that the configured services are all in normal state.  Test tunnel SRv6 SID Ping/Trace with expected result 1. 3;  Test VPN SID Ping/Trace with expected result 2;  SRv6 L3VPN scenario, test TWAMP for L3-service, with expected result 3;  SRv6 EVPN VPWS scenario, testing Y.1731 for L2-service with expected result 4; Expected Results: 1. The device supports SRv6 SID tunnel level Ping/Trace; 2. The device supports SRv6 VPN level Ping/Trace; 3. The device supports TWAMP for L3-service. 4; 4. The device supports Y.1731 for L2-service. 3.4.1. Y.1731 for SRv6 L2-service Objective: To test the delay and packet loss statistics of Y.1731 under EVPN L2VPN. Procedure:  Establish the EVPN VPWS over SRv6 service Geng, et al. Expires 3 March 2025 [Page 7] Internet-Draft Abbreviated-Title August 2024  Enable the Y.1731 function. At the same time, enable single-ended synthetic packet loss and double-ended delay statistics  The meter sends service traffic and records delay  Query the Y.1731 delay statistics and get the expected result 1  Shutdown / no shutdown link, simulate packet loss  Query the Y.1731 delay statistics and get the expected result 2 Expected Results: 1. The query Y.1731 delay statistics result on the device is basically the same as the delay result shown on the meter. 2. The query Y.1731 packet loss on the device is basically consistent with the packet loss statistics shown on the meter. 3.4.2. SRv6 SID Ping Objective: Verify that tunnel connectivity can be detected by SRv6 SID Ping. Procedure:  Initiate the SRv6 SID ping test from from network device 1 to network device 2, and get test result 1. Expected Results: 1. The query Y.1731 delay statistics result on the device is basically the same as the delay result shown on the meter. 2. The query Y.1731 packet loss on the device is basically consistent with the packet loss statistics shown on the meter. 3.4.3. SRv6 SID Tracert Objective: Verify that tunnel connectivity can be detected via SRv6 SID Tracert. Procedure:  Initiate the SRv6 SID Tracert test from network device 1 to network device 2, and get test result 1 Expected Results: Geng, et al. Expires 3 March 2025 [Page 8] Internet-Draft Abbreviated-Title August 2024 1. the SRv6 SID Tracert returns the result that every node is through 3.5. SRv6 Reliability 3.5.1. SRv6 BE Reliablity Objective: Test the protection capabilities in SRv6-BE scenarios. Procedure:  SRv6-BE scenario, detection and protection techniques in case of link failure, with expected result 1;  The tester sends the flow in the link failure scenario, test the packet loss time, with expected result 2;  PE node failure happens, with the detection and protection techniques, with expected result 3;  The tester sends the flow in the node failure scenario, test packet loss time, with expected result 4; Expected Results: 1. The network device support BFD for IGP detection, support Ti-LFA protection inversion; 2. The time of BFD detection is 10ms*3, and the equipment packet loss time is less than 50ms; 3. The device supports BFD for locator detection and VPN FRR; 4. The time of BFD detection is 10ms*3, device packet loss time is less than 200ms; 3.5.2. SRv6 Policy Reliablity Objective: Test the protection capabilities in SRv6 Policy scenarios. Procedure:  SRv6 Policy scenario, detection and protection techniques in case of link failure, with expected result 1;  The tester sends the flow in the link failure scenario, test the packet loss time, with expected result 2; Geng, et al. Expires 3 March 2025 [Page 9] Internet-Draft Abbreviated-Title August 2024  PE node failure happens, with the detection and protection techniques, with expected result 3;  The tester sends the flow in the node failure scenario, test packet loss time, with expected result 4; Expected Results: 1. The network device support SBFD for SRv6-list detection, support HSB protection switch over; 2. The time of BFD detection is 10ms*3, and the equipment packet loss time is less than 50ms; 3. The device supports SBFD for primary and backup SRv6-list detection and VPN FRR; 4. The time of BFD detection is 10ms*3, device packet loss time is less than 200ms; 3.6. SRv6 Service Performance 3.6.1. SRv6 SRH Layer Number Objective: Test the number of SRv6 Policy tunnel SRH label layers supported by the device Procedure:  SRv6 Policy tunnels should be configured on the device under test and the auxiliary device, so that the traffic is relayed repeatedly between the device under test and the auxiliary device, and all of them use END.X neighbor tag forwarding;  The tester sends the flow with the expected result 1;  capture packets on the outgoing interface of the device under test, with expected result 2; Expected Results: 1. Stable traffic with no packet loss for SRv6 Policy tunnel with multilayer SRH labels; 2. Packet capture at the outgoing interface of the device under test, which can capture packets with different label layers, and record the number of SRH label layers supported by each manufacturer; Geng, et al. Expires 3 March 2025 [Page 10] Internet-Draft Abbreviated-Title August 2024 3.6.2. SRv6 Forwarding Performance Objective: Verify the SRv6 packet forwarding performance of the device Procedure:  Test the forwarding performance of the L3VPN service under the SRv6-BE scenario in the 256/512/1024 bit byte traffic scenario with the expected result 1;  Test the forwarding performance of the EVPNv4 service under the SRv6-BE scenario under the 256/512/1024bit byte traffic scenario with expected result 1;  Testing the forwarding performance of EVPNv6 services under SRv6-BE scenario with 256/512/1024bit byte traffic scenarios with expected result 1;  Test the forwarding performance of EVPN VPWS services under SRv6-BE scenario with 256/512/1024bit byte traffic scenario with expected result 1;  Test the forwarding performance of L3VPN services under SRv6 Policy scenario (Layer 3 labeling) with 256/512/1024bit byte traffic scenario with expected result 1;  Test the forwarding performance of EVPNv4 service under SRv6 Policy scenario (Layer 3 labeling) with expected result 1 under 256/512/1024bit byte traffic scenario;  Test the forwarding performance of EVPNv6 services under SRv6 Policy scenario (Layer 3 labeling) with expected result 1 under 256/512/1024bit byte traffic scenario;  Test the forwarding performance of EVPN VPWS services under SRv6 Policy scenario (Layer 3 labeling) with 256/512/1024bit byte traffic scenario with expected result 1; Expected Results: 1. Record the forwarding performance of each vendor's device as a percentage of performance for each service scenario; 3.6.3. SRv6 Tunnel Number Objective: Test the number of SRv6 Policy tunnels supported by the device Geng, et al. Expires 3 March 2025 [Page 11] Internet-Draft Abbreviated-Title August 2024 Procedure:  Test the forwarding performance of the L3VPN service under the SRv6-BE scenario in the 256/512/10  The tester advertises N routes to the system under test and establishes the corresponding SRv6 Policy tunnels based on each route (through the controller or scripts), with each SRv6 Policy labeled at Layer 3;  The tester sends the stream with Desired Result 1; Expected Results: 1. Each SRv6 Policy tunnel carries normal service traffic. Record the number of SRv6 Policy tunnels supported by each manufacturer's device; 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations 6. Acknowledgements 7. Normative References [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, . [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, . Geng, et al. Expires 3 March 2025 [Page 12] Internet-Draft Abbreviated-Title August 2024 [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 10.17487/RFC8986, February 2021, . Authors' Addresses Xuesong Geng Huawei Email: gengxuesong@huawei.com Keyi Zhu Huawei Email: zhukeyi@huawei.com Tianran Zhou Huawei Email: zhoutianran@huawei.com Geng, et al. Expires 3 March 2025 [Page 13]