idnits 2.17.1 draft-vfv-bmwg-srmpls-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], [RFC5695], [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 774 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (~~), 3 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 MPLS Segment Routing 11 draft-vfv-bmwg-srmpls-bench-meth-01 13 Abstract 15 This document defines a methodology for benchmarking Segment Routing 16 (SR) performance for Segment Routing over MPLS (SR-MPLS). It builds 17 upon [RFC2544], [RFC5695] 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. SR-MPLS Forwarding . . . . . . . . . . . . . . . . . . . . . 3 61 3. Test Methodology . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Test Setup . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. IGP and BGP Support . . . . . . . . . . . . . . . . . . . 5 64 3.3. Frame Formats and Sizes . . . . . . . . . . . . . . . . . 5 65 4. Reporting Format . . . . . . . . . . . . . . . . . . . . . . 6 66 5. SR-MPLS Forwarding Benchmarking Tests . . . . . . . . . . . . 6 67 5.1. Throughput . . . . . . . . . . . . . . . . . . . . . . . 6 68 5.1.1. Throughput for SR-MPLS PUSH . . . . . . . . . . . . . 6 69 5.1.2. Throughput for SR-MPLS NEXT . . . . . . . . . . . . . 6 70 5.1.3. Throughput for SR-MPLS CONTINUE . . . . . . . . . . . 7 71 5.2. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.3. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.4. System Recovery . . . . . . . . . . . . . . . . . . . . . 7 74 5.5. Reset . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. SR Policy: protection performance . . . . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Segment Routing (SR), defined in [RFC8402], leverages the source 87 routing paradigm. The headend node steers a packet through an SR 88 Policy [I-D.ietf-spring-segment-routing-policy], instantiated as an 89 ordered list of segments. A segment, referred to by its Segment 90 Identifier (SID), can have a semantic local to an SR node or global 91 within an SR domain. SR supports per-flow explicit routing while 92 maintaining per-flow state only at the ingress nodes to the SR 93 domain. 95 However, there is no standard method defined to compare and contrast 96 the foundational SR packet forwarding capabilities of network 97 devices. This document aims to extend the efforts of [RFC1242] and 98 [RFC2544] to SR network. 100 The SR architecture can be instantiated on two data-plane: SR over 101 MPLS (SR-MPLS) and SR over IPv6 (SRv6). This document is limited to 102 SR-MPLS. 104 SR can be directly applied to the Multiprotocol Label Switching 105 (MPLS) architecture with no change to the forwarding plane [RFC8660]. 106 A segment is encoded as an MPLS label. An SR Policy is instantiated 107 as a stack of labels. 109 For Segment Routing, PUSH, NEXT, and CONTINUE are operations applied 110 by the forwarding plane. 112 PUSH consists of the insertion of a segment at the top of the segment 113 list. In SR-MPLS, the top of the segment list is the outer label of 114 the label stack. 116 NEXT consists of the inspection of the next segment. The active 117 segment is completed and the next segment becomes active. In SR- 118 MPLS, NEXT is implemented as a POP of the top label. 120 CONTINUE happens when the active segment is not completed; hence, it 121 remains active. In SR-MPLS, the CONTINUE operation is implemented as 122 a SWAP of the top label. 124 [RFC5695] describes a methodology specific to the benchmarking of 125 MPLS forwarding devices, by considering the most common MPLS packet 126 forwarding scenarios and corresponding performance measurements. 128 The purpose of this document is to describe a methodology specific to 129 the benchmarking of Segment Routing. The methodology described is a 130 complement for [RFC5695]. 132 2. SR-MPLS Forwarding 134 In MPLS, a Prefix-SID is allocated in the form of an MPLS label. For 135 SR-MPLS, Segment Routing does not require any change to the MPLS 136 forwarding plane. An SR Policy is instantiated through the MPLS 137 Label Stack: the Segment IDs (SIDs) of a Segment List are inserted as 138 MPLS Labels. The classical forwarding functions available for MPLS 139 networks allow implementing the SR operations. 141 The operations applied by the SR-MPLS forwarding plane are PUSH, 142 NEXT, and CONTINUE. 144 The PUSH operation corresponds to the Label Push function, according 145 to the MPLS label pushing rules specified in [RFC3032]. It consists 146 of pushing one or more MPLS labels on top of an incoming packet then 147 sending it out of a particular physical interface or virtual 148 interface towards a particular next hop. 150 The NEXT operation corresponds to the Label Pop function, that 151 consists of removing the topmost label. The action before and/or 152 after the popping depends on the instruction associated with the 153 active SID on the received packet prior to the popping. It is 154 equivalent to Penultimate Hop Popping (PHP). 156 The CONTINUE operation corresponds to the Label Swap function, 157 according to the MPLS label-swapping rules in [RFC3031]. It consists 158 of associating an incoming label with an outgoing interface and 159 outgoing label and forwarding the packet on the outgoing interface. 160 It is equivalent to Ultimate Hop Popping (UHP). 162 The encapsulation of an IP packet into an SR-MPLS packet is performed 163 at the edge of an SR-MPLS domain, reusing the MPLS Forwarding 164 Equivalent Class (FEC) concept. A Forwarding Equivalent Class (FEC) 165 can be associated with an SR Policy ([RFC8660]). When pushing labels 166 onto a packet's label stack, the Time-to-Live (TTL) field and the 167 Traffic Class (TC) field of each label stack entry must also be set. 169 All SR nodes in the SR domain use an IGP signaling extension to 170 advertise their own prefix SIDs. After receiving advertised prefix 171 SIDs, each SR node calculates the prefix SIDs to the advertisers. 172 The prefix SID advertisement can be an absolute value advertisement 173 or an index value advertisement. In this regard, the mapping of 174 Segments to MPLS Labels (SIDs) is an important process in the SR-MPLS 175 data plane. Each router can advertise its own available label space 176 to be used for Global Segments called Segment Routing Global Block 177 (SRGB) and an identical range of labels (SRGB) should be used in all 178 routers in order to simplify services and operations. In the SR 179 domain Global Segments can be identified by an index, which has to be 180 re-mapped into a label, or by an absolute value. This is relevant 181 for the nodes that perform the NEXT operation to the segments, 182 because the label for the next segments needs to be crafted 183 accordingly. 185 [I-D.ietf-spring-segment-routing-policy] specifies the concepts of SR 186 Policy and steering into an SR Policy. The header of a packet 187 steered in an SR Policy is augmented with the ordered list of 188 segments associated with that SR Policy. SR Policy state is 189 instantiated only on the headend node, that steers a flow into an SR 190 Policy. Indeed intermediate and endpoint nodes do not require any 191 state to be maintained. SR Policies can be instantiated on the 192 headend dynamically and on demand basis. Moreover, signaling can be 193 used in the case of a controller based deployment. For all these 194 reasons, SR Policies scale better than traditional TE mechanisms. 196 3. Test Methodology 198 3.1. Test Setup 200 The Device Under Test (DUT) is connected to the test ports on the 201 test tool according to [RFC2544]. 203 The recommended topology for SR-MPLS Forwarding Benchmarking should 204 be the same as MPLS and it is described in [RFC5695] for both single- 205 port and multi-port scenarios. Indeed, the number of ports is a 206 parameter that MUST be reported. 208 3.2. IGP and BGP Support 210 It is RECOMMENDED that all of the ports on the DUT and test tool 211 support a Segment Routing extensions for dynamic Interior Gateway 212 Protocol (IGP) for routing such as IS-IS [RFC8667] and OSPF [RFC8665] 213 as well as Border Gateway Protocol (BGP) [RFC8669]. 215 As specified in [RFC8402], in the context of an IGP-based distributed 216 control plane, two topological segments are defined: the IGP- 217 Adjacency segment and the IGP-Prefix segment; while, in the context 218 of a BGP-based distributed control plane, two topological segments 219 are defined: the BGP peer segment and the BGP Prefix segment. 221 The distribution method that is used (e.g. OSPF, IS-IS, BGP) MUST be 222 reported. 224 3.3. Frame Formats and Sizes 226 The tests for SR-MPLS will use the Frame characteristics as described 227 in [RFC5695]. 229 Note that [RFC5695] requires exactly a single entry in the MPLS label 230 stack in an MPLS packet. In other words, the depth of the label 231 stack is set to one. 233 To ensure successful delivery of Layer 2 frames carrying SR-MPLS 234 packets and realistic benchmarking, it is RECOMMENDED to set the 235 media MTU value to the effective maximum frame payload size (payload 236 of 1500 octets for Ethernet). 238 The number of entries in the label stack MUST be reported. In 239 addition, it MUST be chosen taking into account this condition. 241 4. Reporting Format 243 There are new parameters that MUST be replaced or added to the 244 parameters specified in [RFC5695]: 246 o SR-MPLS Forwarding Operations (PUSH/ NEXT/ CONTINUE). 248 o Number of Segments considered in the MPLS Label Stack. 250 o Global SIDs or Local SID forwarding behavior. 252 o SR Policy headend or endpoint behavior. 254 5. SR-MPLS Forwarding Benchmarking Tests 256 This document recommends the same benchmarking tests described in 257 [RFC2544] and [RFC5695] while observing the DUT setup and the traffic 258 setup considerations specific for SR-MPLS as described above. It may 259 require additional benchmarking steps. 261 5.1. Throughput 263 This section contains the description of the tests that are related 264 to the characterization of a DUT's SR-MPLS traffic forwarding 265 throughput. 267 The list of segments for SR-MPLS is represented as a stack of MPLS 268 labels. There are three distinct operations to be tested: PUSH, NEXT 269 and CONTINUE. These correspond to the three forwarding operations of 270 an MPLS packet: PUSH (or LSP Ingress), SWAP, or POP (or LSP Egress). 272 5.1.1. Throughput for SR-MPLS PUSH 274 Objective: To obtain the DUT's Throughput during PUSH forwarding 275 operation. It is similar to label Push or LSP Ingress forwarding 276 operation, as per [RFC5695]. Non-reserved MPLS label values MUST be 277 used. 279 Procedure: Same as [RFC5695]. 281 Reporting Format: Same as [RFC5695] but adding the additional 282 parameters specified in Section 4. 284 5.1.2. Throughput for SR-MPLS NEXT 286 Objective: To obtain the DUT's Throughput during NEXT forwarding 287 operation. It is equivalent to MPLS Label Pop or Penultimate Hop 288 Popping (PHP), as per [RFC5695]. Non-reserved MPLS label values MUST 289 be used. 291 Procedure: Same as [RFC5695]. 293 Reporting Format: Same as [RFC5695] but adding the additional 294 parameters specified in Section 4. 296 5.1.3. Throughput for SR-MPLS CONTINUE 298 Objective: To obtain the DUT's Throughput during CONTINUE forwarding 299 operation. It is equivalent to MPLS Label Swap or Ultimate Hop 300 Popping (UHP), as per [RFC5695]. Non-reserved MPLS label values MUST 301 be used. 303 Procedure: Same as [RFC5695]. 305 Reporting Format: Same as [RFC5695] but adding the additional 306 parameters specified in Section 4. 308 5.2. Latency 310 Objective: To determine the latency as defined in [RFC5695] for each 311 of the SR-MPLS forwarding operations. 313 Procedure: Same as [RFC5695]. 315 Reporting Format: Same as [RFC5695] but adding the additional 316 parameters specified in Section 4. 318 5.3. Frame Loss 320 Objective: To determine the frame-loss rate (as defined in [RFC5695]) 321 for each of the SR-MPLS forwarding operations of a DUT throughout the 322 entire range of input data rates and frame sizes. 324 Procedure: Same as [RFC5695]. 326 Reporting Format: Same as [RFC5695] but adding the additional 327 parameters specified in Section 4. 329 5.4. System Recovery 331 Objective: To characterize the speed at which a DUT recovers from an 332 overload condition for each of the SR-MPLS forwarding operations. 334 Procedure: Same as [RFC5695]. 336 Reporting Format: Same as [RFC5695]. but adding the additional 337 parameters specified in Section 4. 339 5.5. Reset 341 Objective: To characterize the speed at which a DUT recovers from a 342 device or software reset for each of the SR-MPLS forwarding 343 operations. 345 Procedure: Same as [RFC5695]. 347 Reporting Format: Same as [RFC5695] but adding the additional 348 parameters specified in Section 4. 350 6. SR Policy: protection performance 352 [RFC6414] provides common terminology and metrics for benchmarking 353 the performance of protection mechanisms. [RFC6894] provides 354 detailed test cases with different topologies and scenarios that 355 should be considered to effectively benchmark MPLS-FRR protection 356 mechanisms and failover times on the data plane. The same approach 357 can be considered also for Segment Routing protection mechanisms. 359 An SR Policy can be used for Traffic Engineering (TE), Operations, 360 Administration, and Maintenance (OAM), or Fast Reroute (FRR) reasons. 361 Protection allows that, in the event the interface associated with 362 the Adj-SID is down, the packet can still be forwarded via an 363 alternate path. The use of protection is clearly a policy-based 364 decision that determines, for example, that a PUSH operation is done 365 to forward a packet over a backup path calculated using TI-LFA. 366 There are 2 different protection mechanisms for SR-TE: Segment 367 protection specified in 368 [I-D.ietf-spring-segment-protection-sr-te-paths] and Path protection 369 introduced in [I-D.ietf-spring-segment-routing-policy]. 371 7. Security Considerations 373 Benchmarking methodologies are limited to technology characterization 374 in a laboratory environment, with dedicated address space and 375 constraints. Special capabilities SHOULD NOT exist in the DUT/SUT 376 specifically for benchmarking purposes. Any implications for network 377 security arising from the DUT/SUT SHOULD be identical in the lab and 378 in production networks. The benchmarking network topology is an 379 independent test setup and MUST NOT be connected to devices that may 380 forward the test traffic into a production network or misroute 381 traffic to the test management network. 383 There are no specific security considerations within the scope of 384 this document. 386 8. IANA Considerations 388 This document has no IANA actions. 390 9. Acknowledgements 392 TBD 394 10. References 396 10.1. Normative References 398 [RFC1242] Bradner, S., "Benchmarking Terminology for Network 399 Interconnection Devices", RFC 1242, DOI 10.17487/RFC1242, 400 July 1991, . 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, 404 DOI 10.17487/RFC2119, March 1997, 405 . 407 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 408 Network Interconnect Devices", RFC 2544, 409 DOI 10.17487/RFC2544, March 1999, 410 . 412 [RFC5695] Akhter, A., Asati, R., and C. Pignataro, "MPLS Forwarding 413 Benchmarking Methodology for IP Flows", RFC 5695, 414 DOI 10.17487/RFC5695, November 2009, 415 . 417 [RFC6414] Poretsky, S., Papneja, R., Karthik, J., and S. Vapiwala, 418 "Benchmarking Terminology for Protection Performance", 419 RFC 6414, DOI 10.17487/RFC6414, November 2011, 420 . 422 [RFC6894] Papneja, R., Vapiwala, S., Karthik, J., Poretsky, S., Rao, 423 S., and JL. Le Roux, "Methodology for Benchmarking MPLS 424 Traffic Engineered (MPLS-TE) Fast Reroute Protection", 425 RFC 6894, DOI 10.17487/RFC6894, March 2013, 426 . 428 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 429 Decraene, B., Litkowski, S., and R. Shakir, "Segment 430 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 431 July 2018, . 433 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 434 Decraene, B., Litkowski, S., and R. Shakir, "Segment 435 Routing with the MPLS Data Plane", RFC 8660, 436 DOI 10.17487/RFC8660, December 2019, 437 . 439 10.2. Informative References 441 [I-D.ietf-spring-segment-protection-sr-te-paths] 442 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 443 "Segment Protection for SR-TE Paths", draft-ietf-spring- 444 segment-protection-sr-te-paths-02 (work in progress), 445 January 2022. 447 [I-D.ietf-spring-segment-routing-policy] 448 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 449 P. Mattes, "Segment Routing Policy Architecture", draft- 450 ietf-spring-segment-routing-policy-19 (work in progress), 451 March 2022. 453 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 454 Label Switching Architecture", RFC 3031, 455 DOI 10.17487/RFC3031, January 2001, 456 . 458 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 459 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 460 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 461 . 463 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 464 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 465 Extensions for Segment Routing", RFC 8665, 466 DOI 10.17487/RFC8665, December 2019, 467 . 469 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 470 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 471 Extensions for Segment Routing", RFC 8667, 472 DOI 10.17487/RFC8667, December 2019, 473 . 475 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 476 A., and H. Gredler, "Segment Routing Prefix Segment 477 Identifier Extensions for BGP", RFC 8669, 478 DOI 10.17487/RFC8669, December 2019, 479 . 481 Authors' Addresses 483 Giuseppe Fioccola 484 Huawei Technologies 485 Riesstrasse, 25 486 Munich 80992 487 Germany 489 Email: giuseppe.fioccola@huawei.com 491 Eduard Vasilenko 492 Huawei Technologies 493 17/4 Krylatskaya str. 494 Moscow 121614 495 Russia 497 Email: vasilenko.eduard@huawei.com 499 Paolo Volpato 500 Huawei Technologies 501 Via Lorenteggio, 240 502 Milan 20147 503 Italy 505 Email: paolo.volpato@huawei.com 507 Luis Miguel Contreras Murillo 508 Telefonica 509 Spain 511 Email: luismiguel.contrerasmurillo@telefonica.com