idnits 2.17.1 draft-li-spring-sr-sfc-control-plane-framework-05.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 (October 21, 2021) is 916 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-08 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-13 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-nsh-sr-09 == 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: April 24, 2022 Saudi Telecom Company 6 R. Hu 7 Z. Li 8 Huawei Technologies 9 October 21, 2021 11 A Framework for Constructing Service Function Chaining Systems Based on 12 Segment Routing 13 draft-li-spring-sr-sfc-control-plane-framework-05 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 April 24, 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Overview of SR Based SFC Control Plane . . . . . . . . . . . 4 71 3. Stateless SR Based SFC . . . . . . . . . . . . . . . . . . . 6 72 3.1. Service Function Instance Route Distribution . . . . . . 6 73 3.2. Service Function Path Route Distribution . . . . . . . . 7 74 3.3. Steer Packets into SFC . . . . . . . . . . . . . . . . . 7 75 4. Stateful SR Based SFC . . . . . . . . . . . . . . . . . . . . 8 76 4.1. Service Function Route Distribution . . . . . . . . . . . 8 77 4.2. Service Function Path Route Distribution . . . . . . . . 8 78 4.3. Steer Packets into SFC . . . . . . . . . . . . . . . . . 8 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 8.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 Segment routing (SR) [RFC8402] is a source routing paradigm that 90 explicitly indicates the forwarding path for packets at the ingress 91 node by inserting an ordered list of instructions, called segments. 92 When segment routing is deployed on MPLS data plane, it is called SR- 93 MPLS [RFC8660]. When segment routing is deployed on IPv6 data plane, 94 it is called SRv6 [RFC8754]. 96 Service Function Chaining (SFC) [RFC7665] provides an architecture 97 that supports the creation of composite service that consist of an 98 ordered set of Service Functions (SF) that are to be applied to 99 packets and/or frames selected as a result of classification. 101 SFC can be implemented based on Network Service Header [RFC8300]. In 102 NSH-based SFC, per-SFC state, such as a mapping between Service Path 103 Identifier (SPI) and Service Index (SI) to next-hop forwarding, needs 104 to be maintained on nodes along the Service Function Path(SFP), and 105 it can therefore, be termed as "stateful SFC". 106 [I-D.ietf-bess-nsh-bgp-control-plane] defines the use of BGP as a 107 control plane for networks that support SFC based on NSH and MPLS. 108 The document introduces a new BGP address family called the SFC AFI/ 109 SAFI with two route types: Service Function Instance Route (SFIR) and 110 Service Function Path Route (SFPR). An NSH or MPLS based SFC can be 111 constructed based on the information of SFIR and SFPR. 113 SFC can also be instantiated based on SR. In SR, the forwarding path 114 is explicitly encoded into the packets on the SR source node. In SR- 115 based SFC, an SFC can be represented by a SID list explicitly 116 indicated by the source SR node. The SID in SID list may need to be 117 associated with service information in order to indicate network 118 service, such as Deep Packet Inspection (DPI). Therefore, no per-SFC 119 state needs to be maintained along with the SFP, and it can therefore 120 be termed "stateless SFC". 122 In order to construct SR-based SFC, several mechanisms are proposed, 123 including the mechanisms of SFIR and SFPR distribution, as well as 124 the mechanism of steering packets into an SFP. This document reviews 125 these solutions to describe a framework for the construction of an 126 SFC system based on Segment Routing. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 1.2. Terminology 138 MPLS: Multiprotocol Label Switching. 140 SID: Segment Identifier. 142 SR: Segment Routing. 144 SR-MPLS: Segment Routing with MPLS data plane. 146 SRH: Segment Routing Header. 148 SFIR: Service Function Instance Route 150 SFPR: Service Function Path Route 152 Further, this document makes use of the terms defined in [RFC7665] 153 and [I-D.ietf-spring-sr-service-programming]. 155 2. Overview of SR Based SFC Control Plane 157 As per [RFC7665], the architecture of SFC consists of classifiers, 158 Service Function Forwarders (SFFs), Service Functions (SFs) and SFC 159 Proxies. This is illustrated in Figure 1. 161 +-----+ +-----+ +-----+ 162 | | | SFC | | | 163 | SF1 | |Proxy|---| SF2 | 164 +-----+ +-----+ +-----+ 165 | | 166 +--------------+ | | 167 | Service | SFC +------+ +------+ 168 |Classification| Encapsulation | SFF1 | | SFF2 | 169 --->| Function |+---------------->| |--------| |-------> 170 | | | | | | 171 +--------------+ +------+ +------+ 173 SFC-enabled Domain 175 Figure 1. SFC Architecture 177 In order to construct an SFC, SFIR and SFPR should be distributed to 178 classifiers and SFFs. Also, the rules of steering packets into 179 specific SFPs should be configured at the classifier. 180 [I-D.ietf-bess-nsh-bgp-control-plane]. 182 In SR, a source node can explicitly indicate the forwarding path for 183 packets by inserting an ordered list of instructions. These packet 184 steering policies, known as SR policy, can be installed by a central 185 controller via BGP [I-D.ietf-idr-segment-routing-te-policy] or other 186 mechanisms. 188 When SFC is constructed based on SR, SFPR and packet steering rules 189 can be installed by SR policy at the ingress node, which plays the 190 role of classifier in the SFC architecture. In other words, SFPR 191 does not need to be distributed to all the nodes along the SFP. The 192 architecture of SR based SFC is illustrated in Figure 2. 194 +-----+ +-----+ +-----+ +-----+ 195 | | | | | SR | | | 196 |SR-C | | SF1 | |Proxy|---| SF2 | 197 +-----+ +-----+ +-----+ +-----+ 198 | | | 199 | | | 200 +--------------+ +------+ +------+ 201 | | SFC Encap/SR | SFF1/| | SFF2/| 202 --->|CF/SR ingress |+---------------->| SR |--------| SR |-------> 203 | | | | | | 204 +--------------+ +------+ +------+ 206 SFC-enabled Domain 208 Figure 2. SR based SFC architecture. 210 o CF/SR ingress: an SR ingress node plays the role of Classifier in 211 the SFC architecture, and it connects to an SR controller, where 212 the SR policies originate. 214 o SR-C: SR Controller (SR-C) is connected to the SR ingress node, 215 and may be attached to any node in the network. SR-C is capable 216 of discovering topology, and calculating constrained paths for 217 SFCs. 219 o SFF/SR nodes: the SFF component in SFC architecture, which enables 220 SR to steer packets to SFs. 222 o SFn: Service Functions, can be SR-aware or SR-unaware. If an SF 223 is SR-unaware then SR proxy is needed. 225 o SR proxy: A proxy between SFF/SR nodes and SR-unaware SF. 227 There are two solutions to encode SFC in the SR data plane. 228 [I-D.ietf-spring-sr-service-programming] defines data plane 229 functionality required to implement service segments and achieve 230 service programming in SR-enabled MPLS and IP networks. It can be 231 termed "Stateless SFC" since no per-SFC state is maintained on the SR 232 nodes along the SFP. 234 The second solution can be termed "Stateful SFC" 235 [I-D.ietf-spring-nsh-sr], since it still maintains per-SFC state on 236 nodes. [I-D.ietf-spring-nsh-sr]describes two modes of operation: 238 o NSH-based SFC with SR-based transport tunnel: SR is used as the 239 transport tunnel to route packets between classifier and SFF or 240 SFFs. Service plane routing relies on NSH. 242 o SR-based SFC with Integrated NSH Service Plane: The SFP is encoded 243 within the SR segment-list, while the NSH only maintains the 244 service plane context information, which will be used at NSH-aware 245 SFs, and at SFFs as a pointer to cache SR segment-lists. 247 In order to support these data plane encodings, control plane 248 mechanisms are required. The existing control plane mechanisms are 249 shown in table 1. 251 +------------------------------------------------------------+ 252 | SR based SFC | SFIR | SFPR | Steering policy| 253 +-------------------+-----------+-----------+----------------+ 254 | | BGP | BGP | BGP | 255 |Stateless | BGP-LS | PCEP | PCEP | 256 | | IGP | | | 257 +-------------------+-----------+-----------+----------------+ 258 |NSH-based SFC | BGP | BGP | BGP | 259 |with SR-based | | PCEP | | 260 |transport tunnel | | | | 261 | | | | | 262 | | | | | 263 +-------------------+-----------+-----------+----------------+ 264 |SR-based SFC | BGP | BGP | BGP | 265 |with Integrated | BGP-LS | PCEP | PCEP | 266 |NSH Service Plane | IGP | | | 267 | | | | | 268 +-------------------+-----------+-----------+----------------+ 269 Table 1. SR based SFC Control Plane Solutions 271 3. Stateless SR Based SFC 273 As describe in [I-D.ietf-spring-sr-service-programming], service 274 instances are associated with a segment, called a service SID. These 275 service SIDs are leveraged as part of a SID-list to steer packets 276 through the corresponding services 278 3.1. Service Function Instance Route Distribution 280 To associate a segment with a service, service information, such as 281 Service Function Type (SFT), should be included in segment 282 distribution. [I-D.dawra-idr-bgp-ls-sr-service-segments] specifies 283 the extensions to BGP-LS for discovery and advertisement of service 284 segments to enable setup of service programming paths using Segment 285 Routing. [I-D.dawra-idr-bgp-ls-sr-service-segments] extends SRv6 286 Node SID TLV [I-D.ietf-idr-bgpls-srv6-ext] and SR-MPLS SID/ Label TLV 287 [I-D.ietf-idr-bgp-ls-segment-routing-ext] to associate the Service 288 SID Value with Service-related Information using Service Chaining 289 Sub-TLV. The Service Chaining Sub-TLV contains information of 290 Service SID value, Function Identifier (Static Proxy, Dynamic Proxy, 291 Shared Memory Proxy, Masquerading Proxy, SR Aware Service Etc.), 292 Service Type (DPI, Firewall, Classifier, LB etc.), Traffic Type (IPv4 293 OR IPv6 OR Ethernet) and Opaque Data (such as brand and version, 294 other extra information). This extension works for both SR- MPLS and 295 SRv6. 297 [I-D.ietf-bess-nsh-bgp-control-plane] proposes a BGP-based SFC 298 control plane solution, and it works for SR-MPLS as well. Service 299 function instance route distribution can use SFIR in SFC AFI/SAFI. 300 SFPR and steering rules for the classifier can be distributed by SR 301 policy, which is defined in [I-D.ietf-idr-segment-routing-te-policy]. 302 BGP control plane of SRv6-based SFC still needs to be defined. 304 IGP extensions are proposed by [I-D.xu-isis-service-function-adv] and 305 [I-D.xu-ospf-service-function-adv]. In IS-IS solution, SFFs within 306 the SFC domain need to advertise each SF they are offering by using a 307 new sub-TLV of the IS-IS Router CAPABILITY TLV [RFC4971]. This new 308 sub-TLV is called Service Function sub-TLV, and it can appear 309 multiple times within a given IS-IS Router CAPABILITY TLV or when 310 more than one SF needs to be advertised. OSPF extensions are 311 similar, and use the OSPF Router Information (RI) Opaque LSA 312 [RFC4970] to carry Service Function sub-TLV. 314 However, due to IGP flooding issues, IGP extensions are not very 315 appropriate, and the drafts have expired for a long time. 317 3.2. Service Function Path Route Distribution 319 With SR, the SFPR does not need to be distributed to nodes along the 320 SFP but only to the ingress node. SFPR and steering rules for the 321 classifier can be distributed by SR policy. The BGP extension is 322 defined in [I-D.ietf-idr-segment-routing-te-policy]. The PCEP 323 extension is defined in [I-D.ietf-pce-segment-routing-policy-cp]. 325 3.3. Steer Packets into SFC 327 In SR, packet steering rules are learned through SR policy. Thus, 328 there is no need to install other rules in the classifier, which is 329 the SR source node. 331 4. Stateful SR Based SFC 333 "Stateful SFC" [I-D.ietf-spring-nsh-sr] proposes two modes of SR 334 based SFC: 336 o NSH-based SFC with SR-based transport tunnel 338 o SR-based SFC with Integrated NSH Service Plane 340 4.1. Service Function Route Distribution 342 For NSH-based SFC with SR-based transport tunnel, service information 343 is maintained by NSH while SR is only used for transport between 344 SFFs, so [I-D.ietf-bess-nsh-bgp-control-plane] can be used for this 345 mode. 347 To indicate NSH, an SFF label [I-D.ietf-mpls-sfc-encapsulation] 348 should be inserted as the last label in the label stack in SR-MPLS. 349 The control plane of SFF is also described in 350 [I-D.ietf-bess-nsh-bgp-control-plane]. For choosing/configuring SR 351 as the transport tunnel, BGP route of SFF's BGP Tunnel Encapsulation 352 Attribute Type should be "SR TE Policy Type" 353 [I-D.ietf-idr-segment-routing-te-policy]. For SR-based SFC with 354 Integrated NSH Service Plane, there is no control plane solution as 355 yet defined. 357 4.2. Service Function Path Route Distribution 359 Same as SFIR distribution, SFPR BGP distribution in NSH-based SFC 360 with SR-based transport tunnel is identical to the mechanism defined 361 in [I-D.ietf-bess-nsh-bgp-control-plane]. PCEP extension for SFPR 362 distribution can reuse the NSH based SFC extension defined in 363 [I-D.wu-pce-traffic-steering-sfc]. For SR-based SFC with Integrated 364 NSH Service Plane, control plane solution is to be added in other 365 documents. 367 4.3. Steer Packets into SFC 369 For NSH-based SFC with SR-based transport tunnel, it is the same with 370 the NSH based SFC. The Classifier is responsible for determining to 371 which packet flow a packet belongs (usually by inspecting the packet 372 header), imposing an NSH, and initializing the NSH with the SPI of 373 the selected SFP and the SI of its first hop 374 [I-D.ietf-bess-nsh-bgp-control-plane]. For SR-based SFC with 375 Integrated NSH Service Plane, control plane solution is to be added 376 in other document. 378 5. IANA Considerations 380 This document does not require any IANA actions. 382 6. Security Considerations 384 This document does not introduce additional security requirements and 385 mechanisms. 387 7. Acknowledgements 389 TBA 391 8. References 393 8.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, 397 DOI 10.17487/RFC2119, March 1997, 398 . 400 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 401 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 402 May 2017, . 404 8.2. Informative References 406 [I-D.dawra-idr-bgp-ls-sr-service-segments] 407 Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., 408 Bernier, D., Uttaro, J., Decraene, B., Elmalky, H., Xu, 409 X., Guichard, J., and C. Li, "BGP-LS Advertisement of 410 Segment Routing Service Segments", draft-dawra-idr-bgp-ls- 411 sr-service-segments-06 (work in progress), August 2021. 413 [I-D.ietf-bess-nsh-bgp-control-plane] 414 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 415 Jalil, "BGP Control Plane for the Network Service Header 416 in Service Function Chaining", draft-ietf-bess-nsh-bgp- 417 control-plane-18 (work in progress), August 2020. 419 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 420 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 421 and M. Chen, "Border Gateway Protocol - Link State (BGP- 422 LS) Extensions for Segment Routing", draft-ietf-idr-bgp- 423 ls-segment-routing-ext-18 (work in progress), April 2021. 425 [I-D.ietf-idr-bgpls-srv6-ext] 426 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 427 Bernier, D., and B. Decraene, "BGP Link State Extensions 428 for SRv6", draft-ietf-idr-bgpls-srv6-ext-08 (work in 429 progress), June 2021. 431 [I-D.ietf-idr-segment-routing-te-policy] 432 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 433 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 434 Routing Policies in BGP", draft-ietf-idr-segment-routing- 435 te-policy-13 (work in progress), June 2021. 437 [I-D.ietf-mpls-sfc-encapsulation] 438 Malis, A. G., Bryant, S., Halpern, J. M., and W. 439 Henderickx, "MPLS Transport Encapsulation for the Service 440 Function Chaining (SFC) Network Service Header (NSH)", 441 draft-ietf-mpls-sfc-encapsulation-04 (work in progress), 442 March 2019. 444 [I-D.ietf-pce-segment-routing-policy-cp] 445 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 446 Bidgoli, "PCEP extension to support Segment Routing Policy 447 Candidate Paths", draft-ietf-pce-segment-routing-policy- 448 cp-05 (work in progress), May 2021. 450 [I-D.ietf-spring-nsh-sr] 451 Guichard, J. N. and J. Tantsura, "Integration of Network 452 Service Header (NSH) and Segment Routing for Service 453 Function Chaining (SFC)", draft-ietf-spring-nsh-sr-09 454 (work in progress), July 2021. 456 [I-D.ietf-spring-sr-service-programming] 457 Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C., 458 Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and 459 S. Salsano, "Service Programming with Segment Routing", 460 draft-ietf-spring-sr-service-programming-05 (work in 461 progress), September 2021. 463 [I-D.wu-pce-traffic-steering-sfc] 464 Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J. 465 Tantsura, "PCEP Extensions for Service Function Chaining 466 (SFC)", draft-wu-pce-traffic-steering-sfc-12 (work in 467 progress), June 2017. 469 [I-D.xu-isis-service-function-adv] 470 Xu, X., Wu, N., Shah, H., and L. M. Contreras, 471 "Advertising Service Functions Using IS-IS", draft-xu- 472 isis-service-function-adv-05 (work in progress), May 2017. 474 [I-D.xu-ospf-service-function-adv] 475 Xu, X., Wu, N., Shah, H., and L. M. Contreras, 476 "Advertising Service Functions Using OSPF", draft-xu-ospf- 477 service-function-adv-02 (work in progress), June 2014. 479 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 480 S. Shaffer, "Extensions to OSPF for Advertising Optional 481 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 482 2007, . 484 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 485 "Intermediate System to Intermediate System (IS-IS) 486 Extensions for Advertising Router Information", RFC 4971, 487 DOI 10.17487/RFC4971, July 2007, 488 . 490 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 491 Chaining (SFC) Architecture", RFC 7665, 492 DOI 10.17487/RFC7665, October 2015, 493 . 495 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 496 "Network Service Header (NSH)", RFC 8300, 497 DOI 10.17487/RFC8300, January 2018, 498 . 500 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 501 Decraene, B., Litkowski, S., and R. Shakir, "Segment 502 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 503 July 2018, . 505 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 506 Decraene, B., Litkowski, S., and R. Shakir, "Segment 507 Routing with the MPLS Data Plane", RFC 8660, 508 DOI 10.17487/RFC8660, December 2019, 509 . 511 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 512 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 513 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 514 . 516 Authors' Addresses 518 Cheng Li 519 Huawei Technologies 521 Email: c.l@huawei.com 522 Ahmed El Sawaf 523 Saudi Telecom Company 524 Riyadh 525 Saudi Arabia 527 Email: aelsawaf.c@stc.com.sa 529 Ruizhao Hu 530 Huawei Technologies 531 Huawei Campus, No. 156 Beiqing Rd. 532 Beijing 100095 533 China 535 Email: huruizhao@huawei.com 537 Zhenbin Li 538 Huawei Technologies 539 Huawei Campus, No. 156 Beiqing Rd. 540 Beijing 100095 541 China 543 Email: lizhenbin@huawei.com