idnits 2.17.1 draft-vfv-bmwg-srv6-bench-meth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8402], [RFC5180], [RFC2544]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2022) is 782 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-12 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-03 == Outdated reference: A later version (-06) exists of draft-ietf-spring-segment-protection-sr-te-paths-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-19 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BMWG G. Fioccola 3 Internet-Draft E. Vasilenko 4 Intended status: Informational P. Volpato 5 Expires: September 8, 2022 Huawei Technologies 6 L. Contreras 7 Telefonica 8 March 7, 2022 10 Benchmarking Methodology for IPv6 Segment Routing 11 draft-vfv-bmwg-srv6-bench-meth-01 13 Abstract 15 This document defines a methodology for benchmarking Segment Routing 16 (SR) performance for Segment Routing over IPv6 (SRv6). It builds 17 upon [RFC2544], [RFC5180] and [RFC8402]. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 8, 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. SRv6 Forwarding . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Test Methodology . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. IGP and BGP Support . . . . . . . . . . . . . . . . . . . 6 64 3.3. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 6 65 3.4. Protocol Addresses . . . . . . . . . . . . . . . . . . . 6 66 3.5. Traffic with SRH . . . . . . . . . . . . . . . . . . . . 6 67 4. Reporting Format . . . . . . . . . . . . . . . . . . . . . . 7 68 5. SRv6 Forwarding Benchmarking Tests . . . . . . . . . . . . . 8 69 5.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.1.1. Throughput of a Source Node . . . . . . . . . . . . . 9 71 5.1.2. Throughput of a Segment Endpoint Node . . . . . . . . 9 72 5.1.3. Throughput of a Transit Node . . . . . . . . . . . . 9 73 5.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.3. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.4. System Recovery . . . . . . . . . . . . . . . . . . . . . 10 76 5.5. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 6. SR Policy: protection performance . . . . . . . . . . . . . . 11 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 10.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 Segment Routing (SR), defined in [RFC8402], leverages the source 89 routing paradigm. The headend node steers a packet through an SR 90 Policy [I-D.ietf-spring-segment-routing-policy], instantiated as an 91 ordered list of segments. A segment, referred to by its Segment 92 Identifier (SID), can have a semantic local to an SR node or global 93 within an SR domain. SR supports per-flow explicit routing while 94 maintaining per-flow state only at the ingress nodes to the SR 95 domain. 97 However, there is no standard method defined to compare and contrast 98 the foundational SR packet forwarding capabilities of network 99 devices. This document aims to extend the efforts of [RFC1242] and 100 [RFC2544] to SR network. 102 The SR architecture can be instantiated on two data-plane: SR over 103 MPLS (SR-MPLS) and SR over IPv6 (SRv6). This document is limited to 104 SRv6. 106 SR can be applied to the IPv6 architecture with a new type of routing 107 header called the SR Header (SRH) [RFC8754]. An instruction is 108 associated with a segment and encoded as an IPv6 address. An SRv6 109 segment is also called an SRv6 SID. An SR Policy is instantiated as 110 an ordered list of SRv6 SIDs in the routing header. The active 111 segment is indicated by the Destination Address (DA) of the packet. 113 For Segment Routing, PUSH, NEXT, and CONTINUE are operations applied 114 by the forwarding plane. 116 PUSH consists of the insertion of a segment at the top of the segment 117 list. In SRv6, the top of the segment list is represented by the 118 first segment in the SRH. 120 NEXT consists of the inspection of the next segment. The active 121 segment is completed and the next segment becomes active. In SRv6, 122 NEXT is implemented as the copy of the next segment from the SRH to 123 the destination address of the IPv6 header. 125 CONTINUE happens when the active segment is not completed; hence, it 126 remains active. In SRv6, the CONTINUE operation is the plain IPv6 127 forwarding action of a regular IPv6 packet according to its 128 destination address. 130 [RFC5180] provides benchmarking methodology recommendations that 131 address IPv6-specific aspects, such as evaluating the forwarding 132 performance of traffic containing extension headers. 134 The purpose of this document is to describe a methodology specific to 135 the benchmarking of Segment Routing. The methodology described is a 136 complement for [RFC5180]. 138 2. SRv6 Forwarding 140 In IPv6, a Prefix-SID is allocated in the form of an IPv6 address. 141 For the IPv6 data plane, a new type of IPv6 Routing Extension Header, 142 called Segment Routing Header (SRH) has been defined. The SRH 143 contains the Segment List as an ordered list of IPv6 addresses: each 144 address in the list is a SID. A dedicated field, referred to as 145 Segments Left, is used to maintain the pointer to the active SID of 146 the Segment List. 148 There are three different categories of nodes that may be involved in 149 segment routing networks. 151 The SR source node is the headend node and steers a packet into an SR 152 Policy. It can be a host originating an IPv6 packet or an SR domain 153 ingress router encapsulating a received packet into an outer IPv6 154 packet and inserts the SRH in the outer IPv6 header. It sets the 155 first SID of the SR Policy as IPv6 Destination Address of the packet. 157 The SR transit node forwards packets destined to a remote segment as 158 a normal IPv6 packet on the basis of the IPv6 destination address, 159 because the IPv6 destination address does not locally match with a 160 segment. Indeed, according to [RFC8200] the only node allowed to 161 inspect the Routing Extension Header (and therefore the SRH) is the 162 node corresponding to the destination address of the packet. 164 The SR segment endpoint node receives packets whose IPv6 destination 165 address is locally configured as a segment. It creates Forwarding 166 Information Base (FIB) entries for its local SIDs. For each SR 167 packet, it inspects the SRH and replaces the IPv6 destination address 168 with the new active segment. 170 The operations applied by the SRv6 packet processing are different at 171 the SR source, Transit and SR segment endpoint nodes. 173 The processing of the SR source node corresponds to the sequence of 174 the insertion of the SRH, composed of SIDs stored in reverse order, 175 and setting of the IPv6 Destination Address as first SID of the SR 176 Policy. It can be performed by encapsulating a packet into an outer 177 IPv6 packet with an SRH. Another possibility is to perform the 178 insertion of an SRH as a new header between the IPv6 header and the 179 Next Header (e.g. the Transport Layer Header, TCP or UDP). This 180 option only applies to IPv6 packets and it is especially suited in 181 case the source host is acting as headend node. 183 The processing of the SR segment endpoint node corresponds to the 184 detection of the new active segment, which is the next segment in the 185 Segment List and the related modification of the IPv6 destination 186 address of the outer IPv6 header. Then packets are forwarded on the 187 basis of the IPv6 forwarding table. 189 The processing of the SR transit node corresponds to normal 190 forwarding of the packets containing the SR header. In SRv6 the 191 transit nodes do not need to be SRv6 aware, as every IPv6 router can 192 act as an SRv6 transit node since any IPv6 node will maintain a plain 193 IPv6 FIB entry for any prefix, no matter if the prefix represents a 194 segment or not. 196 [I-D.ietf-spring-segment-routing-policy] specifies the concepts of SR 197 Policy and steering into an SR Policy. The header of a packet 198 steered in an SR Policy is augmented with the ordered list of 199 segments associated with that SR Policy. SR Policy state is 200 instantiated only on the headend node, that steers a flow into an SR 201 Policy. Indeed intermediate and endpoint nodes do not require any 202 state to be maintained. SR Policies can be instantiated on the 203 headend dynamically and on demand basis. Moreover, signaling can be 204 used in the case of a controller based deployment. For all these 205 reasons, SR Policies scale better than traditional TE mechanisms. 207 In addition to the basic SRv6 packet processing, the SRv6 Network 208 Programming model [RFC8986] describes a set of functions that can be 209 associated to segments and executed in a given SRv6 node. 211 Examples of such functions are described in [RFC8986], but, in 212 practice, any behavior and function can be associated to a local SID 213 in a node, in order to apply any special processing on the packet. 214 Obviously, the definition of a standardized set of segment routing 215 functions facilitates the deployment of SR domains with interoperable 216 equipment from multiple vendors. 218 According to [RFC8986], 128 bit SID can be logically split into three 219 fields and interpreted as LOCATOR:FUNCTION:ARGS (in short 220 LOC:FUNCT:ARG) where LOC includes the L most significant bits, FUNCT 221 the following F bits and ARG the remaining A bits, where 128=L+F+A. 222 The LOC corresponds to an IPv6 prefix (for example with a length of 223 48, 56 or 64 bits) that can be distributed by the routing protocols 224 and provides the reachability of a node that hosts a number of 225 functions. All the different functions residing in a node have a 226 different FUNCT code, so that their SIDs will be different. The ARG 227 bits are used to provide information (arguments) to a function. From 228 the routing point of view, the solution is scalable, as a single 229 prefix is distributed for a node, which implements a potentially 230 large number of functions and related arguments. 232 3. Test Methodology 234 3.1. Test Setup 236 The Device Under Test (DUT) is connected to the test ports on the 237 test tool according to [RFC2544]. 239 The test topology recommended for the SRv6 performance evaluation are 240 the same as IPv6 and are described in [RFC5180] and [RFC2544], in 241 both single-port and multi-port scenarios. Single-port testing 242 measures per-interface forwarding performance, while multi-port 243 testing measures the scalability of forwarding performance across the 244 entire platform. 246 3.2. IGP and BGP Support 248 It is RECOMMENDED that all of the ports on the DUT and test tool 249 support a Segment Routing extensions for dynamic Interior Gateway 250 Protocol (IGP) for routing such as IS-IS 251 [I-D.ietf-lsr-isis-srv6-extensions] and OSPF 252 [I-D.ietf-lsr-ospfv3-srv6-extensions] as well as Border Gateway 253 Protocol (BGP) [I-D.ietf-bess-srv6-services]. 255 As specified in [RFC8402], in the context of an IGP-based distributed 256 control plane, two topological segments are defined: the IGP- 257 Adjacency segment and the IGP-Prefix segment; while, in the context 258 of a BGP-based distributed control plane, two topological segments 259 are defined: the BGP peering segment and the BGP-Prefix segment. 261 The distribution method that is used (e.g. OSPF, IS-IS, BGP) MUST be 262 reported. 264 3.3. Frame Formats and Sizes 266 The tests for SRv6 will use the Frame characteristics as described in 267 [RFC5180]. 269 As specified in [RFC5180], for Ethernet, the following frame sizes 270 SHOULD be used for benchmarking over this media type: 64, 128, 256, 271 512, 1024, 1280, and 1518 bytes. Note that the recommended 1518-byte 272 frame size represents the maximum size of an untagged Ethernet frame. 273 A frame size commonly used in operational environments is 1522 bytes, 274 the max length for a VLAN-tagged frame. 276 3.4. Protocol Addresses 278 IANA reserved an IPv6 address block for use with IPv6 benchmark 279 testing (see [RFC5180]). IPv6 source and destination addresses for 280 the test streams SHOULD belong to the IPv6 range assigned by IANA. 282 3.5. Traffic with SRH 284 The extension header chain recommended in [RFC5180] for testing is: 285 Routing header (24-32 bytes), Destination options header (8 bytes), 286 Fragment header (8 bytes). This was considered a real-life 287 extension-header chain but it does not fit well for SRv6. 289 The length of the SRH is (n x 16 + 8) bytes, where n is the number of 290 segments. So, for most of the SRv6 application the recommendation of 291 [RFC5180] is not enough. In addition, it is worth mentioning that 292 the length of SRv6 packets is increased in Topology Independent Loop- 293 Free Alternate (TI-LFA) Fast Reroute (FRR), binding SID, and 294 microloop avoidance scenarios. 296 For SRv6, the extension header chain characteristics and length that 297 are used MUST be reported and the DUT MUST traverse the chain of 298 extension headers, so the impact on performance can be observed. 300 4. Reporting Format 302 There are new parameters that MUST be added to the parameters 303 specified in [RFC5180] and [RFC2544]: 305 o SRv6 types of nodes. 307 o Number of Segments considered in the SRH. 309 o Extension header chain (including SRH) characteristics and length. 311 o Global SIDs or Local SID forwarding behavior. 313 o SR Headend or Endpoint Behaviors eventually associated with a SID, 314 as specified in [RFC8986]. 316 For the sake of completeness, the following Figure 1 reports all the 317 SR Headend or Endpoint Behaviors, as defined in [RFC8986]. But, in 318 most cases, it may not be necessary to test all the services and it 319 is possible to select a subset. 321 +-------------------+-----------------------------------------------+ 322 | H.Encaps | SR Headend with Encapsulation in an SR Policy | 323 +-------------------+-----------------------------------------------+ 324 | H.Encaps.Red | H.Encaps with Reduced Encapsulation | 325 +-------------------+-----------------------------------------------+ 326 | H.Encaps.L2 | H.Encaps Applied to Received L2 Frames | 327 +-------------------+-----------------------------------------------+ 328 | H.Encaps.L2.Red | H.Encaps.Red Applied to Received L2 Frames | 329 +-------------------+-----------------------------------------------+ 330 | End | Endpoint | 331 +-------------------+-----------------------------------------------+ 332 | End.X | Endpoint with L3 cross-connect | 333 +-------------------+-----------------------------------------------+ 334 | End.T | Endpoint with specific IPv6 table lookup | 335 +-------------------+-----------------------------------------------+ 336 | End.DX6 | Endpoint with decapsulation and IPv6 cross- | 337 | | connect | 338 +-------------------+-----------------------------------------------+ 339 | End.DX4 | Endpoint with decapsulation and IPv4 cross- | 340 | | connect | 341 +-------------------+-----------------------------------------------+ 342 | End.DT6 | Endpoint with decapsulation and specific | 343 | | IPv6 table lookup | 344 +-------------------+-----------------------------------------------+ 345 | End.DT4 | Endpoint with decapsulation and specific | 346 | | IPv4 table lookup | 347 +-------------------+-----------------------------------------------+ 348 | End.DT46 | Endpoint with decapsulation and specific IP | 349 | | table lookup | 350 +-------------------+-----------------------------------------------+ 351 | End.DX2 | Endpoint with decapsulation and L2 cross- | 352 | | connect | 353 +-------------------+-----------------------------------------------+ 354 | End.DX2V | Endpoint with decapsulation and VLAN L2 | 355 | | table lookup | 356 +-------------------+-----------------------------------------------+ 357 | End.DT2U | Endpoint with decapsulation and unicast MAC | 358 | | L2 table lookup | 359 +-------------------+-----------------------------------------------+ 360 | End.DT2M | Endpoint with decapsulation and L2 table | 361 | | flooding | 362 +-------------------+-----------------------------------------------+ 363 | End.B6.Encaps | Endpoint bound to an SRv6 Policy with | 364 | | encapsulation | 365 +-------------------+-----------------------------------------------+ 366 | End.B6.Encaps.Red | End.B6.Encaps with reduced SRH | 367 +-------------------+-----------------------------------------------+ 368 | End.BM | Endpoint bound to an SR-MPLS Policy | 369 +-------------------+-----------------------------------------------+ 371 Figure 1: SR Policy Headend and Endpoint Behaviors 373 5. SRv6 Forwarding Benchmarking Tests 375 This document recommends the same benchmarking tests described in 376 [RFC2544] and [RFC5180] while observing the DUT setup and the traffic 377 setup considerations described above. Indeed, the specificities of 378 SRv6, for example the SRH processing, require additional benchmarking 379 steps. 381 5.1. Throughput 383 This section contains the description of the tests that are related 384 to the characterization of a DUT's SRv6 traffic forwarding 385 throughput. 387 The list of segments for SRv6 is represented as a list of IPv6 388 addresses, included in the SRH. There are three distinct types of 389 nodes that are involved in segment routing networks. 391 5.1.1. Throughput of a Source Node 393 Objective: To obtain the DUT's Throughput during the packet 394 processing of a Source Node. It is when the Source SR node, which 395 corresponds to the headend node, encapsulates a received packet into 396 an outer IPv6 packet and inserts the SR Header (SRH) as a Routing 397 Extension Header in the outer IPv6 header. The Segment List in the 398 SRH is composed of SIDs and the Source SR node sets the first SID of 399 the SR Policy as IPv6 Destination Address of the packet. 401 Procedure: Same as [RFC5180]. 403 Reporting Format: Same as [RFC5180] but adding the additional 404 parameters specified in Section 4. 406 5.1.2. Throughput of a Segment Endpoint Node 408 Objective: To obtain the DUT's Throughput during the packet 409 processing of a Segment Endpoint Node. It is when the SR Segment 410 Endpoint node receives packets whose IPv6 destination address is 411 locally configured as a segment. The SR Segment Endpoint node 412 inspects the SR header: it detects the new active segment, i.e. the 413 next segment in the Segment List, modifies the IPv6 destination 414 address of the outer IPv6 header and forwards the packet on the basis 415 of the IPv6 forwarding table. 417 Procedure: Same as [RFC5180]. 419 Reporting Format: Same as [RFC5180] but adding the additional 420 parameters specified in Section 4. 422 5.1.3. Throughput of a Transit Node 424 Objective: To obtain the DUT's Throughput during the packet 425 processing of a Transit Node. It is when a Transit node forwards the 426 packet containing the SR header as a normal IPv6 packet because the 427 IPv6 destination address does not locally match with a segment. 429 Procedure: Same as [RFC5180]. 431 Reporting Format: Same as [RFC5180] but adding the additional 432 parameters specified in Section 4. 434 5.2. Latency 436 Objective: To determine the latency as defined in [RFC5180] for each 437 of the SRv6 forwarding operations. 439 Procedure: Same as [RFC5180]. 441 Reporting Format: Same as [RFC5180] but adding the additional 442 parameters specified in Section 4. 444 5.3. Frame Loss 446 Objective: To determine the frame-loss rate (as defined in [RFC5180]) 447 for each of the SRv6 forwarding operations of a DUT throughout the 448 entire range of input data rates and frame sizes. 450 Procedure: Same as [RFC5180]. 452 Reporting Format: Same as [RFC5180] but adding the additional 453 parameters specified in Section 4. 455 5.4. System Recovery 457 Objective: To characterize the speed at which a DUT recovers from an 458 overload condition for each of the SRv6 forwarding operations. 460 Procedure: Same as [RFC5180]. 462 Reporting Format: Same as [RFC5180] but adding the additional 463 parameters specified in Section 4. 465 5.5. Reset 467 Objective: To characterize the speed at which a DUT recovers from a 468 device or software reset for each of the SRv6 forwarding operations. 470 Procedure: Same as [RFC5180]. 472 Reporting Format: Same as [RFC5180] but adding the additional 473 parameters specified in Section 4. 475 6. SR Policy: protection performance 477 [RFC6414] provides common terminology and metrics for benchmarking 478 the performance of protection mechanisms. 480 An SR Policy can be used for Traffic Engineering (TE), Operations, 481 Administration, and Maintenance (OAM), or Fast Reroute (FRR) reasons. 482 Protection allows that, in the event the interface associated with 483 the Adj-SID is down, the packet can still be forwarded via an 484 alternate path. The use of protection is clearly a policy-based 485 decision that determines, for example, that the packet processing by 486 the source node is done to forward a packet over a backup path 487 calculated using TI-LFA. There are 2 different protection mechanisms 488 for SR-TE: Segment protection specified in 489 [I-D.ietf-spring-segment-protection-sr-te-paths] and Path protection 490 introduced in [I-D.ietf-spring-segment-routing-policy]. 492 7. Security Considerations 494 Benchmarking methodologies are limited to technology characterization 495 in a laboratory environment, with dedicated address space and 496 constraints. Special capabilities SHOULD NOT exist in the DUT/SUT 497 specifically for benchmarking purposes. Any implications for network 498 security arising from the DUT/SUT SHOULD be identical in the lab and 499 in production networks. The benchmarking network topology is an 500 independent test setup and MUST NOT be connected to devices that may 501 forward the test traffic into a production network or misroute 502 traffic to the test management network. 504 There are no specific security considerations within the scope of 505 this document. 507 8. IANA Considerations 509 This document has no IANA actions. 511 9. Acknowledgements 513 TBD 515 10. References 517 10.1. Normative References 519 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 520 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 521 July 1991, . 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, 525 DOI 10.17487/RFC2119, March 1997, 526 . 528 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 529 Network Interconnect Devices", RFC 2544, 530 DOI 10.17487/RFC2544, March 1999, 531 . 533 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 534 Dugatkin, "IPv6 Benchmarking Methodology for Network 535 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 536 2008, . 538 [RFC6414] Poretsky, S., Papneja, R., Karthik, J., and S. Vapiwala, 539 "Benchmarking Terminology for Protection Performance", 540 RFC 6414, DOI 10.17487/RFC6414, November 2011, 541 . 543 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 544 Decraene, B., Litkowski, S., and R. Shakir, "Segment 545 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 546 July 2018, . 548 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 549 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 550 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 551 . 553 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 554 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 555 (SRv6) Network Programming", RFC 8986, 556 DOI 10.17487/RFC8986, February 2021, 557 . 559 10.2. Informative References 561 [I-D.ietf-bess-srv6-services] 562 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 563 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 564 Overlay Services", draft-ietf-bess-srv6-services-12 (work 565 in progress), March 2022. 567 [I-D.ietf-lsr-isis-srv6-extensions] 568 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 569 Z. Hu, "IS-IS Extensions to Support Segment Routing over 570 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-18 571 (work in progress), October 2021. 573 [I-D.ietf-lsr-ospfv3-srv6-extensions] 574 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 575 "OSPFv3 Extensions for SRv6", draft-ietf-lsr- 576 ospfv3-srv6-extensions-03 (work in progress), November 577 2021. 579 [I-D.ietf-spring-segment-protection-sr-te-paths] 580 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 581 "Segment Protection for SR-TE Paths", draft-ietf-spring- 582 segment-protection-sr-te-paths-02 (work in progress), 583 January 2022. 585 [I-D.ietf-spring-segment-routing-policy] 586 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 587 P. Mattes, "Segment Routing Policy Architecture", draft- 588 ietf-spring-segment-routing-policy-19 (work in progress), 589 March 2022. 591 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 592 (IPv6) Specification", STD 86, RFC 8200, 593 DOI 10.17487/RFC8200, July 2017, 594 . 596 Authors' Addresses 598 Giuseppe Fioccola 599 Huawei Technologies 600 Riesstrasse, 25 601 Munich 80992 602 Germany 604 Email: giuseppe.fioccola@huawei.com 606 Eduard Vasilenko 607 Huawei Technologies 608 17/4 Krylatskaya str. 609 Moscow 121614 610 Russia 612 Email: vasilenko.eduard@huawei.com 613 Paolo Volpato 614 Huawei Technologies 615 Via Lorenteggio, 240 616 Milan 20147 617 Italy 619 Email: paolo.volpato@huawei.com 621 Luis Miguel Contreras Murillo 622 Telefonica 623 Spain 625 Email: luismiguel.contrerasmurillo@telefonica.com