BMWG G. Fioccola Internet-Draft E. Vasilenko Intended status: Informational P. Volpato Expires: 25 April 2024 Huawei Technologies L. Contreras Telefonica B. Decraene Orange 23 October 2023 Benchmarking Methodology for IPv6 Segment Routing draft-vfv-bmwg-srv6-bench-meth-08 Abstract This document defines a methodology for benchmarking Segment Routing (SR) performance for Segment Routing over IPv6 (SRv6). It builds upon RFC 2544, RFC 5180, RFC 5695 and RFC 8402. 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 25 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Fioccola, et al. Expires 25 April 2024 [Page 1] Internet-Draft BM for SRv6 October 2023 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. SRv6 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4 3. Test Methodology . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Locator and Endpoint behaviors methods . . . . . . . . . 7 3.3. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 8 3.4. Protocol Addresses . . . . . . . . . . . . . . . . . . . 10 3.5. Trial Duration . . . . . . . . . . . . . . . . . . . . . 10 3.6. Traffic Verification . . . . . . . . . . . . . . . . . . 10 3.7. Buffer tests . . . . . . . . . . . . . . . . . . . . . . 11 4. Reporting Format . . . . . . . . . . . . . . . . . . . . . . 12 5. SRv6 Forwarding Benchmarking Tests . . . . . . . . . . . . . 13 5.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Throughput of a Source Node . . . . . . . . . . . . . 14 5.1.2. Throughput of a transit Segment Endpoint Node . . . . 15 5.1.3. Throughput of a Segment Endpoint Node with decapsulation . . . . . . . . . . . . . . . . . . . . 15 5.1.4. Throughput of a Transit Node . . . . . . . . . . . . 16 5.2. Buffers size . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 17 5.5. System Recovery . . . . . . . . . . . . . . . . . . . . . 17 5.6. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Fioccola, et al. Expires 25 April 2024 [Page 2] Internet-Draft BM for SRv6 October 2023 1. Introduction Segment Routing (SR), defined in [RFC8402], leverages the source routing paradigm. The headend node steers a packet through an SR Policy [RFC9256], instantiated as an ordered list of segments. A segment, referred to by its Segment Identifier (SID), can have a semantic local to an SR node or global within an SR domain. SR supports per-class explicit routing while maintaining per-class state only at the ingress nodes to the SR domain. However, there is no standard method defined to compare and contrast the foundational SR packet forwarding capabilities of network devices. This document aims to extend the efforts of [RFC1242], [RFC2544], [RFC5180] and [RFC5695] to SR network. The SR architecture can be instantiated on two data-plane: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6). This document is limited to SRv6. This document is limited to Headend encapsulations (H.Encaps.xxx) and segment Endpoints (End, End.X). It is expected that future documents may cover the benchmarking of SRv6 applications with decapsulation (End.Dxxx), Binding (End.Bxxx), Fast ReRoute [I-D.ietf-rtgwg-segment-routing-ti-lfa], Compressed SID [I-D.ietf-spring-srv6-srh-compression], etc. SR can be applied to the IPv6 architecture with a new type of routing header called the SR Header (SRH) [RFC8754]. An instruction is associated with a segment and encoded as an IPv6 address. An SRv6 segment is also called an SRv6 SID. An SR Policy is instantiated as an ordered list of SRv6 SIDs in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. SRv6 involves 3 types of forwarding plane operations (PUSH/ NEXT/ CONTINUE) as further described in Section 2. SR list for PUSH operation is typically constructed by the source node with a SR Policy, see [RFC9256]. NEXT operation is done by a SR segment endpoint node. CONTINUE operation happens for a SR transit node. [RFC5695] describes a methodology specific to the benchmarking of MPLS forwarding devices, by considering the most common MPLS packet forwarding scenarios and corresponding performance measurements. [RFC5180] provides benchmarking methodology recommendations that address IPv6-specific aspects, such as evaluating the forwarding performance of traffic containing extension headers. Fioccola, et al. Expires 25 April 2024 [Page 3] Internet-Draft BM for SRv6 October 2023 The purpose of this document is to describe a methodology specific to the benchmarking of Segment Routing over IPv6. The methodology described is a complement for [RFC5180] and [RFC5695]. 1.1. 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], RFC 8174 [RFC8174]. 2. SRv6 Forwarding SR leverages the source routing paradigm. In SRv6, a SID is allocated as an IPv6 address. For the IPv6 data plane, a new type of IPv6 Routing Extension Header, called Segment Routing Header (SRH) has been defined [RFC8754]. The SRH contains the Segment List as an ordered list of IPv6 addresses: each address in the list is a SID. Hence SRv6 Segment list typically contains more SIDs. A dedicated field, referred to as Segments Left, is used to maintain the pointer to the active SID of the Segment List. There are three different categories of nodes that may be involved in segment routing networks. The SR source node is the headend node and steers a packet into an SR Policy. It can be a host originating an IPv6 packet or an SR domain ingress router encapsulating a received packet into an outer IPv6 packet and inserts the SRH in the outer IPv6 header. It sets the first SID of the SR Policy as the IPv6 Destination Address of the packet. The SR transit node forwards packets destined for a remote segment as a normal IPv6 packet based on the IPv6 destination address, because the IPv6 destination address does not locally match with a segment. According to [RFC8200] the only node allowed to inspect the Routing Extension Header (and therefore the SRH) is the node corresponding to the destination address of the packet. The SR segment endpoint node receives packets whose IPv6 destination address is locally configured as a segment. It creates Forwarding Information Base (FIB) entries for its local SIDs. For each SR packet, it inspects the SRH, may prepare some actions (like forwarding through a particular interface), then replaces the IPv6 destination address with the new active segment. The operations applied by the SRv6 packet processing are different at the SR source, transit, and SR segment endpoint nodes. Fioccola, et al. Expires 25 April 2024 [Page 4] Internet-Draft BM for SRv6 October 2023 The processing of the SR source node corresponds to the sequence of insertion of the SRH, composed of SIDs stored in reverse order, and setting of the IPv6 Destination Address as the first SID of the SR Policy. It can be performed by encapsulating a packet into an outer IPv6 packet with an SRH. The processing of the SR segment endpoint node corresponds to the detection of the new active segment, which is the next segment in the Segment List and the related modification of the IPv6 destination address of the outer IPv6 header. Then packets are forwarded on the basis of the IPv6 forwarding table. The processing of the SR transit node corresponds to normal forwarding of the packets containing the SR header. In SRv6, the transit nodes do not need to be SRv6 aware, as every IPv6 router can act as an SRv6 transit node since any IPv6 node will maintain a plain IPv6 FIB entry for any prefix, no matter if the prefix represents a segment or not. [RFC9256] specifies the concepts of SR Policy and steering into an SR Policy. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. SR Policy state is instantiated only on the headend node, which steers a flow into an SR Policy. Intermediate and endpoint nodes do not require any state to be maintained. SR Policies can be instantiated on the headend dynamically and on demand basis. SR policy may be installed by PCEP [RFC8664], BGP [I-D.ietf-idr-segment-routing-te-policy], or via manual configuration on the router. PCEP and BGP signaling of SR Policies can be the case of a controller-based deployment. In addition to the basic SRv6 packet processing, the SRv6 Network Programming model [RFC8986] describes a set of functions that can be associated to segments and executed in a given SRv6 node. Examples of such functions are described in [RFC8986], but, in practice, any behavior and function can be associated with a local SID in a node, to apply any special processing on the packet. The definition of a standardized set of segment routing functions facilitates the deployment of SR domains with interoperable equipment from multiple vendors. According to [RFC8986], 128 bit SID can be logically split into three fields and interpreted as LOCATOR:FUNCTION:ARGS (in short LOC:FUNCT:ARG) where LOC includes the L most significant bits, FUNCT the following F bits and ARG the remaining A bits, where L+F+A=128. The LOC corresponds to an IPv6 prefix (for example with a length of 48, 56, or 64 bits) that can be distributed by the routing protocols Fioccola, et al. Expires 25 April 2024 [Page 5] Internet-Draft BM for SRv6 October 2023 and provides the reachability of a node that hosts some functions. All the different functions residing in a node have a different FUNCT code, so that their SIDs will be different. The ARG bits are used to provide information (arguments) to a function. From the routing point of view, the solution is scalable, as a single prefix is distributed for a node, which implements a potentially large number of functions and related arguments. 3. Test Methodology 3.1. Test Setup The test setup in general is compliant with section 6 of [RFC2544] but augmented by the methodology specified in section 4 of [RFC5695] using many interfaces. It is needed to test the packet forwarding engine that may have different performance based on the number of interfaces served. The Device Under Test (DUT) may have oversubscribed interfaces, then traffic for such interfaces should be proportionally decreased according to the specific DUT oversubscription ratio. All interfaces served by a particular packet forwarding engine should be loaded in reverse proportion to the claimed oversubscription ratio. Tests SHOULD be done with bidirectional traffic that better reflects the real environment for SRv6 nodes. It is OPTIONAL to choose a non-equal proportion for upstream and downstream traffic for some specific aggregation nodes. The RECOMMENDED topology for SRv6 Forwarding Benchmarking should be the same used for MPLS benchmarking, as described in section 4 of [RFC5695]. A simplified view is reported below for reference. +----------+ +---------| |<---------+ | +-------| Tester |<-------+ | | | +-----| |<-----+ | | | | | +----------+ | | | | | | | | | | | | +--------+ | | | | | +----->| |-------+ | | | +------->| DUT |---------+ | +--------->| |-----------+ +--------+ Figure 1: Test environment for SRv6 Forwarding Benchmarking Differently from [RFC5695], this document prefers the use of the term "interface" instead of "port" as an interface may be either virtual or physical. Fioccola, et al. Expires 25 April 2024 [Page 6] Internet-Draft BM for SRv6 October 2023 The RECOMMENDED topology for SRv6 Forwarding Benchmarking should be the same as MPLS and it is described in section 4 of [RFC5695]. Interface numbers involved in the tests and their oversubscription ratio MUST be reported. This document is benchmarking only "source routing". Hence, SIDs represent only Headend encapsulation (H.Encaps.xxx) or segment Endpoint (End, End.X) that may be carried in IGP extensions. In general, Functions of the last SID (called "behavior" in [RFC8986]) may be used to encode services (similar to L2/L3 VPNs and much more) but it is out of the scope of this document. It is OPTIONAL to test SRH in the combination with any other extension headers (fragmentation, hop-by-hop, destination options, etc.) but in all tests, the SRH header should be present for the test to be relevant for SRv6. It is RECOMMENDED to follow section 5.3 of [RFC5180] to introduce other extension headers in proportion 1%, 10%, 50% that may better reflect real use cases. Segment Routing may also be implemented as a software network function in an NFV Infrastructure and, in this case, additional considerations should be done. [ETSI-GR-NFV-TST-007] describes test guidelines for NFV capabilities that require interactions between the components implementing NFV functionality. Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. 3.2. Locator and Endpoint behaviors methods As specified in [RFC8986], topological segments have the structure that consists of Locator and Endpoint behavior (H.Encaps, End, End.X, etc), the latter may have a few different flavors (PSP, USP, USD). Different combinations of behavior and flavor are recommended for every test. It is RECOMMENDED that the DUT and test tool support at least one option for SID stack construction: * IS-IS Extensions to Support Segment Routing over IPv6 Dataplane [RFC9352] * OSPFv3 Extensions for SRv6 [I-D.ietf-lsr-ospfv3-srv6-extensions] * Segment Routing Policy Architecture [RFC9256]. A routing protocol (OSPF or IS-IS) SHOULD be used for the construction of the simplest SRH with 1 SID. It is RECOMMENDED that SR policy should be used for the construction of SRH with 2 SIDs. It Fioccola, et al. Expires 25 April 2024 [Page 7] Internet-Draft BM for SRv6 October 2023 is OPTIONAL to test longer SRH if there is an interest. For longer SRH lists, it is suggested to consider DUT maximum, or "network diameter" plus one SID for the service, where "network diameter" is the maximum number of SR hops that the target SRv6 network have, it is typically between 3 to 7 hops. It is RECOMMENDED that the top SID on the list should have an End.X flavor type to emulate traffic engineering scenario. In all cases, SID stack configuration SHOULD happen before packet forwarding would be started. Control plane convergence speed is not the subject of the present tests. The Locator and Endpoint construction method and SR policy construction method used MUST be reported according to Section 4. 3.3. Frame Formats and Sizes SRv6 tests will use Frame characteristics similarly to section 4.1.5 of [RFC5695], except the need for a bigger MTU to accommodate SRH. It is assumed that MTU is big enough to accommodate all frame sizes proposed below. Fragmentation is not an option for SRv6. It is to be noted that [RFC5695] requires exactly a single entry in the MPLS label stack in an MPLS packet that is not enough to simulate a typical SR SID list. The number of entries in SRH MUST be reported. According to section 4.1.4.2 of [RFC5695], the payload is RECOMMENDED to have an IP packet (IPv6 or IPv4 with UDP or TCP) to better represent the real environment. The minimal Ethernet payload (46B) could not accommodate the whole IPv6 stack (not enough room for TCP or UDP), hence only IPv4 is possible to use if the test for minimal Ethernet payload is needed. It is possible to choose the bigger payload size for the IPv6 only environment. It is assumed that the test would be for Ethernet media only. Other media is possible (see section 4.1.5.2 of [RFC5695] for the POS example). Some layer 2 technologies (like POS/PPP) have bit- or byte- stuffing then [RFC4814] may help to calculate real performance more accurately or else 1-2% error is expected. The most popular layer 2 technology for SR is Ethernet, it does not have stuffing. Fioccola, et al. Expires 25 April 2024 [Page 8] Internet-Draft BM for SRv6 October 2023 RECOMMENDED frame sizes are presented below. Any other frame sizes may be added if suspected of abnormal behavior. For example, some architectures may allocate buffer memory in big fixed chunks that may drop performance if frame sizes are chosen just a few octet more than the fixed chunk size (the second chunk would have a very low memory utilization). The resulting Ethernet frame structure is depicted in the next figure. <---18B---><-40B-><8+n*16B><--------46-1500-9000B-----------> +---------+-------+-------+---------+-----------------------+ | | Outer | | Inner | | | | Layer 2 | IPv6 | SRH | Layer 3 | Layer 4 | High layers | +---------+-------+-------+---------+-----------------------+ Figure 2: Ethernet Frame Structure RECOMMENDED payload sizes (encapsulated packet with L3 headers and above) are the following: * Ethernet Minimal: 46 * DUT Minimal Wire Speed: typically 128-256 (it depends on the DUT specification) * Ethernet Typical: 1500 * DUT Maximum: 9000 (or any claimed maximum) It is evident from the figure 2 that in all cases we need to add 40+8+n*16 bytes for the needed frame size, where 40 octets are added for the outer (tunnel) IPv6 header 8 octets are added for the SRH header itself n is the number of segments multiplied on 16 octet SID size. The typical frame size values are listed above for the DUT minimal wire speed and maximum, but they can be modified according to the DUT characteristics. The minimum wire speed frame size can be considered based on the DUT specification but, in some cases, many tests may be needed in the search for the real minimum wire speed frame size. VLAN tag may additionally increase the frame size. VLAN tag tests are OPTIONAL. Fioccola, et al. Expires 25 April 2024 [Page 9] Internet-Draft BM for SRv6 October 2023 3.4. Protocol Addresses IANA reserved an IPv6 address block 2001:0002::/48 for use with IPv6 benchmark testing (see section 8 of [RFC5180]). IPv6 source and destination addresses for the test streams SHOULD belong to the IPv6 range assigned by IANA. It is not principal what Locator blocks would be chosen for tests. It may be /52, /56, /64, or even bigger. It is possible to test a few different Locator blocks if there is a need. As it is discussed in section 3.1, there is a need to load the whole forwarding engine (on all interfaces). [RFC4814] discusses the importance to have many flows with address randomization for acceptable hash-based load balancing that is implemented in all forwarding engines. Note that IPv6 flow label randomization can be used, according to [RFC6438]. In the context of this document, it may also be relevant for SIDs, because SIDs may be used for hash to choose the next link (depending on DUT default or desired configuration). It is important to check what exactly is used for the hash load balancing algorithm on the DUT to keep these numbers sufficiently random and at volume. It is very often that IP addresses and transport protocol ports are used instead of SIDs. 3.5. Trial Duration The test portion of each trial must take into account the respective protocol configuration. IGP protocols typically have a shorter hold time, while some BGP default configurations may be up to 180 seconds. It is needed to check the default hold time of the DUT for the respective protocol used. In general, the test portion of each trial SHOULD be no less than 250 seconds, which is a reasonable value based on common hold time values. But a test can also adapt to the real setup and select a different value if default configuration has been changed. The test portion of each trial can be chosen at least 10 seconds longer than the hold time to verify that the DUT can maintain a stable control plane when the data-forwarding plane is under stress. 3.6. Traffic Verification Traffic verification is following section 10 of [RFC2544] and section 4.1.8 of [RFC5695]. The text is copied here for your convenience. "The test equipment SHOULD discard any frames received during a test run that are not actual forwarded test frames. For example, keep- alive and routing update frames SHOULD NOT be included in the count of received frames. In all cases, sent traffic MUST be accounted Fioccola, et al. Expires 25 April 2024 [Page 10] Internet-Draft BM for SRv6 October 2023 for, whether it was received on the wrong port, the correct port, or not received at all. In all cases, the test equipment SHOULD verify the length of the received frames and check that they match the expected length. Preferably, the test equipment SHOULD include sequence numbers (or signature) in the transmitted frames and check for these numbers on the received frames. If this is done, the reported results SHOULD include in addition to the number of frames dropped, the number of frames that were received out of order, the number of duplicate frames received and the number of gaps in the received frame numbering sequence". Many test tools may, by default, only verify that they have received the embedded signature on the receive side. However, some SRv6 tests assumes headers modifications (add or delete SRH, replace destination address, adjust "segments left"). All packets SHOULD be checked of the correct headers values on the receiving side. 3.7. Buffer tests Back-to-back frame test was initially discussed in section 26.4 [RFC2544] and later improved in [RFC9004] which is considered the comprehensive reference for Back-to-back frame test. Modern forwarding engines are typically flexible in the buffer distribution between different interfaces. Hence, like for all other benchmarking tests, it is important to stress the forwarding engine on all interfaces. It should be necessary to perform throughput tests first because only frame sizes that stress DUT below wire-speed can be used for back-to-back tests. Buffers would be filled with the rate equal to the difference between the theoretical maximum frame rate (wire- speed) and DUT measured throughput for the respective frame size. The test time could be much shorter than recommended in [RFC9004] because typical SR DUT is hardware-based with claimed buffers between 30ms to 100ms. It is better to consult with the vendor to find a good starting search point. If DUT is software-based then [RFC9004] recommendation for 2-30 seconds is applied. Queuing SHOULD NOT have weighted random early detection (WRED) or any other mechanism that may start dropping packets before the buffer is filled. Queuing SHOULD be configured for the tail drop which is typically a non-default configuration. Back-to-back frame test is rather complex and expensive (50 runs for every frame size). Hence, it is OPTIONAL for SRv6. Fioccola, et al. Expires 25 April 2024 [Page 11] Internet-Draft BM for SRv6 October 2023 4. Reporting Format There are a few parameters that must be changed in section 5 of [RFC5695] for SRv6 tests. Reporting parameter preserved from [RFC5695]: * Throughput in bytes per second and frames per second * Frame sizes in Octets (see Section 3.3) * Interface speed (10/50/100/400/800/etc GE) * Interface encapsulation (Ethernet or Ethernet VLAN) * Interface media type (probably Ethernet) Parameters changed from [RFC5695]: * SRv6 Forwarding Operations (PUSH/ NEXT/ CONTINUE). * Label Distribution protocol and IGP are the same in the context of SRv6. Hence, it can be called "Locator and Endpoint behaviors methods". New parameters that MUST be reported are: * Interface numbers involved for ingress and egress in the tests and their respective oversubscription ratio. * Upstream/downstream traffic proportion (equal bidirectional or some other split). * Number of Segments considered in the SRH. * Behavior (H.Encaps, etc.) and Flavor (PSP, USP, USD) used for tests (according to [RFC8986]). * SR Policy construction method (PCEP, BGP, manual configuration). * Type of the payload (IPv6/IPv4, UDP/TCP). * Time to recover from the overload state * Time to recover from the reset state and reset type (particular module in reset) Fioccola, et al. Expires 25 April 2024 [Page 12] Internet-Draft BM for SRv6 October 2023 * Tested buffers size in frames with respective frame size (for the optional back-to-back test); it is possible to record calculated buffer time for wire-speed throughput in milliseconds. Some parameters may be the same for all tests (like Media type or Ethernet encapsulation) then it may be reported one time. 5. SRv6 Forwarding Benchmarking Tests In general, tests are compliant with [RFC2544] but the important correction discussed in section 6 of [RFC2544] is applied: interfaces chosen for every test MUST stress all interfaces served by one forwarding engine. It is better to check the DUT specification for the relationship between interfaces and the forwarding engine to minimize the number of interfaces involved. But it is possible to understand the worst case by looking at the throughput and latency from the trial tests. If any doubt exists about how full is the offered load for the forwarding engine then it is better to stress all interfaces of the line card or all interfaces for the whole router with a centralized forwarding engine. A partial load on the forwarding engine would show optimistic results. Controllable traffic distribution between many interfaces (as specified in section 4 of [RFC5695]) would need separate SID announcements for separate interfaces. The performance of modern packet forwarding engines may be huge that may need to involve many testers to sufficiently load the DUT as presented on figure 3. Then results correlation and recalculation of the real performance would be an additional burden. +----------+ +-------| Tester1 |<-------+ | +-----| |<-----+ | | | +----------+ | | | | | | | | +--------+ | | | +----->| |-------+ | +------->| DUT |---------+ +------->| |---------+ | +----->| |-------+ | | | +--------+ | | | | | | | | +----------+ | | | +-----| Tester2 |<-----+ | +-------| |<-------+ +----------+ Figure 3: Many testers Fioccola, et al. Expires 25 April 2024 [Page 13] Internet-Draft BM for SRv6 October 2023 As specified in section 6 of [RFC5695], the traffic is sent from test tool Tx interface(s) to the DUT at a constant load for a fixed-time interval, and is received from the DUT on test tool Rx interface(s). If any frame loss is detected, then a new iteration is needed where the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss (No-Drop Rate - NDR). Each iteration should involve varying the offered load of the traffic, while keeping the other parameters (test duration, number of interfaces, number of addresses, frame size, etc.) constant, until the maximum rate at which none of the offered frames are dropped is determined. The test can be repeated with a varying number of Segments pushed on ingress in order to measure the resulting maximum number. It can also be tested the maximum number of Segments that are correctly load-balanced in transit by only changing the Nth label in the stack and detect when load-balancing fails. Therefore, the two main parameters that can be evaluated are: Maximum offered frame rate, Maximum number of Segments that can be pushed and hashed by the SR node for load-balancing. 5.1. Throughput This section contains a description of the tests that are related to the characterization of a DUT's SRv6 traffic forwarding throughput. The list of segments for SRv6 is represented as a list of IPv6 addresses, included in the SRH. There are three distinct types of nodes that are involved in segment routing networks that may represent four different cases. 5.1.1. Throughput of a Source Node Objective: To obtain the DUT's Throughput during the packet processing of a Source Node. It is when the Source SR node, which corresponds to the headend node, encapsulates a received packet into an outer IPv6 packet and inserts the SR Header (SRH) as a Routing Extension Header in the outer IPv6 header. The Segment List in the SRH is composed of SIDs and the Source SR node sets the first SID of the SR Policy as the IPv6 Destination Address of the packet. The RECOMMENDED headend behavior is H.Encaps, in case of interest for another behavior (H.Encaps.Red or H.Encaps.L2 or H.Encaps.L2.Red) it is OPTIONAL to test it with proper reporting. Fioccola, et al. Expires 25 April 2024 [Page 14] Internet-Draft BM for SRv6 October 2023 Procedure: Similar to section 6.1 of [RFC5695] or section 26.1 of [RFC2544] with extension to test SID list longer than 1 SID (more than 2 are RECOMMENDED). SID list can be from 1 to N SIDs. N could be specified a priori or measured as part of the test. The test tool must advertise and learn the IP prefix(es) and SID(s) on respective sides, as per Section 3.4, and must use one option for SID stack construction, as per Section 3.2, on its receive and transmit interfaces towards the DUT. Reporting Format: A table, similar to [RFC5180], with all parameters specified in Section 4. 5.1.2. Throughput of a transit Segment Endpoint Node Objective: To obtain the DUT's Throughput during the packet processing of a Segment Endpoint Node. It is when the SR Segment Endpoint node receives packets whose IPv6 destination address is locally configured as a segment. The SR Segment Endpoint node inspects the SR header: it detects the new active segment, i.e. the next segment in the Segment List, modifies the IPv6 destination address of the outer IPv6 header and forwards the packet on the basis of the IPv6 forwarding table. The RECOMMENDED endpoint behavior is End.X, in case of interest for another behavior (End, End.T, End.BM, End.B6.Encaps, End.B6.Encaps.Red) it is OPTIONAL to test it with proper reporting. SRH SL (Segment Left) is assumed to be bigger than zero for this test. Moreover, it is assumed that DUT would not need to delete headers (no PSP, USD, or USP). Procedure: Similar to section 6.1 of [RFC5695] or section 26.1 of [RFC2544] with extension to test SID list longer than 1 SID (more than 2 are RECOMMENDED). SID list can be from 1 to N SIDs. N could be specified a priori or measured as part of the test. The test tool must advertise and learn the IP prefix(es) and SID(s) on respective sides, as per Section 3.4, and must use one option for SID stack construction, as per Section 3.2, on its receive and transmit interfaces towards the DUT. Reporting Format: A table, similar to [RFC5180], with all parameters specified in Section 4. 5.1.3. Throughput of a Segment Endpoint Node with decapsulation Objective: To obtain the DUT's Throughput during the packet processing of a Segment Endpoint Node that needs decapsulation. It is when the SR Segment Endpoint node receives packets whose IPv6 destination address is locally configured as a segment and SL (segment left) in the SRH header is decremented to zero. The SR Segment Endpoint node inspects the SR header: it detects the new Fioccola, et al. Expires 25 April 2024 [Page 15] Internet-Draft BM for SRv6 October 2023 active segment, i.e. the next segment in the Segment List, modifies the IPv6 destination address of the outer IPv6 header, decapsulate the packet, and forwards the packet on the basis of the IPv6 forwarding table. The RECOMMENDED endpoint decapsulation behavior is End with USD flavor, in case of interest for another flavor (PSP, USP) it is OPTIONAL to test it with proper reporting. Procedure: Similar to section 6.1 of [RFC5695] or section 26.1 of [RFC2544] with extension to test SID list longer than 1 SID (more than 2 are RECOMMENDED). SID list can be from 1 to N SIDs. N could be specified a priori or measured as part of the test. The test tool must advertise and learn the IP prefix(es) and SID(s) on respective sides, as per Section 3.4, and must use one option for SID stack construction, as per Section 3.2, on its receive and transmit interfaces towards the DUT. Reporting Format: A table, similar to [RFC5180], with all parameters specified in Section 4. 5.1.4. Throughput of a Transit Node Objective: To obtain the DUT's Throughput during the packet processing of a Transit Node. It is when a Transit node forwards the packet containing the SR header as a normal IPv6 packet because the IPv6 destination address does not locally match with a segment. Procedure: Similar to section 6.1 of [RFC5695] or section 26.1 of [RFC2544] with extension to test SID list longer than 1 SID (more than 2 are RECOMMENDED). SID list can be from 1 to N SIDs. N could be specified a priori or measured as part of the test. The test tool must advertise and learn the IP prefix(es) and SID(s) on respective sides, as per Section 3.4, and must use one option for SID stack construction, as per Section 3.2, on its receive and transmit interfaces towards the DUT. Reporting Format: A table, similar to [RFC5180], with all parameters specified in Section 4. 5.2. Buffers size Back-to-back frame test is OPTIONAL and SHOULD be performed only after throughput tests because it SHOULD use only frame sizes that DUT is not capable to forward wire-speed, as explained in Section 3.7. Objective: To determine the buffer size as defined in section 6 of [RFC9004] for each of the SRv6 forwarding operations. Fioccola, et al. Expires 25 April 2024 [Page 16] Internet-Draft BM for SRv6 October 2023 Procedure: Should be inherited from [RFC9004] with 2 SIDs RECOMMENDED (many SIDs are possible). Despite the simple general idea for filling the buffer until tail drop, [RFC9004] has many details for procedure, precautions, and calculations that would be too lengthy to copy here. Reporting Format: A table, similar to [RFC5180], with all parameters specified in Section 4. 5.3. Latency Objective: To determine the latency as defined in section 6.2 of [RFC5695] and section 26.2 of [RFC2544] for each of the SRv6 forwarding operations. It is RECOMMENDED to test all four test types discussed in Section 5.1. Procedure: Similar to Section 5.1. It is OPTIONAL to improve the procedure according to section 7.2 of [RFC8219] with calculations for typical and worst-case latency. Reporting Format: A table, similar to [RFC5180], with all parameters specified in Section 4. 5.4. Frame Loss Objective: To determine the frame-loss rate (as defined in section 6.3 of [RFC5695] or and section 26.3 of [RFC2544]) for each of the SRv6 forwarding operations of a DUT throughout the entire range of input data rates and frame sizes. The primary idea is to see what would be the frame loss under the overload conditions. It may be that overloaded forwarding engine would forward less traffic than in the situation close to the overload. Throughput may drop below the possible maximum. As for the section 26.3 of [RFC2544], it is RECOMMENDED to have the data for all tested frame sizes with 10% load step above the wire-speed throughput measured in Section 5.1. It is RECOMMENDED to test all four test types discussed in Section 5.1. Procedure: Similar to Section 5.1. Reporting Format: A table, similar to [RFC5180], with all parameters specified in Section 4. 5.5. System Recovery Objective: To characterize the speed at which a DUT recovers from an overload condition for each of the SRv6 forwarding operations. It is RECOMMENDED to test all four test types discussed in Section 5.1. Fioccola, et al. Expires 25 April 2024 [Page 17] Internet-Draft BM for SRv6 October 2023 Procedure: Similar to section 6.4 of [RFC5695] or section 26.5 of [RFC2544]. Send a stream of frames at a rate 110% of the recorded throughput rate or the maximum rate for the media, whichever is lower, for at least 60 seconds. At Timestamp A reduce the frame rate to 50% of the above rate and record the time of the last frame lost (Timestamp B). The system recovery time is determined by subtracting Timestamp B from Timestamp A. The test SHOULD be repeated a number of times and the average of the recorded values being reported. Reporting Format: A table, similar to [RFC5180], with all parameters specified in Section 4. 5.6. Reset All type of reset tests are OPTIONAL. Objective: To characterize the speed at which a DUT recovers from a device or software reset for each of the SRv6 forwarding operations. According to section 1.3 of [RFC6201] it is possible to measure frame loss or time stamps (depending on the test tool capability). According to section 4 of [RFC6201] reset could be: 1) hardware, 2) software, or 3) power interruption. All resets may be partial, i.e. only for a particular part of hardware (line card) or software (module). Especial interest may be to test redundant power supplies or routing engines to make sure that reset does not affect the traffic. Hardware reset may be soft (command for reset) or hard (physical removal and insertion of the module). These types of reset SHOULD be treated as different. It is OPTIONAL to test all four test types discussed in Section 5.1, typically they would give the same result. Procedure: It is inherited from [RFC6201] (see it for more details). It is simple in essence: create the traffic, initiate a reset, measure the time for the traffic lost. Reporting Format: A table, similar to [RFC5180], with all parameters specified in Section 4. 6. Security Considerations Benchmarking methodologies are limited to technology characterization in a laboratory environment, with dedicated address space and constraints. Special capabilities SHOULD NOT exist in the DUT/SUT specifically for benchmarking purposes. Any implications for network security arising from the DUT/SUT SHOULD be identical in the lab and production networks. The benchmarking network topology is an independent test setup and MUST NOT be connected to devices that may forward the test traffic into a production network or misroute Fioccola, et al. Expires 25 April 2024 [Page 18] Internet-Draft BM for SRv6 October 2023 traffic to the test management network. There are no specific security considerations within the scope of this document. 7. IANA Considerations This document has no IANA actions. 8. Acknowledgements The authors would like to thank Al Morton, Gabor Lencse, Boris Khasanov for the precious comments and suggestions. 9. References 9.1. Normative References [RFC1242] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, July 1991, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, . [RFC4814] Newman, D. and T. Player, "Hash and Stuffing: Overlooked Factors in Network Device Benchmarking", RFC 4814, DOI 10.17487/RFC4814, March 2007, . [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. Dugatkin, "IPv6 Benchmarking Methodology for Network Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 2008, . [RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding Benchmarking Methodology for IP Flows", RFC 5695, DOI 10.17487/RFC5695, November 2009, . Fioccola, et al. Expires 25 April 2024 [Page 19] Internet-Draft BM for SRv6 October 2023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking Methodology for IPv6 Transition Technologies", RFC 8219, DOI 10.17487/RFC8219, August 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, . [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [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, . 9.2. Informative References [ETSI-GR-NFV-TST-007] ETSI, "ETSI GR NFV-TST 007: Network Functions Virtualisation (NFV) Release 3; Testing; Guidelines on Interoperability Testing for MANO", 2020, . [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and D. Jain, "Advertising Segment Routing Policies in BGP", Work in Progress, Internet-Draft, draft-ietf-idr-segment- routing-te-policy-25, 26 September 2023, . [I-D.ietf-lsr-ospfv3-srv6-extensions] Li, Z., Hu, Z., Talaulikar, K., and P. Psenak, "OSPFv3 Extensions for SRv6", Work in Progress, Internet-Draft, draft-ietf-lsr-ospfv3-srv6-extensions-15, 21 June 2023, . Fioccola, et al. Expires 25 April 2024 [Page 20] Internet-Draft BM for SRv6 October 2023 [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa- 11, 30 June 2023, . [I-D.ietf-spring-srv6-srh-compression] Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F. Clad, "Compressed SRv6 Segment List Encoding in SRH", Work in Progress, Internet-Draft, draft-ietf-spring-srv6-srh- compression-08, 12 September 2023, . [RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera, "Device Reset Characterization", RFC 6201, DOI 10.17487/RFC6201, March 2011, . [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, . [RFC9004] Morton, A., "Updates for the Back-to-Back Frame Benchmark in RFC 2544", RFC 9004, DOI 10.17487/RFC9004, May 2021, . [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, . Fioccola, et al. Expires 25 April 2024 [Page 21] Internet-Draft BM for SRv6 October 2023 [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, February 2023, . Authors' Addresses Giuseppe Fioccola Huawei Technologies Palazzo Verrocchio, Centro Direzionale Milano 2 20054 Segrate (Milan) Italy Email: giuseppe.fioccola@huawei.com Eduard Vasilenko Huawei Technologies 17/4 Krylatskaya str. Moscow Email: vasilenko.eduard@huawei.com Paolo Volpato Huawei Technologies Palazzo Verrocchio, Centro Direzionale Milano 2 20054 Segrate (Milan) Italy Email: paolo.volpato@huawei.com Luis Miguel Contreras Murillo Telefonica Spain Email: luismiguel.contrerasmurillo@telefonica.com Bruno Decraene Orange France Email: bruno.decraene@orange.com Fioccola, et al. Expires 25 April 2024 [Page 22]