Internet-Draft Abbreviated-Title March 2024
Geng, et al. Expires 5 September 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-geng-bmwg-srv6-service-guideline-00
Published:
Intended Status:
Experimental
Expires:
Authors:
X. Geng
Huawei
K. Zhu
Huawei
T. Zhou
Huawei

SRv6 Service Benchmarking Guideline

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 5 September 2024.

▲

Table of Contents

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.

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

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.

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.

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;

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;

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

 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:

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;

 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;

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

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

Authors' Addresses

Xuesong Geng
Huawei
Keyi Zhu
Huawei
Tianran Zhou
Huawei