SRv6 Service Benchmarking Guideline

Test Topology

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.

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.

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;

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;

TBD

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.

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.

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.

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

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;

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;

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;

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;

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;