idnits 2.17.1 draft-li-spring-sr-sfc-control-plane-framework-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (22 April 2022) is 707 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-09 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-17 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-07 == Outdated reference: A later version (-15) exists of draft-ietf-spring-nsh-sr-11 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-05 -- Obsolete informational reference (is this intentional?): RFC 4970 (Obsoleted by RFC 7770) -- Obsolete informational reference (is this intentional?): RFC 4971 (Obsoleted by RFC 7981) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group C. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Informational A. Sawaf 5 Expires: 24 October 2022 Saudi Telecom Company 6 R. Hu 7 Z. Li 8 Huawei Technologies 9 22 April 2022 11 A Framework for Constructing Service Function Chaining Systems Based on 12 Segment Routing 13 draft-li-spring-sr-sfc-control-plane-framework-06 15 Abstract 17 Segment Routing (SR) allows for a flexible definition of end-to-end 18 paths by encoding paths as sequences of topological sub-paths, called 19 "segments". Segment routing architecture can be implemented over an 20 MPLS data plane as well as an IPv6 data plane. 22 Service Function Chaining (SFC) provides support for the creation of 23 composite services that consist of an ordered set of Service 24 Functions (SF) that are to be applied to packets and/or frames 25 selected as a result of classification. 27 SFC can be implemented based on several technologies, such as Network 28 Service Header (NSH) and SR. This document describes a framework for 29 constructing SFC based on Segment Routing. The document reviews the 30 control plane solutions for route distribution of service function 31 instance and service function path, and steering packets into a 32 service function chain. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 24 October 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Overview of SR Based SFC Control Plane . . . . . . . . . . . 4 70 3. Stateless SR Based SFC . . . . . . . . . . . . . . . . . . . 7 71 3.1. Service Function Instance Route Distribution . . . . . . 7 72 3.2. Service Function Path Route Distribution . . . . . . . . 8 73 3.3. Steer Packets into SFC . . . . . . . . . . . . . . . . . 8 74 4. Stateful SR Based SFC . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Service Function Route Distribution . . . . . . . . . . . 8 76 4.2. Service Function Path Route Distribution . . . . . . . . 9 77 4.3. Steer Packets into SFC . . . . . . . . . . . . . . . . . 9 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 8.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 Segment routing (SR) [RFC8402] is a source routing paradigm that 89 explicitly indicates the forwarding path for packets at the ingress 90 node by inserting an ordered list of instructions, called segments. 91 When segment routing is deployed on MPLS data plane, it is called SR- 92 MPLS [RFC8660]. When segment routing is deployed on IPv6 data plane, 93 it is called SRv6 [RFC8754]. 95 Service Function Chaining (SFC) [RFC7665] provides an architecture 96 that supports the creation of composite service that consist of an 97 ordered set of Service Functions (SF) that are to be applied to 98 packets and/or frames selected as a result of classification. 100 SFC can be implemented based on Network Service Header [RFC8300]. In 101 NSH-based SFC, per-SFC state, such as a mapping between Service Path 102 Identifier (SPI) and Service Index (SI) to next-hop forwarding, needs 103 to be maintained on nodes along the Service Function Path(SFP), and 104 it can therefore, be termed as "stateful SFC". 105 [I-D.ietf-bess-nsh-bgp-control-plane] defines the use of BGP as a 106 control plane for networks that support SFC based on NSH and MPLS. 107 The document introduces a new BGP address family called the SFC AFI/ 108 SAFI with two route types: Service Function Instance Route (SFIR) and 109 Service Function Path Route (SFPR). An NSH or MPLS based SFC can be 110 constructed based on the information of SFIR and SFPR. 112 SFC can also be instantiated based on SR. In SR, the forwarding path 113 is explicitly encoded into the packets on the SR source node. In SR- 114 based SFC, an SFC can be represented by a SID list explicitly 115 indicated by the source SR node. The SID in SID list may need to be 116 associated with service information in order to indicate network 117 service, such as Deep Packet Inspection (DPI). Therefore, no per-SFC 118 state needs to be maintained along with the SFP, and it can therefore 119 be termed "stateless SFC". 121 In order to construct SR-based SFC, several mechanisms are proposed, 122 including the mechanisms of SFIR and SFPR distribution, as well as 123 the mechanism of steering packets into an SFP. This document reviews 124 these solutions to describe a framework for the construction of an 125 SFC system based on Segment Routing. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 1.2. Terminology 137 MPLS: Multiprotocol Label Switching. 139 SID: Segment Identifier. 141 SR: Segment Routing. 143 SR-MPLS: Segment Routing with MPLS data plane. 145 SRH: Segment Routing Header. 147 SFIR: Service Function Instance Route 149 SFPR: Service Function Path Route 151 Further, this document makes use of the terms defined in [RFC7665] 152 and [I-D.ietf-spring-sr-service-programming]. 154 2. Overview of SR Based SFC Control Plane 156 As per [RFC7665], the architecture of SFC consists of classifiers, 157 Service Function Forwarders (SFFs), Service Functions (SFs) and SFC 158 Proxies. This is illustrated in Figure 1. 160 +-----+ +-----+ +-----+ 161 | | | SFC | | | 162 | SF1 | |Proxy|---| SF2 | 163 +-----+ +-----+ +-----+ 164 | | 165 +--------------+ | | 166 | Service | SFC +------+ +------+ 167 |Classification| Encapsulation | SFF1 | | SFF2 | 168 --->| Function |+---------------->| |--------| |-------> 169 | | | | | | 170 +--------------+ +------+ +------+ 172 SFC-enabled Domain 174 Figure 1. SFC Architecture 176 In order to construct an SFC, SFIR and SFPR should be distributed to 177 classifiers and SFFs. Also, the rules of steering packets into 178 specific SFPs should be configured at the classifier. 179 [I-D.ietf-bess-nsh-bgp-control-plane]. 181 In SR, a source node can explicitly indicate the forwarding path for 182 packets by inserting an ordered list of instructions. These packet 183 steering policies, known as SR policy, can be installed by a central 184 controller via BGP [I-D.ietf-idr-segment-routing-te-policy] or other 185 mechanisms. 187 When SFC is constructed based on SR, SFPR and packet steering rules 188 can be installed by SR policy at the ingress node, which plays the 189 role of classifier in the SFC architecture. In other words, SFPR 190 does not need to be distributed to all the nodes along the SFP. The 191 architecture of SR based SFC is illustrated in Figure 2. 193 +-----+ +-----+ +-----+ +-----+ 194 | | | | | SR | | | 195 |SR-C | | SF1 | |Proxy|---| SF2 | 196 +-----+ +-----+ +-----+ +-----+ 197 | | | 198 | | | 199 +--------------+ +------+ +------+ 200 | | SFC Encap/SR | SFF1/| | SFF2/| 201 --->|CF/SR ingress |+---------------->| SR |--------| SR |-------> 202 | | | | | | 203 +--------------+ +------+ +------+ 205 SFC-enabled Domain 207 Figure 2. SR based SFC architecture. 209 * CF/SR ingress: an SR ingress node plays the role of Classifier in 210 the SFC architecture, and it connects to an SR controller, where 211 the SR policies originate. 213 * SR-C: SR Controller (SR-C) is connected to the SR ingress node, 214 and may be attached to any node in the network. SR-C is capable 215 of discovering topology, and calculating constrained paths for 216 SFCs. 218 * SFF/SR nodes: the SFF component in SFC architecture, which enables 219 SR to steer packets to SFs. 221 * SFn: Service Functions, can be SR-aware or SR-unaware. If an SF 222 is SR-unaware then SR proxy is needed. 224 * SR proxy: A proxy between SFF/SR nodes and SR-unaware SF. 226 There are two solutions to encode SFC in the SR data plane. 227 [I-D.ietf-spring-sr-service-programming] defines data plane 228 functionality required to implement service segments and achieve 229 service programming in SR-enabled MPLS and IP networks. It can be 230 termed "Stateless SFC" since no per-SFC state is maintained on the SR 231 nodes along the SFP. 233 The second solution can be termed "Stateful SFC" 234 [I-D.ietf-spring-nsh-sr], since it still maintains per-SFC state on 235 nodes. [I-D.ietf-spring-nsh-sr]describes two modes of operation: 237 * NSH-based SFC with SR-based transport tunnel: SR is used as the 238 transport tunnel to route packets between classifier and SFF or 239 SFFs. Service plane routing relies on NSH. 241 * SR-based SFC with Integrated NSH Service Plane: The SFP is encoded 242 within the SR segment-list, while the NSH only maintains the 243 service plane context information, which will be used at NSH-aware 244 SFs, and at SFFs as a pointer to cache SR segment-lists. 246 In order to support these data plane encodings, control plane 247 mechanisms are required. The existing control plane mechanisms are 248 shown in table 1. 250 +------------------------------------------------------------+ 251 | SR based SFC | SFIR | SFPR | Steering policy| 252 +-------------------+-----------+-----------+----------------+ 253 | | BGP | BGP | BGP | 254 |Stateless | BGP-LS | PCEP | PCEP | 255 | | IGP | | | 256 +-------------------+-----------+-----------+----------------+ 257 |NSH-based SFC | BGP | BGP | BGP | 258 |with SR-based | | PCEP | | 259 |transport tunnel | | | | 260 | | | | | 261 | | | | | 262 +-------------------+-----------+-----------+----------------+ 263 |SR-based SFC | BGP | BGP | BGP | 264 |with Integrated | BGP-LS | PCEP | PCEP | 265 |NSH Service Plane | IGP | | | 266 | | | | | 267 +-------------------+-----------+-----------+----------------+ 268 Table 1. SR based SFC Control Plane Solutions 270 3. Stateless SR Based SFC 272 As describe in [I-D.ietf-spring-sr-service-programming], service 273 instances are associated with a segment, called a service SID. These 274 service SIDs are leveraged as part of a SID-list to steer packets 275 through the corresponding services 277 3.1. Service Function Instance Route Distribution 279 To associate a segment with a service, service information, such as 280 Service Function Type (SFT), should be included in segment 281 distribution. [I-D.dawra-idr-bgp-ls-sr-service-segments] specifies 282 the extensions to BGP-LS for discovery and advertisement of service 283 segments to enable setup of service programming paths using Segment 284 Routing. [I-D.dawra-idr-bgp-ls-sr-service-segments] extends SRv6 285 Node SID TLV [I-D.ietf-idr-bgpls-srv6-ext] and SR-MPLS SID/ Label TLV 286 [I-D.ietf-idr-bgp-ls-segment-routing-ext] to associate the Service 287 SID Value with Service-related Information using Service Chaining 288 Sub-TLV. The Service Chaining Sub-TLV contains information of 289 Service SID value, Function Identifier (Static Proxy, Dynamic Proxy, 290 Shared Memory Proxy, Masquerading Proxy, SR Aware Service Etc.), 291 Service Type (DPI, Firewall, Classifier, LB etc.), Traffic Type (IPv4 292 OR IPv6 OR Ethernet) and Opaque Data (such as brand and version, 293 other extra information). This extension works for both SR- MPLS and 294 SRv6. 296 [I-D.ietf-bess-nsh-bgp-control-plane] proposes a BGP-based SFC 297 control plane solution, and it works for SR-MPLS as well. Service 298 function instance route distribution can use SFIR in SFC AFI/SAFI. 299 SFPR and steering rules for the classifier can be distributed by SR 300 policy, which is defined in [I-D.ietf-idr-segment-routing-te-policy]. 301 BGP control plane of SRv6-based SFC still needs to be defined. 303 IGP extensions are proposed by [I-D.xu-isis-service-function-adv] and 304 [I-D.xu-ospf-service-function-adv]. In IS-IS solution, SFFs within 305 the SFC domain need to advertise each SF they are offering by using a 306 new sub-TLV of the IS-IS Router CAPABILITY TLV [RFC4971]. This new 307 sub-TLV is called Service Function sub-TLV, and it can appear 308 multiple times within a given IS-IS Router CAPABILITY TLV or when 309 more than one SF needs to be advertised. OSPF extensions are 310 similar, and use the OSPF Router Information (RI) Opaque LSA 311 [RFC4970] to carry Service Function sub-TLV. 313 However, due to IGP flooding issues, IGP extensions are not very 314 appropriate, and the drafts have expired for a long time. 316 3.2. Service Function Path Route Distribution 318 With SR, the SFPR does not need to be distributed to nodes along the 319 SFP but only to the ingress node. SFPR and steering rules for the 320 classifier can be distributed by SR policy. The BGP extension is 321 defined in [I-D.ietf-idr-segment-routing-te-policy]. The PCEP 322 extension is defined in [I-D.ietf-pce-segment-routing-policy-cp]. 324 3.3. Steer Packets into SFC 326 In SR, packet steering rules are learned through SR policy. Thus, 327 there is no need to install other rules in the classifier, which is 328 the SR source node. 330 4. Stateful SR Based SFC 332 "Stateful SFC" [I-D.ietf-spring-nsh-sr] proposes two modes of SR 333 based SFC: 335 * NSH-based SFC with SR-based transport tunnel 337 * SR-based SFC with Integrated NSH Service Plane 339 4.1. Service Function Route Distribution 341 For NSH-based SFC with SR-based transport tunnel, service information 342 is maintained by NSH while SR is only used for transport between 343 SFFs, so [I-D.ietf-bess-nsh-bgp-control-plane] can be used for this 344 mode. 346 To indicate NSH, an SFF label [I-D.ietf-mpls-sfc-encapsulation] 347 should be inserted as the last label in the label stack in SR-MPLS. 348 The control plane of SFF is also described in 349 [I-D.ietf-bess-nsh-bgp-control-plane]. For choosing/configuring SR 350 as the transport tunnel, BGP route of SFF's BGP Tunnel Encapsulation 351 Attribute Type should be "SR TE Policy Type" 352 [I-D.ietf-idr-segment-routing-te-policy]. For SR-based SFC with 353 Integrated NSH Service Plane, there is no control plane solution as 354 yet defined. 356 4.2. Service Function Path Route Distribution 358 Same as SFIR distribution, SFPR BGP distribution in NSH-based SFC 359 with SR-based transport tunnel is identical to the mechanism defined 360 in [I-D.ietf-bess-nsh-bgp-control-plane]. PCEP extension for SFPR 361 distribution can reuse the NSH based SFC extension defined in 362 [I-D.wu-pce-traffic-steering-sfc]. For SR-based SFC with Integrated 363 NSH Service Plane, control plane solution is to be added in other 364 documents. 366 4.3. Steer Packets into SFC 368 For NSH-based SFC with SR-based transport tunnel, it is the same with 369 the NSH based SFC. The Classifier is responsible for determining to 370 which packet flow a packet belongs (usually by inspecting the packet 371 header), imposing an NSH, and initializing the NSH with the SPI of 372 the selected SFP and the SI of its first hop 373 [I-D.ietf-bess-nsh-bgp-control-plane]. For SR-based SFC with 374 Integrated NSH Service Plane, control plane solution is to be added 375 in other document. 377 5. IANA Considerations 379 This document does not require any IANA actions. 381 6. Security Considerations 383 This document does not introduce additional security requirements and 384 mechanisms. 386 7. Acknowledgements 388 TBA 390 8. References 392 8.1. Normative References 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 400 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 401 May 2017, . 403 8.2. Informative References 405 [I-D.dawra-idr-bgp-ls-sr-service-segments] 406 Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., 407 Bernier, D., Uttaro, J., Decraene, B., Elmalky, H., Xu, 408 X., Guichard, J., and C. Li, "BGP-LS Advertisement of 409 Segment Routing Service Segments", Work in Progress, 410 Internet-Draft, draft-dawra-idr-bgp-ls-sr-service- 411 segments-06, 17 August 2021, 412 . 415 [I-D.ietf-bess-nsh-bgp-control-plane] 416 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 417 Jalil, "BGP Control Plane for the Network Service Header 418 in Service Function Chaining", Work in Progress, Internet- 419 Draft, draft-ietf-bess-nsh-bgp-control-plane-18, 21 August 420 2020, . 423 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 424 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 425 and M. Chen, "Border Gateway Protocol - Link State (BGP- 426 LS) Extensions for Segment Routing", Work in Progress, 427 Internet-Draft, draft-ietf-idr-bgp-ls-segment-routing-ext- 428 18, 15 April 2021, . 431 [I-D.ietf-idr-bgpls-srv6-ext] 432 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 433 Bernier, D., and B. Decraene, "BGP Link State Extensions 434 for SRv6", Work in Progress, Internet-Draft, draft-ietf- 435 idr-bgpls-srv6-ext-09, 10 November 2021, 436 . 439 [I-D.ietf-idr-segment-routing-te-policy] 440 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 441 Jain, D., and S. Lin, "Advertising Segment Routing 442 Policies in BGP", Work in Progress, Internet-Draft, draft- 443 ietf-idr-segment-routing-te-policy-17, 14 April 2022, 444 . 447 [I-D.ietf-mpls-sfc-encapsulation] 448 Malis, A. G., Bryant, S., Halpern, J. M., and W. 449 Henderickx, "MPLS Transport Encapsulation for the Service 450 Function Chaining (SFC) Network Service Header (NSH)", 451 Work in Progress, Internet-Draft, draft-ietf-mpls-sfc- 452 encapsulation-04, 24 March 2019, 453 . 456 [I-D.ietf-pce-segment-routing-policy-cp] 457 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 458 Bidgoli, "PCEP extension to support Segment Routing Policy 459 Candidate Paths", Work in Progress, Internet-Draft, draft- 460 ietf-pce-segment-routing-policy-cp-07, 21 April 2022, 461 . 464 [I-D.ietf-spring-nsh-sr] 465 Guichard, J. N. and J. Tantsura, "Integration of Network 466 Service Header (NSH) and Segment Routing for Service 467 Function Chaining (SFC)", Work in Progress, Internet- 468 Draft, draft-ietf-spring-nsh-sr-11, 20 April 2022, 469 . 472 [I-D.ietf-spring-sr-service-programming] 473 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 474 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 475 S. Salsano, "Service Programming with Segment Routing", 476 Work in Progress, Internet-Draft, draft-ietf-spring-sr- 477 service-programming-05, 10 September 2021, 478 . 481 [I-D.wu-pce-traffic-steering-sfc] 482 Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J. 483 Tantsura, "PCEP Extensions for Service Function Chaining 484 (SFC)", Work in Progress, Internet-Draft, draft-wu-pce- 485 traffic-steering-sfc-12, 30 June 2017, 486 . 489 [I-D.xu-isis-service-function-adv] 490 Xu, X., Wu, N., Shah, H., and L. M. Contreras, 491 "Advertising Service Functions Using IS-IS", Work in 492 Progress, Internet-Draft, draft-xu-isis-service-function- 493 adv-05, 10 May 2017, . 496 [I-D.xu-ospf-service-function-adv] 497 Xu, X., Wu, N., Shah, H., and L. M. Contreras, 498 "Advertising Service Functions Using OSPF", Work in 499 Progress, Internet-Draft, draft-xu-ospf-service-function- 500 adv-02, 29 June 2014, . 503 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 504 S. Shaffer, "Extensions to OSPF for Advertising Optional 505 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 506 2007, . 508 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 509 "Intermediate System to Intermediate System (IS-IS) 510 Extensions for Advertising Router Information", RFC 4971, 511 DOI 10.17487/RFC4971, July 2007, 512 . 514 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 515 Chaining (SFC) Architecture", RFC 7665, 516 DOI 10.17487/RFC7665, October 2015, 517 . 519 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 520 "Network Service Header (NSH)", RFC 8300, 521 DOI 10.17487/RFC8300, January 2018, 522 . 524 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 525 Decraene, B., Litkowski, S., and R. Shakir, "Segment 526 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 527 July 2018, . 529 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 530 Decraene, B., Litkowski, S., and R. Shakir, "Segment 531 Routing with the MPLS Data Plane", RFC 8660, 532 DOI 10.17487/RFC8660, December 2019, 533 . 535 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 536 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 537 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 538 . 540 Authors' Addresses 542 Cheng Li 543 Huawei Technologies 544 Email: c.l@huawei.com 545 Ahmed El Sawaf 546 Saudi Telecom Company 547 Riyadh 548 Saudi Arabia 549 Email: aelsawaf.c@stc.com.sa 551 Ruizhao Hu 552 Huawei Technologies 553 Huawei Campus, No. 156 Beiqing Rd. 554 Beijing 555 100095 556 China 557 Email: huruizhao@huawei.com 559 Zhenbin Li 560 Huawei Technologies 561 Huawei Campus, No. 156 Beiqing Rd. 562 Beijing 563 100095 564 China 565 Email: lizhenbin@huawei.com