SRv6 Service Benchmarking Guideline
draft-geng-bmwg-srv6-service-guideline-00

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]