idnits 2.17.1 draft-li-spring-sr-sfc-control-plane-framework-02.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 (May 8, 2020) is 1449 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-barth-pce-segment-routing-policy-cp-05 == Outdated reference: A later version (-06) exists of draft-dawra-idr-bgp-ls-sr-service-segments-03 == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-13 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-02 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-08 == Outdated reference: A later version (-15) exists of draft-ietf-spring-nsh-sr-02 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-02 -- 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 (~~), 10 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: November 9, 2020 Saudi Telecom Company 6 R. Hu 7 Z. Li 8 Huawei Technologies 9 May 8, 2020 11 A Framework for Constructing Service Function Chaining Systems Based on 12 Segment Routing 13 draft-li-spring-sr-sfc-control-plane-framework-02 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 November 9, 2020. 50 Copyright Notice 52 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . 12 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 [I-D.ietf-spring-segment-routing-mpls]. When segment routing is 94 deployed on IPv6 data plane, it is called SRv6 95 [I-D.ietf-6man-segment-routing-header]. 97 Service Function Chaining (SFC) [RFC7665] provides an architecture 98 that supports the creation of composite service that consist of an 99 ordered set of Service Functions (SF) that are to be applied to 100 packets and/or frames selected as a result of classification. 102 SFC can be implemented based on Network Service Header [RFC8300]. In 103 NSH-based SFC, per-SFC state, such as a mapping between Service Path 104 Identifier (SPI) and Service Index (SI) to next-hop forwarding, needs 105 to be maintained on nodes along the Service Function Path(SFP), and 106 it can therefore, be termed as "stateful SFC". 107 [I-D.ietf-bess-nsh-bgp-control-plane] defines the use of BGP as a 108 control plane for networks that support SFC based on NSH and MPLS. 109 The document introduces a new BGP address family called the SFC AFI/ 110 SAFI with two route types: Service Function Instance Route (SFIR) and 111 Service Function Path Route (SFPR). An NSH or MPLS based SFC can be 112 constructed based on the information of SFIR and SFPR. 114 SFC can also be instantiated based on SR. In SR, the forwarding path 115 is explicitly encoded into the packets on the SR source node. In SR- 116 based SFC, an SFC can be represented by a SID list explicitly 117 indicated by the source SR node. The SID in SID list may need to be 118 associated with service information in order to indicate network 119 service, such as Deep Packet Inspection (DPI). Therefore, no per-SFC 120 state needs to be maintained along with the SFP, and it can therefore 121 be termed "stateless SFC". 123 In order to construct SR-based SFC, several mechanisms are proposed, 124 including the mechanisms of SFIR and SFPR distribution, as well as 125 the mechanism of steering packets into an SFP. This document reviews 126 these solutions to describe a framework for the construction of an 127 SFC system based on Segment Routing. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 133 "OPTIONAL" in this document are to be interpreted as described in BCP 134 14 [RFC2119] [RFC8174] when, and only when, they appear in all 135 capitals, as shown here. 137 1.2. Terminology 139 MPLS: Multiprotocol Label Switching. 141 SID: Segment Identifier. 143 SR: Segment Routing. 145 SR-MPLS: Segment Routing with MPLS data plane. 147 SRH: Segment Routing Header. 149 SFIR: Service Function Instance Route 151 SFPR: Service Function Path Route 153 Further, this document makes use of the terms defined in [RFC7665] 154 and [I-D.ietf-spring-sr-service-programming]. 156 2. Overview of SR Based SFC Control Plane 158 As per [RFC7665], the architecture of SFC consists of classifiers, 159 Service Function Forwarders (SFFs), Service Functions (SFs) and SFC 160 Proxies. This is illustrated in Figure 1. 162 +-----+ +-----+ +-----+ 163 | | | SFC | | | 164 | SF1 | |Proxy|---| SF2 | 165 +-----+ +-----+ +-----+ 166 | | 167 +--------------+ | | 168 | Service | SFC +------+ +------+ 169 |Classification| Encapsulation | SFF1 | | SFF2 | 170 --->| Function |+---------------->| |--------| |-------> 171 | | | | | | 172 +--------------+ +------+ +------+ 174 SFC-enabled Domain 176 Figure 1. SFC Architecture 178 In order to construct an SFC, SFIR and SFPR should be distributed to 179 classifiers and SFFs. Also, the rules of steering packets into 180 specific SFPs should be configured at the classifier. 181 [I-D.ietf-bess-nsh-bgp-control-plane]. 183 In SR, a source node can explicitly indicate the forwarding path for 184 packets by inserting an ordered list of instructions. These packet 185 steering policies, known as SR policy, can be installed by a central 186 controller via BGP [I-D.ietf-idr-segment-routing-te-policy] or other 187 mechanisms. 189 When SFC is constructed based on SR, SFPR and packet steering rules 190 can be installed by SR policy at the ingress node, which plays the 191 role of classifier in the SFC architecture. In other words, SFPR 192 does not need to be distributed to all the nodes along the SFP. The 193 architecture of SR based SFC is illustrated in Figure 2. 195 +-----+ +-----+ +-----+ +-----+ 196 | | | | | SR | | | 197 |SR-C | | SF1 | |Proxy|---| SF2 | 198 +-----+ +-----+ +-----+ +-----+ 199 | | | 200 | | | 201 +--------------+ +------+ +------+ 202 | | SFC Encap/SR | SFF1/| | SFF2/| 203 --->|CF/SR ingress |+---------------->| SR |--------| SR |-------> 204 | | | | | | 205 +--------------+ +------+ +------+ 207 SFC-enabled Domain 209 Figure 2. SR based SFC architecture. 211 o CF/SR ingress: an SR ingress node plays the role of Classifier in 212 the SFC architecture, and it connects to an SR controller, where 213 the SR policies originate. 215 o SR-C: SR Controller (SR-C) is connected to the SR ingress node, 216 and may be attached to any node in the network. SR-C is capable 217 of discovering topology, and calculating constrained paths for 218 SFCs. 220 o SFF/SR nodes: the SFF component in SFC architecture, which enables 221 SR to steer packets to SFs. 223 o SFn: Service Functions, can be SR-aware or SR-unaware. If an SF 224 is SR-unaware then SR proxy is needed. 226 o SR proxy: A proxy between SFF/SR nodes and SR-unaware SF. 228 There are two solutions to encode SFC in the SR data plane. 229 [I-D.ietf-spring-sr-service-programming] defines data plane 230 functionality required to implement service segments and achieve 231 service programming in SR-enabled MPLS and IP networks. It can be 232 termed "Stateless SFC" since no per-SFC state is maintained on the SR 233 nodes along the SFP. 235 The second solution can be termed "Stateful SFC" 236 [I-D.ietf-spring-nsh-sr], since it still maintains per-SFC state on 237 nodes. [I-D.ietf-spring-nsh-sr]describes two modes of operation: 239 o NSH-based SFC with SR-based transport tunnel: SR is used as the 240 transport tunnel to route packets between classifier and SFF or 241 SFFs. Service plane routing relies on NSH. 243 o SR-based SFC with Integrated NSH Service Plane: The SFP is encoded 244 within the SR segment-list, while the NSH only maintains the 245 service plane context information, which will be used at NSH-aware 246 SFs, and at SFFs as a pointer to cache SR segment-lists. 248 In order to support these data plane encodings, control plane 249 mechanisms are required. The existing control plane mechanisms are 250 shown in table 1. 252 +------------------------------------------------------------+ 253 | SR based SFC | SFIR | SFPR | Steering policy| 254 +-------------------+-----------+-----------+----------------+ 255 | | BGP | BGP | BGP | 256 |Stateless | BGP-LS | PCEP | PCEP | 257 | | IGP | | | 258 +-------------------+-----------+-----------+----------------+ 259 |NSH-based SFC | BGP | BGP | BGP | 260 |with SR-based | | PCEP | | 261 |transport tunnel | | | | 262 | | | | | 263 | | | | | 264 +-------------------+-----------+-----------+----------------+ 265 |SR-based SFC | BGP | BGP | BGP | 266 |with Integrated | BGP-LS | PCEP | PCEP | 267 |NSH Service Plane | IGP | | | 268 | | | | | 269 +-------------------+-----------+-----------+----------------+ 270 Table 1. SR based SFC Control Plane Solutions 272 3. Stateless SR Based SFC 274 As describe in [I-D.ietf-spring-sr-service-programming], service 275 instances are associated with a segment, called a service SID. These 276 service SIDs are leveraged as part of a SID-list to steer packets 277 through the corresponding services 279 3.1. Service Function Instance Route Distribution 281 To associate a segment with a service, service information, such as 282 Service Function Type (SFT), should be included in segment 283 distribution. [I-D.dawra-idr-bgp-ls-sr-service-segments] specifies 284 the extensions to BGP-LS for discovery and advertisement of service 285 segments to enable setup of service programming paths using Segment 286 Routing. [I-D.dawra-idr-bgp-ls-sr-service-segments] extends SRv6 287 Node SID TLV [I-D.ietf-idr-bgpls-srv6-ext] and SR-MPLS SID/ Label TLV 288 [I-D.ietf-idr-bgp-ls-segment-routing-ext] to associate the Service 289 SID Value with Service-related Information using Service Chaining 290 Sub-TLV. The Service Chaining Sub-TLV contains information of 291 Service SID value, Function Identifier (Static Proxy, Dynamic Proxy, 292 Shared Memory Proxy, Masquerading Proxy, SR Aware Service Etc.), 293 Service Type (DPI, Firewall, Classifier, LB etc.), Traffic Type (IPv4 294 OR IPv6 OR Ethernet) and Opaque Data (such as brand and version, 295 other extra information). This extension works for both SR- MPLS and 296 SRv6. 298 [I-D.ietf-bess-nsh-bgp-control-plane] proposes a BGP-based SFC 299 control plane solution, and it works for SR-MPLS as well. Service 300 function instance route distribution can use SFIR in SFC AFI/SAFI. 301 SFPR and steering rules for the classifier can be distributed by SR 302 policy, which is defined in [I-D.ietf-idr-segment-routing-te-policy]. 303 BGP control plane of SRv6-based SFC still needs to be defined. 305 IGP extensions are proposed by [I-D.xu-isis-service-function-adv] and 306 [I-D.xu-ospf-service-function-adv]. In IS-IS solution, SFFs within 307 the SFC domain need to advertise each SF they are offering by using a 308 new sub-TLV of the IS-IS Router CAPABILITY TLV [RFC4971]. This new 309 sub-TLV is called Service Function sub-TLV, and it can appear 310 multiple times within a given IS-IS Router CAPABILITY TLV or when 311 more than one SF needs to be advertised. OSPF extensions are 312 similar, and use the OSPF Router Information (RI) Opaque LSA 313 [RFC4970] to carry Service Function sub-TLV. 315 However, due to IGP flooding issues, IGP extensions are not very 316 appropriate, and the drafts have expired for a long time. 318 3.2. Service Function Path Route Distribution 320 With SR, the SFPR does not need to be distributed to nodes along the 321 SFP but only to the ingress node. SFPR and steering rules for the 322 classifier can be distributed by SR policy. The BGP extension is 323 defined in [I-D.ietf-idr-segment-routing-te-policy]. The PCEP 324 extension is defined in [I-D.barth-pce-segment-routing-policy-cp]. 326 3.3. Steer Packets into SFC 328 In SR, packet steering rules are learned through SR policy. Thus, 329 there is no need to install other rules in the classifier, which is 330 the SR source node. 332 4. Stateful SR Based SFC 334 "Stateful SFC" [I-D.ietf-spring-nsh-sr] proposes two modes of SR 335 based SFC: 337 o NSH-based SFC with SR-based transport tunnel 339 o SR-based SFC with Integrated NSH Service Plane 341 4.1. Service Function Route Distribution 343 For NSH-based SFC with SR-based transport tunnel, service information 344 is maintained by NSH while SR is only used for transport between 345 SFFs, so [I-D.ietf-bess-nsh-bgp-control-plane] can be used for this 346 mode. 348 To indicate NSH, an SFF label [I-D.ietf-mpls-sfc-encapsulation] 349 should be inserted as the last label in the label stack in SR-MPLS. 350 The control plane of SFF is also described in 351 [I-D.ietf-bess-nsh-bgp-control-plane]. For choosing/configuring SR 352 as the transport tunnel, BGP route of SFF's BGP Tunnel Encapsulation 353 Attribute Type should be "SR TE Policy Type" 354 [I-D.ietf-idr-segment-routing-te-policy]. For SR-based SFC with 355 Integrated NSH Service Plane, there is no control plane solution as 356 yet defined. 358 4.2. Service Function Path Route Distribution 360 Same as SFIR distribution, SFPR BGP distribution in NSH-based SFC 361 with SR-based transport tunnel is identical to the mechanism defined 362 in [I-D.ietf-bess-nsh-bgp-control-plane]. PCEP extension for SFPR 363 distribution can reuse the NSH based SFC extension defined in 364 [I-D.wu-pce-traffic-steering-sfc]. For SR-based SFC with Integrated 365 NSH Service Plane, control plane solution is to be added in other 366 documents. 368 4.3. Steer Packets into SFC 370 For NSH-based SFC with SR-based transport tunnel, it is the same with 371 the NSH based SFC. The Classifier is responsible for determining to 372 which packet flow a packet belongs (usually by inspecting the packet 373 header), imposing an NSH, and initializing the NSH with the SPI of 374 the selected SFP and the SI of its first hop 375 [I-D.ietf-bess-nsh-bgp-control-plane]. For SR-based SFC with 376 Integrated NSH Service Plane, control plane solution is to be added 377 in other document. 379 5. IANA Considerations 381 This document does not require any IANA actions. 383 6. Security Considerations 385 This document does not introduce additional security requirements and 386 mechanisms. 388 7. Acknowledgements 390 TBA 392 8. References 394 8.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, 398 DOI 10.17487/RFC2119, March 1997, 399 . 401 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 402 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 403 May 2017, . 405 8.2. Informative References 407 [I-D.barth-pce-segment-routing-policy-cp] 408 Koldychev, M., Sivabalan, S., Barth, C., Li, C., and H. 409 Bidgoli, "PCEP extension to support Segment Routing Policy 410 Candidate Paths", draft-barth-pce-segment-routing-policy- 411 cp-05 (work in progress), May 2020. 413 [I-D.dawra-idr-bgp-ls-sr-service-segments] 414 Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., 415 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., 416 Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS 417 Advertisement of Segment Routing Service Segments", draft- 418 dawra-idr-bgp-ls-sr-service-segments-03 (work in 419 progress), January 2020. 421 [I-D.ietf-6man-segment-routing-header] 422 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 423 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 424 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 425 progress), October 2019. 427 [I-D.ietf-bess-nsh-bgp-control-plane] 428 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 429 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 430 nsh-bgp-control-plane-13 (work in progress), December 431 2019. 433 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 434 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 435 and M. Chen, "BGP Link-State extensions for Segment 436 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 437 (work in progress), June 2019. 439 [I-D.ietf-idr-bgpls-srv6-ext] 440 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 441 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 442 State Extensions for SRv6", draft-ietf-idr-bgpls- 443 srv6-ext-02 (work in progress), January 2020. 445 [I-D.ietf-idr-segment-routing-te-policy] 446 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 447 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 448 Routing Policies in BGP", draft-ietf-idr-segment-routing- 449 te-policy-08 (work in progress), November 2019. 451 [I-D.ietf-mpls-sfc-encapsulation] 452 Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 453 "MPLS Transport Encapsulation For The SFC NSH", draft- 454 ietf-mpls-sfc-encapsulation-04 (work in progress), March 455 2019. 457 [I-D.ietf-spring-nsh-sr] 458 Guichard, J., Song, H., Tantsura, J., Halpern, J., 459 Henderickx, W., Boucadair, M., and S. Hassan, "Network 460 Service Header (NSH) and Segment Routing Integration for 461 Service Function Chaining (SFC)", draft-ietf-spring-nsh- 462 sr-02 (work in progress), April 2020. 464 [I-D.ietf-spring-segment-routing-mpls] 465 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 466 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 467 data plane", draft-ietf-spring-segment-routing-mpls-22 468 (work in progress), May 2019. 470 [I-D.ietf-spring-sr-service-programming] 471 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 472 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 473 Henderickx, W., and S. Salsano, "Service Programming with 474 Segment Routing", draft-ietf-spring-sr-service- 475 programming-02 (work in progress), March 2020. 477 [I-D.wu-pce-traffic-steering-sfc] 478 Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J. 479 Tantsura, "PCEP Extensions for Service Function Chaining 480 (SFC)", draft-wu-pce-traffic-steering-sfc-12 (work in 481 progress), June 2017. 483 [I-D.xu-isis-service-function-adv] 484 Xu, X., Wu, N., Shah, H., and L. Contreras, "Advertising 485 Service Functions Using IS-IS", draft-xu-isis-service- 486 function-adv-05 (work in progress), May 2017. 488 [I-D.xu-ospf-service-function-adv] 489 Xu, X., Wu, N., Shah, H., and L. Contreras, "Advertising 490 Service Functions Using OSPF", draft-xu-ospf-service- 491 function-adv-02 (work in progress), June 2014. 493 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 494 S. Shaffer, "Extensions to OSPF for Advertising Optional 495 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 496 2007, . 498 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 499 "Intermediate System to Intermediate System (IS-IS) 500 Extensions for Advertising Router Information", RFC 4971, 501 DOI 10.17487/RFC4971, July 2007, 502 . 504 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 505 Chaining (SFC) Architecture", RFC 7665, 506 DOI 10.17487/RFC7665, October 2015, 507 . 509 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 510 "Network Service Header (NSH)", RFC 8300, 511 DOI 10.17487/RFC8300, January 2018, 512 . 514 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 515 Decraene, B., Litkowski, S., and R. Shakir, "Segment 516 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 517 July 2018, . 519 Authors' Addresses 521 Cheng Li 522 Huawei Technologies 524 Email: chengli13@huawei.com 526 Ahmed El Sawaf 527 Saudi Telecom Company 528 Riyadh 529 Saudi Arabia 531 Email: aelsawaf.c@stc.com.sa 533 Ruizhao Hu 534 Huawei Technologies 535 Huawei Campus, No. 156 Beiqing Rd. 536 Beijing 100095 537 China 539 Email: huruizhao@huawei.com 541 Zhenbin Li 542 Huawei Technologies 543 Huawei Campus, No. 156 Beiqing Rd. 544 Beijing 100095 545 China 547 Email: lizhenbin@huawei.com