Internet DRAFT - draft-geng-bmwg-srv6-service-guideline
draft-geng-bmwg-srv6-service-guideline
Network Working Group X. Geng
Internet-Draft K. Zhu
Intended status: Experimental T. Zhou
Expires: 5 September 2024 Huawei
4 March 2024
SRv6 Service Benchmarking Guideline
draft-geng-bmwg-srv6-service-guideline-00
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.
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 5 September 2024 [Page 1]
Internet-Draft Abbreviated-Title March 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 . . . . . . . . . . . . . . . . . 5
3.3.1. EVPN VPWS over SRv6 . . . . . . . . . . . . . . . . . 5
3.3.2. EVPN L3VPN over SRv6 . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . 10
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 5 September 2024 [Page 2]
Internet-Draft Abbreviated-Title March 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
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.
Geng, et al. Expires 5 September 2024 [Page 3]
Internet-Draft Abbreviated-Title March 2024
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.
Geng, et al. Expires 5 September 2024 [Page 4]
Internet-Draft Abbreviated-Title March 2024
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.
Geng, et al. Expires 5 September 2024 [Page 5]
Internet-Draft Abbreviated-Title March 2024
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
Geng, et al. Expires 5 September 2024 [Page 6]
Internet-Draft Abbreviated-Title March 2024
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
Geng, et al. Expires 5 September 2024 [Page 7]
Internet-Draft Abbreviated-Title March 2024
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
Geng, et al. Expires 5 September 2024 [Page 8]
Internet-Draft Abbreviated-Title March 2024
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;
Geng, et al. Expires 5 September 2024 [Page 9]
Internet-Draft Abbreviated-Title March 2024
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
Geng, et al. Expires 5 September 2024 [Page 10]
Internet-Draft Abbreviated-Title March 2024
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
Geng, et al. Expires 5 September 2024 [Page 11]
Internet-Draft Abbreviated-Title March 2024
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,
<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,
May 2017, <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,
July 2018, <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, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
Geng, et al. Expires 5 September 2024 [Page 12]
Internet-Draft Abbreviated-Title March 2024
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 5 September 2024 [Page 13]
