BMWG G. Fioccola Internet-Draft E. Vasilenko Intended status: Informational P. Volpato Expires: 26 March 2027 Huawei Technologies L. Contreras Telefonica B. Decraene Orange 22 September 2026 Benchmarking Methodology for Segment Routing (SR) Forwarding draft-ietf-bmwg-sr-bench-meth-09 Abstract This document defines a methodology for benchmarking Segment Routing (SR) forwarding performance for Segment Routing over IPv6 (SRv6) and MPLS (SR-MPLS). 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 26 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Fioccola, et al. Expires 26 March 2027 [Page 1] Internet-Draft BM for SR September 2026 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. Relationships with RFC 2544, RFC 5180, RFC 5695, RFC 6201, RFC 9004 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Test Methodology . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Control Plane Support . . . . . . . . . . . . . . . . . . 7 3.3. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 9 3.4. IP Addresses . . . . . . . . . . . . . . . . . . . . . . 11 3.5. Trial Duration . . . . . . . . . . . . . . . . . . . . . 12 3.6. Traffic Verification . . . . . . . . . . . . . . . . . . 12 3.7. Back-to-Back Frame Tests . . . . . . . . . . . . . . . . 13 4. Reporting Format . . . . . . . . . . . . . . . . . . . . . . 14 5. SR Forwarding Benchmarking Tests . . . . . . . . . . . . . . 16 5.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . 17 5.1.1. Throughput of a Source Edge Node . . . . . . . . . . 18 5.1.2. Throughput of a Transit Segment Endpoint Node . . . . 18 5.1.3. Throughput of a Destination Edge Node . . . . . . . . 19 5.1.4. Throughput of an Ordinary Transit Node . . . . . . . 20 5.2. Buffer Time . . . . . . . . . . . . . . . . . . . . . . . 21 5.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 21 5.5. System Recovery . . . . . . . . . . . . . . . . . . . . . 22 5.6. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.7. SR Policy Scaling . . . . . . . . . . . . . . . . . . . . 23 6. Operational Considerations . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 10.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Fioccola, et al. Expires 26 March 2027 [Page 2] Internet-Draft BM for SR September 2026 1. Introduction Segment Routing (SR), defined in [RFC8402], leverages the source routing approach. A 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 of an 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-enabled networks. This document includes benchmarking specifications which are for use in isolated test environments only and not for testing Internet paths in deployed networks, as also highlighted in [RFC6815]. The SR architecture can be instantiated on two underlying data planes: SR over MPLS (SR-MPLS) [RFC8660] and SR over IPv6 (SRv6) [RFC8754]. SRv6 has a variant with compressed SID [RFC9800]. SR can be directly applied to the Multiprotocol Label Switching (MPLS) architecture [RFC8660]. A segment is encoded as an MPLS label. An SR Policy is instantiated as a stack of labels. SR can be applied to the IPv6 architecture with a dedicated type of routing header called the Segment Routing Header (SRH) [RFC8754]. An instruction is associated with a segment and encoded as an IPv6 address, as defined in [RFC8754] and [I-D.ietf-6man-sidlist-clarification]. An SRv6 segment is also called an SRv6 SID. An SR Policy is instantiated as an ordered list of SRv6 SIDs in the SRH. The active segment is indicated by the Destination Address (DA) of the packet. A few compressed SIDs may be directly populated into the DA according to [RFC9800]. Fioccola, et al. Expires 26 March 2027 [Page 3] Internet-Draft BM for SR September 2026 The SID stack in the scope of this document has a minimum of two entries, e.g. two SIDs. However, it is recommended that the tests described in the next sections can be applied to label stacks with more than two SIDs. The reason for having a minimum of two SIDs, hence two labels, is to simulate a SID list (i.e., explicit steering of a packet flow through different paths or nodes). Testing should be performed up to the maximum SID depth supported or claimed by the equipment. This approach allows to identify the performance impact of a large SID list; ideally, all SID depths between two SIDs and the maximum SID depth should be tested. When using compressed SIDs, it is recommended to test a SID list large enough to fill at least one compressed SID container (i.e., all 128 bits) according to the chosen compression method. This document is limited to underlay. For SR-MPLS, it is tested MPLS label Push, label Swap, Ultimate Hop Popping (UHP), Label Pop (Unlabeled or Aggregate) and Penultimate Hop Popping (PHP). For SRv6, it is tested Headend encapsulations (H.Encaps.xxx), segment Endpoints (End, End.X), Endpoints with decapsulations (End.Dxxx) and Binding (End.Bxxx). Compressed SID [RFC9800] (both SRH-based and SRH-less compression) is also considered in this document. Services (e.g. Layer 2 or Layer 3 VPNs), typically encoded by the last SID in the stack, are out of the scope of this document. The purpose of this document is to describe a methodology specific to the benchmarking of Segment Routing. Such methodology leverages [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]. This document makes use of the terms defined in [RFC8402]. 2. Relationships with RFC 2544, RFC 5180, RFC 5695, RFC 6201, RFC 9004 This document leverages [RFC2544], [RFC5180], [RFC5695], [RFC9004], and [RFC6201] reusing or expanding their methodologies to include specific performance tests for SR. There are few differences from these documents and these are detailed below. [RFC2544] establishes a standardized benchmarking methodology to measure and report the performance characteristics of network devices. Fioccola, et al. Expires 26 March 2027 [Page 4] Internet-Draft BM for SR September 2026 [RFC5180] provides benchmarking methodology recommendations that address IPv6-specific aspects, such as evaluating the forwarding performance of traffic containing extension headers. [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. [RFC6201] specifies a methodology for characterizing reset (and reset time) for benchmarking forwarding devices. [RFC9004] revise the specific procedures to measure the Back-to-Back Frames benchmark, to determine physical device buffer capacities. This document mainly refers to the procedures of [RFC5695] for both SR-MPLS and SRv6 benchmarking tests. The primary differences in the test methodologies defined in this document when compared to [RFC2544], [RFC5180], [RFC5695], and [RFC9004] are as follows. * For SR-MPLS, the tests use frame characteristics similar to Section 4.1.5 of [RFC5695], except for a bigger MTU to accommodate a MPLS stack with 2 or more SIDs. * For SRv6, the IPv6 benchmarking defined in [RFC5180] has been taken as a reference only for the IPv6-specific aspects (e.g. IPv6 addressing, extension headers). * Both TCP and UDP tests are considered for SR benchmarking, as in [RFC2544], while [RFC5695] only considers UDP tests. * Differently from [RFC2544] and [RFC5695], the trial duration has been modified to take into account session/adjacency hold time for respective protocol configuration in order to maintain a stable control plane. * This document suggests to use a test time shorter than recommended by [RFC9004] in line with the typical SR DUT. * Equal-Cost Multi-Path (ECMP) and weighted ECMP (wECMP) tests, which were excluded in [RFC5695], have been added for scaling tests. 3. Test Methodology Fioccola, et al. Expires 26 March 2027 [Page 5] Internet-Draft BM for SR September 2026 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 levels based on the number of interfaces served. The Device Under Test (DUT) may have oversubscribed interfaces, therefore, traffic for such interfaces should be proportionally decreased according to the specific DUT oversubscription ratio (R). Where a forwarding engine serves interfaces whose aggregate line rate exceeds the engine's forwarding capacity by a factor R, each interface SHOULD be loaded in reverse proportion to R so that the aggregate offered load equals the engine's capacity. R and the resulting per-interface offered load MUST be reported. Tests SHOULD be done with bidirectional traffic that better reflects the real environment for SR nodes, anyway unidirectional traffic can be used too. It is OPTIONAL to choose a non-equal proportion for upstream and downstream traffic for some specific aggregation nodes. The RECOMMENDED topology for SR Forwarding Benchmarking should be the same used for MPLS benchmarking, as described in Section 4 of [RFC5695]. A simplified view is reported in Figure 1 for reference. Other setups can be followed to accommodate specific needs. It is out of scope of this document to identify those. +----------+ +---------| |<---------+ | +-------| Tester |<-------+ | | | +-----| |<-----+ | | | | | +----------+ | | | | | | | | | | | | +--------+ | | | | | +----->| |-------+ | | | +------->| DUT |---------+ | +--------->| |-----------+ +--------+ Figure 1: Test Environment for SR 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. Also, ports may be confused with transport layers (e.g., TCP/UDP) terms. Interface numbers involved in the tests and their oversubscription ratio MUST be reported. This document is benchmarking only "source routing". Hence, SIDs represent only prefix and adjacency segments, Fioccola, et al. Expires 26 March 2027 [Page 6] Internet-Draft BM for SR September 2026 that may be carried, for example, in IGP extensions. For the case of SRv6, as mentioned above, the DUT is exercised for Headend encapsulation (H.Encaps.xxx), segment Endpoint (End, End.X), Endpoints with decapsulations (End.Dxxx) or Binding (End.Bxxx). For, SRv6, it is OPTIONAL to test any extension headers (fragmentation, hop-by-hop, destination options, etc.) in addition to the SRH [RFC8754], if present. It is RECOMMENDED to follow Section 5.3 of [RFC5180] to introduce other extension headers in proportions 1%, 10%, 50% that may better reflect real use cases. Other ratios may be used to accommodate special benchmarking cases. SR may be implemented as a software network function in a Network Function Virtualization (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. These are not repeated here. Special capabilities SHOULD NOT exist in the DUT specifically for benchmarking purposes. 3.2. Control Plane Support SRv6 and SR-MPLS have different terminology that is inherited from [RFC8402] for SR-MPLS and extended by [RFC8986] for SRv6. As specified in [RFC8402], in the context of an IGP-based distributed control plane, two topological segments are defined: the IGP- Adjacency segment and the IGP-Prefix segment; while in the context of a BGP-based distributed control plane, two topological segments are defined: as the BGP peer segment and the BGP Prefix segment. 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: Penultimate Segment Pop (PSP), Ultimate Segment Pop (USP), and Ultimate Segment Decapsulation (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, [RFC8667] for SR-MPLS and [RFC9352] for SRv6 * OSPFv2 Extensions to Support Segment Routing, [RFC8665] for SR- MPLS. Fioccola, et al. Expires 26 March 2027 [Page 7] Internet-Draft BM for SR September 2026 * OSPFv3 Extensions to Support Segment Routing, [RFC8666] for SR- MPLS and [RFC9513] for SRv6 * Segment Routing Prefix Segment Identifier Extensions for BGP [RFC8669] * Segment Routing Policy Architecture [RFC9256]. * Advertising Segment Routing Policies in BGP [RFC9830]. * Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing [RFC8664]. One of the options above SHOULD be used for the SID stack construction. Another possibility might be the static routing, but it is not a realistic production scenario. It is RECOMMENDED to test SR policy with a SID depth comprised between two SIDs and the maximum SID depth supported by the particular DUT. The long SID list may be needed for extensive traffic engineering or other scenarios. If the DUT advertises its Maximum SID Depth capabilities, the tester can read the maximum SID list supported for encapsulation, decapsulation and SRH deletion in transit: for SRv6 from Section 4 of [RFC9352] (IS-IS), Section 4 of [RFC9513] (OSPFv3), or Sections 3.2 and 4.3 of [RFC9514] (BGP-LS); for SR-MPLS from [RFC8491] (IS-IS), [RFC8476] (OSPF), or [RFC8814] (BGP-LS). It is not required to test the SID list for operations beyond the announced capabilities on the DUT. Optionally, if there is an interest, it may be tested how the DUT reacts in this situation. It is RECOMMENDED that the top SID of the list emulates a traffic engineering scenario. For example, the top SID can be associated with an emulated next hop of the SR path. In all cases, the SID stack configuration SHOULD happen before packet forwarding is started. Control plane convergence speed is not the subject of the present tests. It is important to point out that the control plane is independent of the SID list compression method used, if any. The SID list construction method and SR policy construction method used MUST be reported according to Section 4. This is to ensure that control plane is stable during the tests and does not contribute to the forwarding performance, as also highlighted in Section 4.1.2 of [RFC5695] and Section 11.3 of [RFC2544]. Fioccola, et al. Expires 26 March 2027 [Page 8] Internet-Draft BM for SR September 2026 3.3. Frame Formats and Sizes SR tests use Frame characteristics similar to Section 4.1.5 of [RFC5695], except the need for a bigger MTU to accommodate SRH or MPLS SID stack. It is assumed that MTU is big enough to accommodate all frame sizes listed below. Fragmentation is not an option for Transit Segment Endpoint tests because it is prohibited in transit by Section 4.5 of [RFC8200]. Fragmentation of IPv4 packet is not considered for source nodes as it is not usually done for MPLS service and it is not implemented for SRv6 services. [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], this document mandates the payload to include an IP packet (IPv6 or IPv4) to better represent the real environment. The test can be performed by selecting one or more payload sizes ranging from the minimum Ethernet payload (46 B) to the maximum payload size (e.g. 1500 B) or beyond this value (e.g. Jumbo Frames). It is to be noted that, in case of IPv6, the Ethernet payload must take into account the whole IPv6 stack (including TCP or UDP), therefore it could be necessary to enlarge the minimum payload size to accommodate the needed space for the IPv6 environment. For the headend nodes, the frame size of the incoming interface(s) may be smaller than the frame size of the outgoing interface(s). The DUT MUST support the possible increased frame size due to the creation of SR-MPLS and SRv6 packets. It is assumed that the test would be for Ethernet media only. Other media are possible, as stated in Section 4.1.5.2 of [RFC5695] for Packet Over Synchronous Optical Network (POS). Some Layer 2 technologies, like POS or Point-to-Point (PPP), have bit- or byte- stuffing, and [RFC4814] may help to calculate real performance accurately. The most popular Layer 2 technology for SR is Ethernet, and it does not have stuffing. It is RECOMMENDED to choose at least one frame size from the list 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 octets more than the fixed chunk size (the second chunk would have a very low memory utilization). The resulting Ethernet frame structure is depicted in Figure 2 and Figure 3. Note that the sizes are expressed in bytes (B). Fioccola, et al. Expires 26 March 2027 [Page 9] Internet-Draft BM for SR September 2026 <---18B---><-n*4B-><---------46-1500-9000B-----------> +---------+--------+---------+-----------------------+ | | MPLS | | | | | Layer 2 | Labels | Layer 3 | Layer 4 | High layers | +---------+--------+---------+-----------------------+ Figure 2: Ethernet Frame Structure for SR-MPLS <---18B---><-40B-><8+n*16B><--------46-1500-9000B-----------> +---------+-------+-------+---------+-----------------------+ | | Outer | | Inner | | | | Layer 2 | IPv6 | SRH | Layer 3 | Layer 4 | High layers | +---------+-------+-------+---------+-----------------------+ Figure 3: Ethernet Frame Structure for SRv6 RECOMMENDED payload sizes (encapsulated packet with Layer 3 headers and above) are the following: * Ethernet Minimum payload size: 46 B * DUT Minimal Wire Speed frame size: typically 128-256 B (it depends on the DUT specification) * Ethernet Maximum payload size: 1500 B * DUT typical Jumbo Frame size: 9000 B (or any claimed maximum) Note that n*4 octets should be added in the previous calculations for SR-MPLS tests to accommodate MPLS labels needed for respective tests. While 40+8+n*16 bytes should be added for SRv6 tests, where 40 octets are added for the outer (tunnel) IPv6 header, 8 octets are added for the SRH header itself, and n is the number of SIDs multiplied by 16 octets SID size, one SID may have a few compressed SIDs. This calculation is reported just for reference and it is related to the base SR-MPLS and SRv6 packets. Therefore, for each specific case, a new calculation should be done. Fioccola, et al. Expires 26 March 2027 [Page 10] Internet-Draft BM for SR September 2026 The typical frame size values are listed above for the DUT minimal wire speed and maximum, 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. As also mentioned in Section 4.1.6 of [RFC5695], the Time-to-Live (TTL) or Hop Limit MUST be large enough so that the frame traverses the DUT without expiring given the number of segments. For SR-MPLS, the TTL propagation model in use MUST be reported along with the values used. 3.4. IP Addresses IANA reserved an IPv6 address block 2001:2::/48 [RFC6890] for use with IPv6 benchmark testing (see Section 8 of [RFC5180]) and block 198.18.0.0/15 [RFC6890] for IPv4 benchmark testing. Source and destination addresses for the test streams SHOULD belong to the IPv6 range assigned by IANA. Other addresses MAY be used to accommodate customized setups. The type of infrastructure protocol (IPv6 vs IPv4) that should be used for IGP and BGP in the tests should be chosen according to the test purpose and requirements. For SRv6, the choice of the Locator blocks depends on the type of tests and its format MUST be reported. As it is discussed in Section 2.1, there is a need to load the whole forwarding engine (on all interfaces). [RFC4814] discusses the importance of having many flows with address randomization for acceptable hash-based load balancing that is implemented in all forwarding engines. Note that IPv6 flow label randomization MUST be used, according to [RFC8754]. In the context of this document, randomization may also be applied to SIDs, because SIDs may be used for hashing for the choice of 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 for SR-MPLS. Fioccola, et al. Expires 26 March 2027 [Page 11] Internet-Draft BM for SR September 2026 3.5. Trial Duration The test portion of each trial must take into account the respective protocol configuration. The test portion of each trial SHOULD be at least 10 seconds longer than the session/adjacency hold time for respective protocol configuration to verify that the DUT is able to maintain a stable control plane when the data-forwarding plane is under stress. Otherwise, there is a risk that routing control plane is affected by the stressed data plane. IGPs 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. 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. As stated in Section 10 of [RFC2544]: "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 any case, 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 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." Section 4.1.8 of [RFC5695] highlights that "In all cases, sent traffic MUST be accounted for, whether it was received on the wrong port, the correct port, or not received at all." Many test tools may, by default, only verify that they have received the embedded signature on the receive side. However, some tests assume headers modifications (push or pop the MPLS label stack, add or delete SRH, replace destination address, adjust "segments left"). All packets MUST be checked for the correct header values on the receiving side. Fioccola, et al. Expires 26 March 2027 [Page 12] Internet-Draft BM for SR September 2026 In addition, Section 4.1.8 of [RFC5695] requires that "the presence or absence of the MPLS label stack, every field value inside the label stack, if present, ethertype (0x8847 or 0x8848 versus 0x0800 or 0x86DD), frame sequencing, and frame check sequence (FCS) MUST be verified in the received frame." This is to verify that the packets received by the test tool carry the expected MPLS label. 3.7. Back-to-Back Frame Tests The 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 tests. 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. At the time of publication, typical buffers range between 30ms and 100ms. It is suggested 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. For benchmarking, paths SHOULD NOT employ Active Queue Management (AQM) including the use of Random Early Detection (RED), weighted RED (WRED) or other scheduling methods that would result in packet drop before the corresponding buffer is filled. Any queuing or policing applied on the tested path MUST be specified in the test results. Queuing SHOULD be configured for the tail drop which is, typically, a non-default configuration, otherwise it may happen that packets are randomly dropped and that would affect the performance statistics of the forwarding engine. The back-to-back frame test is rather complex and expensive (50 runs for every frame size). Hence, it is OPTIONAL for both SR-MPLS and SRv6. Fioccola, et al. Expires 26 March 2027 [Page 13] Internet-Draft BM for SR September 2026 4. Reporting Format There are a few parameters that must be changed and added to accommodate SR tests. Reporting parameters inherited from [RFC2544]: * Throughput in bytes per second and frames per second * Latency (milliseconds, microseconds, nanoseconds etc.) * Frame loss rate as the percentage of the frames that are dropped based on the offered load * Recovery time in milliseconds Reporting parameters inherited from [RFC5695]: * 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) Reporting parameters inherited from [RFC6201]: * Reset Time in milliseconds Reporting parameters inherited from [RFC9004]: * Buffer Time as burst of frames in units of time Parameters changed from [RFC5695]: * SR Forwarding Operations (PUSH/NEXT/CONTINUE). * Label Distribution protocol and IGP are the same in the context of SR. Hence, it can be called "Label distribution methods" for SR- MPLS or "Locator and Endpoint behaviors methods" for SRv6. New parameters that MUST be reported are: * Interface numbers involved for ingress and egress in the tests and their respective oversubscription ratio. Fioccola, et al. Expires 26 March 2027 [Page 14] Internet-Draft BM for SR September 2026 * Upstream/downstream traffic proportion (equal bidirectional or some other split). * Number of Segments considered in the SID list. * Number of Segment Lists considered for the same Candidate Path. * Number of Candidate Paths considered for an SR Policy. * Number of SR Policies considered for a DUT. * Locator blocks format, Function, Argument. * Compression method used: None, NEXT-CSID, REPLACE-CSID and compressed SID size. In case of compression, it must be specified if it is SRH or SRH-less compression. * SRH TLV used, if any. * Behavior (H.Encaps, etc.) and Flavor (PSP, USP, USD) used for SRv6 tests (according to [RFC8986]). * SR Policy construction method (PCEP, BGP, manual configuration). * SR Policy steering modes (according to [RFC9256]). * Type of the payload (IPv6/IPv4, UDP/TCP). * TTL propagation model. * ECMP related information: ECMP hashing algorithm, fields used, list of interfaces used for load balancing. * Time to recover from the overload state * Time to recover from the reset state and reset type (particular module in reset) * Tested buffer 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). In such case, these may be reported one time. Note that individual test cases may have additional reporting information that may refer to other RFCs. Fioccola, et al. Expires 26 March 2027 [Page 15] Internet-Draft BM for SR September 2026 5. SR 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. However, 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 packet forwarding engines may be huge that may need to involve many testers to sufficiently load the DUT as presented in Figure 4. Then results correlation and recalculation of the real performance would be an additional burden. +----------+ +-------| Tester1 |<-------+ | +-----| |<-----+ | | | +----------+ | | | | | | | | +--------+ | | | +----->| |-------+ | +------->| DUT |---------+ +------->| |---------+ | +----->| |-------+ | | | +--------+ | | | | | | | | +----------+ | | | +-----| Tester2 |<-----+ | +-------| |<-------+ +----------+ Figure 4: Many Testers 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 Fioccola, et al. Expires 26 March 2027 [Page 16] Internet-Draft BM for SR September 2026 offered frame rate with a zero-frame loss (Non Drop Rate). 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 to measure the resulting maximum number. It can also be tested for 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, and Maximum number of Segments that can be pushed and hashed by the SR node for load-balancing. The test could be done to assess more construction methods and consequently report the results as specified in Section 4. In addition, it could be possible to test the ECMP behavior of an SR Policy. An SR Policy with one active Candidate Path (CP) but with variable Segments Left (SL), SIDs, weights can be tested to check the overall performance and ECMP limits. All the related parameters must be reported as specified in Section 4. Note that the test can also be done in the case of Compressed SRv6 Segment List Encoding [RFC9800]. 5.1. Throughput This section contains a description of the tests that are related to the characterization of a DUT's SR traffic forwarding throughput. The list of segments for SR-MPLS is represented as a stack of MPLS labels. There are three distinct operations to be tested: PUSH, NEXT and CONTINUE. These correspond to the three forwarding operations of an MPLS packet: PUSH (or LSP Ingress), POP (or LSP Egress), or SWAP. The list of segments for SRv6 is represented as a list of IPv6 addresses, included in the SRH. Three distinct types of nodes are involved in segment routing networks that may represent four different cases. Fioccola, et al. Expires 26 March 2027 [Page 17] Internet-Draft BM for SR September 2026 Note that the different operations are separately discussed only for throughput tests, but they are equally applicable to the other tests below. 5.1.1. Throughput of a Source Edge Node Objective: To obtain the DUT's Throughput during the packet processing of a Source Node, which is the PUSH forwarding operation. It is when the Source SR node, which corresponds to the headend node, encapsulates a received packet into SR-MPLS or SRv6. In the case of SR-MPLS, the SID list is PUSHed to the MPLS label stack. It is similar to label Push or LSP Ingress forwarding operation, as per Section 6.1.1 of [RFC5695] and Section 26.1 of [RFC2544]. In the case of SRv6, the received packet is encapsulated in an IPv6 outer header including the SRH as a Routing Extension 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. Additionally, the router could be configured for NEXT-CSID or REPLACE-CSID compression. Procedure: Similar to Section 6.1 of [RFC5695] or Section 26.1 of [RFC2544] with extension to test a SID list with at least 2 SIDs. The SID list can be from 2 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 the SID stack construction, as per Section 3.2, on its receive and transmit interfaces towards the DUT. Reporting Format: A table with all parameters specified in Section 4 and in Section 26.1 of [RFC2544]. 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, which is the NEXT forwarding operation. It is when the SR Segment Endpoint node receives packets whose SID is locally configured as a segment. Fioccola, et al. Expires 26 March 2027 [Page 18] Internet-Draft BM for SR September 2026 In the case of SR-MPLS, it is equivalent to MPLS Label Swap or Ultimate Hop Popping (UHP), as per Section 6.1.2 of [RFC5695] and Section 26.1 of [RFC2544]. Non-reserved MPLS label values MUST be used. In the case of SRv6, 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 based on 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 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). Additionally, the router could be configured for NEXT-CSID or REPLACE-CSID compression. Procedure: Similar to Section 6.1 of [RFC5695] or Section 26.1 of [RFC2544] with extension to test a SID list with at least 2 SIDs. The SID list can be from 2 to N SIDs. N should 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 the SID stack construction, as per Section 3.2, on its receive and transmit interfaces towards the DUT. Reporting Format: A table with all parameters specified in Section 4 and in Section 26.1 of [RFC2544]. 5.1.3. Throughput of a Destination Edge Node Objective: To obtain the DUT's Throughput during the packet processing of a Segment Endpoint Node that needs decapsulation, which is the NEXT forwarding operation. In the case of SR-MPLS, it is equivalent to MPLS Label Pop (Unlabeled or Aggregate) or Penultimate Hop Popping (PHP), as per Section 6.1.3, 6.1.4, and 6.1.5 of [RFC5695] and Section 26.1 of [RFC2544]. Fioccola, et al. Expires 26 March 2027 [Page 19] Internet-Draft BM for SR September 2026 In the case of SRv6, it is when the SR Segment Endpoint node receives packets whose IPv6 destination address is locally configured as a segment and SL in the SRH header is zero. The SR Segment Endpoint node decapsulates the packet, and forwards the packet based on the respective forwarding table (of the inner packet). The RECOMMENDED endpoint decapsulation behavior is End with the USD flavor, in case of interest for another flavor (PSP, USP) it is OPTIONAL to test it with proper reporting. Additionally, the router could be configured for NEXT-CSID or REPLACE-CSID compression. Procedure: Similar to Section 6.1 of [RFC5695] or Section 26.1 of [RFC2544] with extension to test a SID list with at least 2 SIDs. The SID list can be from 2 to N SIDs. N should 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 the SID stack construction, as per Section 3.2, on its receive and transmit interfaces towards the DUT. Reporting Format: A table with all parameters specified in Section 4 and in Section 26.1 of [RFC2544]. 5.1.4. Throughput of an Ordinary Transit Node Objective: To obtain the DUT's Throughput during the packet processing of a Transit Node. It is the CONTINUE forwarding operation and in this case 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. This test is possible only for SRv6, SR-MPLS requires all transit nodes to support MPLS. Procedure: Similar to Section 6.1 of [RFC5695] or Section 26.1 of [RFC2544] with extension to test a SID list with at least 2 SIDs. The SID list can be from 2 to N SIDs. N should 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 the SID stack construction, as per Section 3.2, on its receive and transmit interfaces towards the DUT. Reporting Format: A table with all parameters specified in Section 4 and in Section 26.1 of [RFC2544]. Fioccola, et al. Expires 26 March 2027 [Page 20] Internet-Draft BM for SR September 2026 5.2. Buffer Time The back-to-back frame test is OPTIONAL. If done, it 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 SR forwarding operations. Procedure: Should be inherited from [RFC9004] for a SID list with at least 2 SIDs. Despite the simple general idea for filling the buffer until the tail drop, [RFC9004] has many details for procedure, precautions, and calculations that would be too lengthy to copy here. Reporting Format: A table with all parameters specified in Section 4 and in Section 7 of [RFC9004]. 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 SR forwarding operations (PUSH, NEXT, CONTINUE). It is RECOMMENDED to test all three (for SR-MPLS) or four (for SRv6) 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 with all parameters specified in Section 4 and in Section 26.2 of [RFC2544]. 5.4. Frame Loss Objective: To determine the frame-loss rate (as defined in Section 6.3 of [RFC5695] and Section 26.3 of [RFC2544]) for each of the SR forwarding operations of a DUT throughout the entire range of input data rates and frame sizes. It is RECOMMENDED to test all three (for SR-MPLS) or four (for SRv6) test types discussed in Section 5.1. An additional objective could be to assess the frame loss under the overload conditions. It may be that the overloaded forwarding engine would forward less traffic than in the situation close to the overload. Procedure: Similar to Section 5.1. Fioccola, et al. Expires 26 March 2027 [Page 21] Internet-Draft BM for SR September 2026 Reporting Format: A table with all parameters specified in Section 4 and in Section 26.3 of [RFC2544]. 5.5. System Recovery Objective: To characterize the speed at which a DUT recovers from an overload condition for each of the SR forwarding operations. It is RECOMMENDED to test all three (for SR-MPLS) or four (for SRv6) test types discussed in Section 5.1. Procedure: Similar to Section 6.4 of [RFC5695] or Section 26.5 of [RFC2544]. Send a stream of frames at a rate of 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 the difference between the two Timestamps. The test MUST be repeated several times and the average of the recorded values being reported. Reporting Format: A table with all parameters specified in Section 4 and in Section 26.5 of [RFC2544]. 5.6. Reset Objective: To characterize the speed at which a DUT recovers from a hardware or software reset for each of the SR 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, and 3) power interruption. All resets may be partial, i.e., only for a particular part of hardware (line card) or software (module). Special 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 MUST be treated as different. It is OPTIONAL to test all three (for SR-MPLS) or four (for SRv6) test types discussed in Section 5.1, typically they would give the same result. Fioccola, et al. Expires 26 March 2027 [Page 22] Internet-Draft BM for SR September 2026 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 with all parameters specified in Section 4 and in Section 1.4 of [RFC6201]. All type of reset tests are OPTIONAL. 5.7. SR Policy Scaling Objective: To check the scaling capabilities of a DUT as it acts as the SR Policy headend where an SR Policy is configured. The goal is to verify the Maximum SID Depth (MSD) and then calculate the maximum number of supported Segment Lists per CP, maximum number of CPs in a single SR Policy, maximum number of supported SR policies. Note that this test is focused on the forwarding scaling capabilities. However, in some steps, it is necessary to verify that everything is installed and activated properly but without measuring the control plane performance. Also, ECMP/wECMP benchmarking is out of scope and it is only used to verify the expected function for SR. Procedure: 1) Testing of the baseline. Configure a single SR Policy with just one CP and different Segment Lists with a number of SIDs as baseline (e.g., 3 SIDs); verify that the SR Policy is installed; prepare traffic flow and initiate it; then verify that traffic flows successfully. The expected result is that there is no packet loss. 2) Testing the SID scale per Segment List. The setup is the same as the previous test but Segment List length is equal to MSD. All the other steps are same as the previous test. 3) Testing Segment List scale per CP. The setup is the same as the previous test except that X Segment Lists are created, and the test is repeated for each value of X (e.g., X=10,15,20,etc.). All Segment Lists are in the same CP. On the first iteration each Segment List has a number of SIDs as baseline, each Segment List have the same weight (ECMP testing). On the second iteration the Segment List length is equal to MSD. The scope is to verify that traffic flows between headend nodes and ECMP is working. The test can be repeated with different weights per each Segment List, testing wECMP. The result is to find out the maximum number of supported Segment Lists per CP. It also implies the verification that ECMP/wECMP works as expected on that maximum Segment List scale, with no traffic drops. Fioccola, et al. Expires 26 March 2027 [Page 23] Internet-Draft BM for SR September 2026 4) Testing CP scale in one SR Policy. Y CPs are created in one SR Policy where Y=10,15,20,etc. (each per different test run), set higher Preference for one of CPs. Verify that all CPs are configured but that only one is Active (with higher Preference). Use the minimal Segment List length, then the maximum Segment List length, according to the previous test. Verify that traffic flows, with correct ECMP/wECMP and no drops. The result is to find out the maximum number of CPs in a single SR Policy where the Active CP is working properly with any Segment Lists, ECMP/wECMP behavior, and without traffic drops. 5) Testing SR Policies scale (can be combined with composite SR Policy testing as subcase, if supported). Create Z SR Policies, where Z=10,15,20,etc., then apply CPs per each SR Policy, from one CP to the maximum tested amount of CPs from the previous test, create different color communities for steering traffic into those policies towards one or many Egress headend nodes, start traffic flows per each SR Policy (matching all Segment Lists/CP variances above), verify traffic flows, absence of drops, correct ECMP/ wECMP. The result is to find out the maximum number of supported SR Policies (max Z). If composite SR Policy is supported combine all created SR Policies in one composite, then make verification. Reporting Format: A table with all parameters specified in Section 4. Note that all the ECMP parameters and hash fields must be carefully reported to guarantee the reproducibility. 6. Operational Considerations Section 5.7 of [I-D.ietf-opsawg-rfc5706bis] highlights the need to consider information that would be useful to determine the performance characteristics of a deployed system using the target protocol. In this regard, the test environment for the benchmarking of networking technologies, such as SR-MPLS and SRv6, should be considered not confidential. Indeed, a detailed description of the test setup and related execution is crucial to allow reproducing and repeating the tests by the different stakeholders. There are several advantages for the community if test reproducibility and repeatability are guaranteed: * test modifications can be easier because some configurations could be reused, * new tests can be developed in case of new requirements and it is possible to start from known information, Fioccola, et al. Expires 26 March 2027 [Page 24] Internet-Draft BM for SR September 2026 * the tests can be checked by the DUT vendor, that may try to fix bugs or improve performance, * the tests may be repeated after vendor hardware upgrade or software update, * the tests could be shared to improve industry practices. Also, in addition to the parameters specified in Section 4, it is important to record and document in detail the tests for the community and provide all the relevant information, such as: * detailed description of the test environment and setup, * versions of software and hardware for the DUT and all the equipment used (e.g., generator, analyzer,...), * traffic generator and traffic analyzer configurations for every test (it may also include specialized scripts developed specifically for the test), * DUT configuration for every test (it would be desired to have a unified configuration for all tests, if possible), * some DUT or traffic generator/analyzer configurations may be not obvious (it may be useful to document at least the challenging points encountered during tests preparation), * the list of all resources (like URLs or other documentation) that were used during the test preparation, * contacts of people involved in the test. 7. 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 specifically for benchmarking purposes. Any implications for network security arising from the DUT 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 traffic to the test management network. Fioccola, et al. Expires 26 March 2027 [Page 25] Internet-Draft BM for SR September 2026 8. IANA Considerations This document has no IANA requests. 9. Acknowledgements The authors would like to thank Al Morton, Gabor Lencse, Boris Khasanov, Gyan Mishra, Carsten Rossenhoevel, Maciek Konstantynowicz, Dan Voyer, Libin Liu for the precious comments and suggestions. 10. References 10.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, . [RFC6201] Asati, R., Pignataro, C., Calabria, F., and C. Olvera, "Device Reset Characterization", RFC 6201, DOI 10.17487/RFC6201, March 2011, . Fioccola, et al. Expires 26 March 2027 [Page 26] Internet-Draft BM for SR September 2026 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 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, . [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019, . [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019, . [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019, . Fioccola, et al. Expires 26 March 2027 [Page 27] Internet-Draft BM for SR September 2026 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, A., and H. Gredler, "Segment Routing Prefix Segment Identifier Extensions for BGP", RFC 8669, DOI 10.17487/RFC8669, December 2019, . [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, . [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, . [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, . [RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", RFC 9513, DOI 10.17487/RFC9513, December 2023, . [RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding", RFC 9800, DOI 10.17487/RFC9800, June 2025, . 10.2. Informative References Fioccola, et al. Expires 26 March 2027 [Page 28] Internet-Draft BM for SR September 2026 [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-6man-sidlist-clarification] Farrel, A. and S. Krishnan, "Clarifying SRv6 SID List Processing", Work in Progress, Internet-Draft, draft-ietf- 6man-sidlist-clarification-03, 19 May 2026, . [I-D.ietf-opsawg-rfc5706bis] Claise, B., Clarke, J., Farrel, A., Barguil, S., Pignataro, C., and R. Chen, "Guidelines for Considering Operations and Management in IETF Specifications", Work in Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-07, 7 September 2026, . [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, "Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful", RFC 6815, DOI 10.17487/RFC6815, November 2012, . [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, December 2018, . [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, . [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, . Fioccola, et al. Expires 26 March 2027 [Page 29] Internet-Draft BM for SR September 2026 [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., and N. Triantafillis, "Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State", RFC 8814, DOI 10.17487/RFC8814, August 2020, . [RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., Bernier, D., and B. Decraene, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December 2023, . [RFC9830] Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, P., and D. Jain, "Advertising Segment Routing Policies in BGP", RFC 9830, DOI 10.17487/RFC9830, September 2025, . Authors' Addresses Giuseppe Fioccola Huawei Technologies Viale Martesana, 12 20055 Vimodrone (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 Viale Martesana, 12 20055 Vimodrone (Milan) Italy Email: paolo.volpato@huawei.com Luis Miguel Contreras Murillo Telefonica Spain Email: luismiguel.contrerasmurillo@telefonica.com Fioccola, et al. Expires 26 March 2027 [Page 30] Internet-Draft BM for SR September 2026 Bruno Decraene Orange France Email: bruno.decraene@orange.com Fioccola, et al. Expires 26 March 2027 [Page 31]