idnits 2.17.1 draft-ietf-mpls-sfc-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 date (August 5, 2018) is 2092 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-14 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group A. Farrel 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track S. Bryant 5 Expires: February 6, 2019 Huawei 6 J. Drake 7 Juniper Networks 8 August 5, 2018 10 An MPLS-Based Forwarding Plane for Service Function Chaining 11 draft-ietf-mpls-sfc-02 13 Abstract 15 Service Function Chaining (SFC) is the process of directing packets 16 through a network so that they can be acted on by an ordered set of 17 abstract service functions before being delivered to the intended 18 destination. An architecture for SFC is defined in RFC7665. 20 The Network Service Header (NSH) can be inserted into packets to 21 steer them along a specific path to realize a Service Function Chain. 23 Multiprotocol Label Switching (MPLS) is a widely deployed forwarding 24 technology that uses labels placed in a packet in a label stack to 25 identify the forwarding actions to be taken at each hop through a 26 network. Actions may include swapping or popping the labels as well, 27 as using the labels to determine the next hop for forwarding the 28 packet. Labels may also be used to establish the context under which 29 the packet is forwarded. 31 This document describes how Service Function Chaining can be achieved 32 in an MPLS network by means of a logical representation of the NSH in 33 an MPLS label stack. It does not deprecate or replace the NSH, but 34 acknowledges that there may be a need for an interim deployment of 35 SFC functionality in brownfield networks. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on February 6, 2019. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 73 3. Choice of Data Plane SPI/SI Representation . . . . . . . . . 4 74 4. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 5 75 4.1. Label Swapping for Logical NSH . . . . . . . . . . . . . 5 76 4.2. Hierarchical Encapsulation . . . . . . . . . . . . . . . 5 77 4.3. Fine Control of Service Function Instances . . . . . . . 6 78 4.4. Micro Chains and Label Stacking . . . . . . . . . . . . . 6 79 4.5. SFC and Segment Routing . . . . . . . . . . . . . . . . . 6 80 5. Basic Unit of Representation . . . . . . . . . . . . . . . . 6 81 6. MPLS Label Swapping . . . . . . . . . . . . . . . . . . . . . 8 82 7. MPLS Label Stacking . . . . . . . . . . . . . . . . . . . . . 10 83 8. Mixed Mode Forwarding . . . . . . . . . . . . . . . . . . . . 12 84 9. A Note on Service Function Capabilities and SFC Proxies . . . 13 85 10. Control Plane Considerations . . . . . . . . . . . . . . . . 13 86 11. Use of the Entropy Label . . . . . . . . . . . . . . . . . . 14 87 12. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 12.1. Indicating Metadata in User Data Packets . . . . . . . . 15 89 12.2. Inband Programming of Metadata . . . . . . . . . . . . . 17 90 13. Worked Examples . . . . . . . . . . . . . . . . . . . . . . . 20 91 14. Implementation Notes . . . . . . . . . . . . . . . . . . . . 24 92 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 94 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 95 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 96 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 19.1. Normative References . . . . . . . . . . . . . . . . . . 26 98 19.2. Informative References . . . . . . . . . . . . . . . . . 27 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 101 1. Introduction 103 Service Function Chaining (SFC) is the process of directing packets 104 through a network so that they can be acted on by an ordered set of 105 abstract service functions before being delivered to the intended 106 destination. An architecture for SFC is defined in [RFC7665]. 108 When applying a particular Service Function Chain to the traffic 109 selected by a service classifier, the traffic needs to be steered 110 through an ordered set of Service Functions (SFs) in the network. 111 This ordered set of SFs is termed a Service Function Path (SFP), and 112 the traffic is passed between Service Function Forwarders (SFFs) that 113 are responsible for delivering the packets to the SFs and for 114 forwarding them onward to the next SFF. 116 In order to steer the selected traffic between SFFs and to the 117 correct SFs the service classifier needs to attach information to 118 each packet. This information indicates the SFP on which the packet 119 is being forwarded and hence the SFs to which it must be delivered. 120 The information also indicates the progress the packet has already 121 made along the SFP. 123 The Network Service Header (NSH) [RFC8300] has been defined to carry 124 the necessary information for Service Function Chaining in packets. 125 The NSH can be inserted into packets and contains various information 126 including a Service Path Indicator (SPI), a Service Index (SI), and a 127 Time To Live (TTL) counter. 129 Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed 130 forwarding technology that uses labels placed in a packet in a label 131 stack to identify the forwarding actions to be taken at each hop 132 through a network. Actions may include swapping or popping the 133 labels as well, as using the labels to determine the next hop for 134 forwarding the packet. Labels may also be used to establish the 135 context under which the packet is forwarded. In many cases, MPLS 136 will be used as a tunneling technology to carry packets through 137 networks between SFFs. 139 This document describes how Service Function Chaining can be achieved 140 in an MPLS network by means of a logical representation of the NSH in 141 an MPLS label stack. This approach is applicable to all forms of 142 MPLS forwarding (where labels are looked up at each hop, and swapped 143 or popped [RFC3031]). It does not deprecate or replace the NSH, but 144 acknowledges that there may be a need for an interim deployment of 145 SFC functionality in brownfield networks. The mechanisms described 146 in this document are a compromise between the full function that can 147 be achieved using the NSH, and the benefits of reusing the existing 148 MPLS forwarding paradigms. 150 Section 4 provides a short overview of several use case scenarios 151 that help to explain the relationship between the MPLS label 152 operations (swapping, popping, stacking) and the MPLS encoding of the 153 logical NSH described in this document). 155 It is assumed that the reader is fully familiar with the terms and 156 concepts introduced in [RFC7665] and [RFC8300]. 158 Note that one of the features of the SFC architecture described in 159 [RFC7665] is the "SFC proxy" that exists to include legacy SFs that 160 are not able to process NSH-encapsulated packets. This issue is 161 equally applicable to the use of MPLS-encapsulated packets that 162 encode a logical representation of an NSH. It is discussed further 163 in Section 9. 165 2. Requirements Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 3. Choice of Data Plane SPI/SI Representation 175 While [RFC8300] defines the NSH that can be used in a number of 176 environments, this document provides a mechanism to handle situations 177 in which the NSH is not ubiquitously deployed. In this case it is 178 possible to use an alternative data plane representation of the SPI/ 179 SI by carrying the identical semantics in MPLS labels. 181 In order to correctly select the mechanism by which SFC information 182 is encoded and carried between SFFs, it may be necessary to configure 183 the capabilities and choices either within the whole Service Function 184 Overlay Network, or on a hop by hop basis. It is a requirement that 185 both ends of a tunnel over the underlay network (i.e., a pair of SFFs 186 adjacent in the SFC) know that the tunnel is used for SFC and know 187 what form of NSH representation is used. A control plane signalling 188 approach to achieve these objectives is provided using BGP in 189 [I-D.ietf-bess-nsh-bgp-control-plane]. 191 Note that the encoding of the SFC information is independent of the 192 choice of tunneling technology used between SFFs. Thus, an MPLS 193 representation of the logical NSH (as defined in this document) may 194 be used even if the tunnel between a pair of SFFs is not an MPLS 195 tunnel. Conversely, MPLS tunnels may be used to carry other 196 encodings of the logical NSH (specifically, the NSH itself). 198 4. Use Case Scenarios 200 There are five scenarios that can be considered for the use of an 201 MPLS encoding in support of SFC. These are set out in the following 202 sub-sections. 204 4.1. Label Swapping for Logical NSH 206 The primary use case for SFC is described in [RFC7665] and delivered 207 using the NSH which, as described in [RFC8300], uses an encapsulation 208 with a position indicator that is modified at each SFC hop along the 209 chain to indicate the next hop. 211 The label swapping use case scenario effectively replaces the NSH 212 with an MPLS encapsulation as described in Section 6. The MPLS 213 labels encode the same information as the NSH to form a logical NSH. 214 The labels are modified (swapped per [RFC3031]) at each SFC hop along 215 the chain to indicate the next hop. The processing and forwarding 216 state for a chain (i.e., the actions to take on a received label) are 217 programmed in to the network using a control plane or management 218 plane. 220 4.2. Hierarchical Encapsulation 222 [I-D.ietf-sfc-hierarchical] describes an architecture for 223 hierarchical encapsulation using the NSH. It facilitates 224 partitioning of SFC domains for administrative reasons, and allows 225 concatenation of service function chains under the control of a 226 service classifier. 228 The same function can be achieved in an MPLS network using an MPLS 229 encoding of the logical NSH, and label stacking as defined in 230 [RFC3031] and described in Section 7. In this model, swapping is 231 used per Section 4.1 to navigate one chain, and when the end of the 232 chain is reached, the final label is popped revealing the label for 233 another chain. Thus, the primary mode is swapping, but stacking is 234 used to enable the ingress classifier to control concatenation of 235 service function chains. 237 4.3. Fine Control of Service Function Instances 239 It may be that a service function chain (as described in Section 4.1 240 allows some leeway in the choice of service function instances along 241 the chain. However, it may be that a service classifier wishes to 242 constrain the choice and this can be achieved using chain 243 concatenation so that the first chain ends at the point of choice, 244 the next label in the stack indicates the specific service function 245 instance to be executed, and the next label in the stack starts a new 246 chain. Thus, a mixture of label swapping and stacking is used. 248 4.4. Micro Chains and Label Stacking 250 The scenario in Section 4.2 may be extended to its logical extreme by 251 making each concatenated chain as short as it can be: one service 252 function. Each label in the stack indicates the next service 253 function to be executed, and the network is programmed through the 254 control plane or management plane to know how to route to the next 255 (i.e., first) hop in each chain just as it would be to support the 256 scenarios in Section 4.1 and Section 4.2. 258 This scenario is functionally identical to the use of MPLS-SR for SFC 259 as described Section 4.5, and the discussion in that section applies 260 to this section as well. 262 4.5. SFC and Segment Routing 264 Segment Routing (SR) in an MPLS network (known as MPLS-SR) uses a 265 stack of MPLS labels to encode information about the path and network 266 functions that a packet should traverse. MPLS-SR is achieved by 267 applying control plane and management plane techniques to program the 268 MPLS forwarding plane, and by imposing labels on packets at the 269 entrance to the MPLS-SR network. 271 The application of SR to SFC was considered in early versions of the 272 SR architecture [RFC8402] and the MPLS-SR specification 273 [I-D.ietf-spring-segment-routing-mpls], but has since been moved out 274 of those documents. An implementation proposal for achieving SFC 275 using MPLS-SR can be found in [I-D.xuclad-spring-sr-service-chaining] 276 and is not discussed further in this document. 278 5. Basic Unit of Representation 280 When an MPLS label stack is used to carry a logical NSH, a basic unit 281 of representation is used. This unit comprises two MPLS labels as 282 shown below. The unit may be present one or more times in the label 283 stack as explained in subsequent sections. 285 In order to convey the same information as is present in the NSH, two 286 MPLS label stack entries are used. One carries a label to provide 287 context within the SFC scope (the SFC Context Label), and the other 288 carries a label to show which service function is to be actioned (the 289 SF Label). This two-label unit is shown in Figure 1. 291 0 1 2 3 292 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | SFC Context Label | TC |S| TTL | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | SF Label | TC |S| TTL | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 1: The Basic Unit of MPLS Label Stack for SFC 301 The fields of these two label stack entries are encoded as follows: 303 Label: The Label fields contain the values of the SFC Context Label 304 and the SF Label encoded as 20 bit integers. The precise 305 semantics of these label fields are dependent on whether the label 306 stack entries are used for MPLS label swapping (see Section 6) or 307 MPLS label stacking (see Section 7). 309 TC: The TC bits have no meaning. They SHOULD be set to zero in both 310 label stack entries when a packet is sent and MUST be ignored on 311 receipt. 313 S: The bottom of stack bit has its usual meaning in MPLS. It MUST be 314 clear in the SFC Context label stack entry and MAY be set in the 315 SF label stack entry depending on whether the label is the bottom 316 of stack. 318 TTL: The TTL field in the SFC Context label stack entry SHOULD be 319 set to 1. The TTL in SF label stack entry (called the SF TTL) is 320 set according to its use for MPLS label swapping (see Section 6) 321 or MPLS label stacking (see Section 7 and is used to mitigate 322 packet loops. 324 The sections that follow show how this basic unit of MPLS label stack 325 may be used for SFC in the MPLS label swapping case and in the MPLS 326 label stacking. For simplicity, these sections do not describe the 327 use of metadata: that is covered separately in Section 12. 329 6. MPLS Label Swapping 331 This section describes how the basic unit of MPLS label stack for SFC 332 introduced in Section 5 is used when MPLS label swapping is in use. 333 The use case scenario for this approach is introduced in Section 4.1. 335 As can be seen from Figure 2, the top of the label stack comprises 336 the labels necessary to deliver the packet over the MPLS tunnel 337 between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS 338 in UDP, MPLS in GRE, and MPLS in VXLAN or GPE), thus the tunnel 339 technology does not need to be MPLS, but that is shown here for 340 simplicity. 342 An entropy label ([RFC6790]) may also be present as described in 343 Section 11 345 Under these labels (or other encapsulation) comes a single instance 346 of the basic unit of MPLS label stack for SFC. In addition to the 347 interpretation of the fields of these label stack entries provided in 348 Section 5 the following meanings are applied: 350 SPI Label: The Label field of the SFC Context label stack entry 351 contains the value of the SPI encoded as a 20 bit integer. The 352 semantics of the SPI is exactly as defined in [RFC8300]. Note 353 that an SPI as defined by [RFC8300] can be encoded in 3 octets 354 (i.e., 24 bits), but that the Label field allows for only 20 bits 355 and reserves the values 0 though 15 as 'special purpose' labels 356 [RFC7274]. Thus, a system using MPLS representation of the 357 logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or 358 less than 16. 360 SI Label: The Label field of the SF label stack entry contains the 361 value of the SI exactly as defined in [RFC8300]. Since the SI 362 requires only 8 bits, and to avoid overlap with the 'special 363 purpose' label range of 0 through 15 [RFC7274], the SI is carried 364 in the top (most significant) 8 bits of the Label field with the 365 low order 12 bits set to zero. 367 TC: The TC fields are as described in Section 5. 369 S: The S bits are as described in Section 5. 371 TTL: The TTL field in the SPI label stack entry SHOULD be set to 1 372 as stated in Section 5. The TTL in SF label stack entry is 373 decremented once for each forwarding hop in the SFP, i.e., for 374 each SFF transited, and so mirrors the TTL field in the NSH. 376 --------------- 377 ~ Tunnel Labels ~ 378 +---------------+ 379 ~ Optional ~ 380 ~ Entropy Label ~ 381 +---------------+ - - - 382 | SPI Label | 383 +---------------+ Basic unit of MPLS label stack for SFC 384 | SI Label | 385 +---------------+ - - - 386 | | 387 ~ Payload ~ 388 | | 389 --------------- 391 Figure 2: The MPLS SFC Label Stack 393 The following processing rules apply to the Label fields: 395 o When a classifier inserts a packet onto an SFP it sets the SPI 396 Label to indicate the identity of the SFP, and sets the SI Label 397 to indicate the first SF in the path. 399 o When a component of the SFC system processes a packet it uses the 400 SPI Label to identify the SFP and the SI Label to determine to 401 which SFF or instance of an SF (an SFI) to deliver the packet. 402 Under normal circumstances (with the exception of branching and 403 reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the 404 SPI Label value is preserved on all packets. The SI Label value 405 is modified by SFFs and through reclassification to indicate the 406 next hop along the SFP. 408 The following processing rules apply to the TTL field of the SF label 409 stack entry, and are derived from section 2.2 of [RFC8300]: 411 o When a classifier places a packet onto an SFP it MUST set the TTL 412 to a value between 1 and 255. It SHOULD set this according to the 413 expected length of the SFP (i.e., the number of SFs on the SFP), 414 but it MAY set it to a larger value according to local 415 configuration. The maximum TTL value supported in an NSH is 63, 416 and so the practical limit here may also be 63. 418 o When an SFF receives a packet from any component of the SFC system 419 (classifier, SFI, or another SFF) it MUST discard any packets with 420 TTL set to zero. It SHOULD log such occurrences, but MUST apply 421 rate limiting to any such logs. 423 o An SFF MUST decrement the TTL by one each time it performs a 424 forwarding lookup. 426 o If an SFF decrements the TTL to zero it MUST NOT send the packet, 427 and MUST discard the packet. It SHOULD log such occurrences, but 428 MUST apply rate limiting to any such logs. 430 o SFIs MUST ignore the TTL, but MUST mirror it back to the SFF 431 unmodified along with the SI (which may have been changed by local 432 reclassification). 434 o If a classifier along the SFP makes any change to the intended 435 path of the packet including for looping, jumping, or branching 436 (see [I-D.ietf-bess-nsh-bgp-control-plane] it MUST NOT change the 437 SI TTL of the packet. In particular, each component of the SFC 438 system MUST NOT increase the SI TTL value otherwise loops may go 439 undetected. 441 7. MPLS Label Stacking 443 This section describes how the basic unit of MPLS label stack for SFC 444 introduced in Section 5 is used when MPLS label stacking is used to 445 carry information about the SFP and SFs to be executed. The use case 446 scenarios for this approach is introduced in Section 4. 448 As can be seen in Figure 3, the top of the label stack comprises the 449 labels necessary to deliver the packet over the MPLS tunnel between 450 SFFs. Any MPLS encapsulation may be used. 452 An entropy label ([RFC6790]) may also be present as described in 453 Section 11 455 Under these labels comes one of more instances of the basic unit of 456 MPLS label stack for SFC. In addition to the interpretation of the 457 fields of these label stack entries provided in Section 5 the 458 following meanings are applied: 460 SFC Context Label: The Label field of the SFC Context label stack 461 entry contains a label that delivers SFC context. This label may 462 be used to indicate the SPI encoded as a 20 bit integer using the 463 semantics of the SPI is exactly as defined in [RFC8300] and noting 464 that in this case a system using MPLS representation of the 465 logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or 466 less than 16. This label may also be used to convey other SFC 467 context-speific semantics such as indicating how to interpret the 468 SF Label or how to forward the packet to the node that offers the 469 SF. 471 SF Label: The Label field of the SF label stack entry contains a 472 value that identifies the next SFI to be actioned for the packet. 473 This label may be scoped globally or within the context of the 474 preceding SFC Context Label and comes from the range 16 ... 2^20 - 475 1. 477 TC: The TC fields are as described in Section 5. 479 S: The S bits are as described in Section 5. 481 TTL: The TTL fields in the SFC Context label stack entry SF label 482 stack entry SHOULD be set to 1 as stated in Section 5, but MAY be 483 set to larger values if the label indicated a forwarding operation 484 towards the node that hosts the SF. 486 ------------------- 487 ~ Tunnel Labels ~ 488 +-------------------+ 489 ~ Optional ~ 490 ~ Entropy Label ~ 491 +-------------------+ - - - 492 | SFC Context Label | 493 +-------------------+ Basic unit of MPLS label stack for SFC 494 | SF Label | 495 +-------------------+ - - - 496 | SFC Context Label | 497 +-------------------+ Basic unit of MPLS label stack for SFC 498 | SF Label | 499 +-------------------+ - - - 500 ~ ~ 501 +-------------------+ - - - 502 | SFC Context Label | 503 +-------------------+ Basic unit of MPLS label stack for SFC 504 | SF Label | 505 +-------------------+ - - - 506 | | 507 ~ Payload ~ 508 | | 509 ------------------- 511 Figure 3: The MPLS SFC Label Stack for Label Stacking 513 The following processing rules apply to the Label fields: 515 o When a classifier inserts a packet onto an SFP it adds a stack 516 comprising one or more instances of the basic unit of MPLS label 517 stack for SFC. Taken together, this stack defines the SFs to be 518 actioned and so defines the SFP that the packet will traverse. 520 o When a component of the SFC system processes a packet it uses the 521 top basic unit of label stack for SFC to determine to which SFI to 522 next deliver the packet. When an SFF receives a packet it 523 examines the top basic unit of MPLS label stack for SFC to 524 determine where to send the packet next. If the next recipient is 525 a local SFI, the SFC strips the basic unit of MPLS label stack for 526 SFC before forwarding the packet. 528 8. Mixed Mode Forwarding 530 The previous sections describe homogeneous networks where SFC 531 forwarding is either all label swapping or all label popping 532 (stacking). This simplification helps to clarify the explanation of 533 the mechanisms. 535 However, as described in Section 4.2, some uses cases may use label 536 swapping and stacking at the same time. Furthermore, it is also 537 possible that different parts of the network utilize swapping or 538 popping such that an end-to-end service chain has to utilize a 539 combination of both techniques. It is also worth noting that a 540 classifier may be content to use an SFP as installed in the network 541 by a control plane or management plane and so would use label 542 swapping, but that there may be a point in the SFP where a choice of 543 SFIs can be made (perhaps for load balancing) and where, in this 544 instance, the classifier wishes to exert control over that choice by 545 use of a specific entry on the label stack as described in 546 Section 4.3. 548 When an SFF receives a packet containing an MPLS label stack, it 549 checks whether it is processing an {SFP, SI} label pair for label 550 swapping or a {context label, SFI index} label pair for label 551 stacking. It then selects the appropriate SFI to which to send the 552 packet. When it receives the packet back from the SFI, it has four 553 cases to consider. 555 o If the current hop requires an {SFP, SI} and the next hop requires 556 an {SFP, SI}, it sets the SI label to the SI value of the current 557 hop, selects an instance of the SF to be executed at the next hop, 558 and tunnels the packet to the SFF for that SFI. 560 o If the current hop requires an {SFP, SI} and the next hop requires 561 a {context label, SFI label}, it pops the {SFP, SI} from the top 562 of the MPLS label stack and tunnels the packet to the SFF 563 indicated by the context label. 565 o If the current hop requires a {context label, SFI label}, it pops 566 the {context label, SFI label} from the top of the MPLS label 567 stack. 569 * If the new top of the MPLS label stack contains an {SFP, SI} 570 label pair, it selects an SFI to use at the next hop, and 571 tunnels the packet to SFF for that SFI. 573 * If the top of the MPLS label stack contains a {context label, 574 SFI label}, it tunnels the packet to the SFF indicated by the 575 context label. 577 9. A Note on Service Function Capabilities and SFC Proxies 579 The concept of an "SFC proxy" is introduced in [RFC7665]. An SFC 580 proxy is logically located between an SFF and an SFI that is not 581 "SFC-aware". Such SFIs are not capable of handling the SFC 582 encapsulation (whether that be NSH or MPLS) and need the 583 encapsulation stripped from the packets they are to process. In many 584 cases, legacy SFIs that were once deployed as "bumps in the wire" fit 585 into this category until they have been upgraded to be SFC-aware. 587 The job of an SFC proxy is to remove and then reimpose SFC 588 encapsulation so that the SFF is able to process as though it was 589 communication with an SFC-aware SFI, and so that the SFI is unaware 590 of the SFC encapsulation. In this regard, the job of an SFC proxy is 591 no different when NSH encapsulation is used and when MPLS 592 encapsulation is used as described in this document, although (of 593 course) it is different encapsulation bytes that must be removed and 594 reimposed. 596 It should be noted that the SFC proxy is a logical function. It 597 could be implemented as a separate physical component on the path 598 from the SFF to SFI, but it could be coresident with the SFF or it 599 could be a component of the SFI. This is purely an implementation 600 choice. 602 Note also that the delivery of metadata (see Section 12) requires 603 specific processing if an SFC proxy is in use. This is also no 604 different when NSH or the MPLS encoding defined in this document is 605 in use, and how it is handled will depend on how (or if) each non- 606 SFC-aware SFI can receive metadata. 608 10. Control Plane Considerations 610 In order that a packet may be forwarded along an SFP several 611 functional elements must be executed. 613 o Discovery/advertisement of SFIs. 615 o Computation of SFP. 617 o Programming of classifiers. 619 o Advertisement of forwarding instructions. 621 Various approaches may be taken. These include a fully centralized 622 model where SFFs report to a central controller the SFIs that they 623 support, the central controller computes the SFP and programs the 624 classifiers, and (if the label swapping approach is taken) the 625 central controller installs forwarding state in the SFFs that lie on 626 the SFP. 628 Alternatively, a dynamic control plane may be used such as that 629 described in [I-D.ietf-bess-nsh-bgp-control-plane]. In this case the 630 SFFs use the control plane to advertise the SFIs that they support, a 631 central controller computes the SFP and programs the classifiers, and 632 (if the label swapping approach is taken) the central controller uses 633 the control plane to advertise the SFPs so that SFFs that lie on the 634 SFP can install the necessary forwarding state. 636 11. Use of the Entropy Label 638 Entropy is used in ECMP situations to ensure that packets from the 639 same flow travel down the same path, thus avoiding jitter or re- 640 ordering issues within a flow. 642 Entropy is often determined by hashing on specific fields in a packet 643 header such as the "five-tuple" in the IP and transport headers. 644 However, when an MPLS label stack is present, the depth of the stack 645 could be too large for some processors to correctly determine the 646 entropy hash. This problem is addressed by the inclusion of an 647 Entropy Label as described in [RFC6790]. 649 When entropy is desired for packets as they are carried in MPLS 650 tunnels over the underlay network, it is RECOMMENDED that an Entropy 651 Label is included in the label stack immediately after the tunnel 652 labels and before the SFC labels as shown in Figure 2 and Figure 3. 654 If an Entropy Label is present in an MPLS payload, it is RECOMMENDED 655 that the initial classifier use that value in an Entropy Label 656 inserted in the label stack when the packet is forwarded (on the 657 first tunnel) to the first SFF. In this case it is not necessary to 658 remove the Entropy Label from the payload. 660 12. Metadata 662 Metadata is defined in [RFC7665] as providing "the ability to 663 exchange context information between classifiers and SFs, and among 664 SFs." [RFC8300] defines how this context information can be directly 665 encoded in fields that form part of the NSH encapsulation. 667 The next two sections describe how metadata is associated with user 668 data packets, and how metadata may be exchanged between SFC nodes in 669 the network, when using an MPLS encoding of the logical 670 representation of the NSH. 672 It should be noted that the MPLS encoding is less functional than the 673 direct use of the NSH. Both methods support metadata that is "per- 674 SFP" or "per-packet-flow" (see [RFC8393] for definitions of these 675 terms), but "per-packet" metadata (where the metadata must be carried 676 on each packet because it differs from one packet to the next even on 677 the same flow or SFP) is only supported using the NSH and not using 678 the mechanisms defined in this document. 680 12.1. Indicating Metadata in User Data Packets 682 Metadata is achieved in the MPLS realization of the logical NSH by 683 the use of an SFC Metadata Label which uses the Extended Special 684 Purpose Label construct [RFC7274]. Thus, three label stack entries 685 are present as shown in Figure 4: 687 o The Extension Label (value 15) 689 o An extended special purpose label called the Metadata Label 690 Indicator (MLI) (value TBD1 by IANA) 692 o The Metadata Label (ML). 694 ---------------- 695 | Extension = 15 | 696 +----------------+ 697 | MLI | 698 +----------------+ 699 | Metadata Label | 700 --------------- 702 Figure 4: The MPLS SFC Metadata Label 704 The Metadata Label value is an index into a table of metadata that is 705 programmed into the network using in-band or out-of-band mechanisms. 707 Out-of-band mechanisms potentially include management plane and 708 control plane solutions (such as 709 [I-D.ietf-bess-nsh-bgp-control-plane]), but are out of scope for this 710 document. The in-band mechanism is described in Section 12.2 712 The SFC Metadata Label (as a set of three labels as indicated in 713 Figure 4) may be present zero, one, or more times in an MPLS SFC 714 packet. For MPLS label swapping, the SFC Metadata Labels are placed 715 immediately after the basic unit of MPLS label stack for SFC as shown 716 in Figure 5. For MPLS label stacking, the SFC Metadata Labels can be 717 present zero, one, or more times and are placed at the bottom of the 718 label stack as shown in Figure 6. 720 ---------------- 721 ~ Tunnel Labels ~ 722 +----------------+ 723 ~ Optional ~ 724 ~ Entropy Label ~ 725 +----------------+ 726 | SPI Label | 727 +----------------+ 728 | SI Label | 729 +----------------+ 730 | Extension = 15 | 731 +----------------+ 732 | MLI | 733 +----------------+ 734 | Metadata Label | 735 +----------------+ 736 ~ Other ~ 737 | Metadata | 738 ~ Label Triples ~ 739 +----------------+ 740 | | 741 ~ Payload ~ 742 | | 743 ---------------- 745 Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata 746 Label 748 ------------------- 749 ~ Tunnel Labels ~ 750 +-------------------+ 751 ~ Optional ~ 752 ~ Entropy Label ~ 753 +-------------------+ 754 | SFC Context Label | 755 +-------------------+ 756 | SF Label | 757 +-------------------+ 758 ~ ~ 759 +-------------------+ 760 | SFC Context Label | 761 +-------------------+ 762 | SF Label | 763 +-------------------+ 764 | Extension = 15 | 765 +-------------------+ 766 | MLI | 767 +-------------------+ 768 | Metadata Label | 769 +-------------------+ 770 ~ Other ~ 771 | Metadata | 772 ~ Label Triples ~ 773 +-------------------+ 774 | | 775 ~ Payload ~ 776 | | 777 ------------------- 779 Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata 780 Label 782 12.2. Inband Programming of Metadata 784 A mechanism for sending metadata associated with an SFP without a 785 payload packet is described in [RFC8393]. The same approach can be 786 used in an MPLS network where the NSH is logically represented by an 787 MPLS label stack. 789 The packet header is formed exactly as previously described in this 790 document so that the packet will follow the SFP through the SFC 791 network. However, instead of payload data, metadata is included 792 after the bottom of the MPLS label stack. An Extended Special 793 Purpose Label is used to indicate that the metadata is present. 794 Thus, three label stack entries are present: 796 o The Extension Label (value 15) 798 o An extended special purpose label called the Metadata Present 799 Indicator (MPI) (value TBD2 by IANA) 801 o The Metadata Label (ML) that is associated with this metadata on 802 this SFP and can be used to indicate the use of the metadata as 803 described in Section 12. 805 The SFC Metadata Present Label, if present, is placed immediately 806 after the last basic unit of MPLS label stack for SFC. The resultant 807 label stacks are shown in Figure 7 for the MPLS label swapping case 808 and Figure 8 for the MPLS label stacking case. 810 --------------- 811 ~ Tunnel Labels ~ 812 +---------------+ 813 ~ Optional ~ 814 ~ Entropy Label ~ 815 +---------------+ 816 | SPI Label | 817 +---------------+ 818 | SI Label | 819 +---------------+ 820 | Extension = 15| 821 +---------------+ 822 | MPI | 823 +---------------+ 824 | Metadata Label| 825 +---------------+ 826 | | 827 ~ Metadata ~ 828 | | 829 --------------- 831 Figure 7: The MPLS SFC Label Stack for Label Swapping Carrying 832 Metadata 834 ------------------- 835 ~ Tunnel Labels ~ 836 +-------------------+ 837 ~ Optional ~ 838 ~ Entropy Label ~ 839 +-------------------+ 840 | SFC Context Label | 841 +-------------------+ 842 | SF Label | 843 +-------------------+ 844 | SFC Context Label | 845 +-------------------+ 846 | SF Label | 847 +-------------------+ 848 ~ ~ 849 +-------------------+ 850 | SFC Context Label | 851 +-------------------+ 852 | SF Label | 853 +-------------------+ 854 | Extension = 15 | 855 +-------------------+ 856 | MPI | 857 +-------------------+ 858 | Metadata Label | 859 +-------------------+ 860 | | 861 ~ Metadata ~ 862 | | 863 ------------------- 865 Figure 8: The MPLS SFC Label Stack for Label Stacking Carrying 866 Metadata 868 In both cases the metadata is formatted as a TLV as shown in 869 Figure 9. 871 0 1 2 3 872 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Length | Metadata Type | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 ~ Metadata ~ 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 Figure 9: The Metadata TLV 881 The fields of this TLV are interpreted as follows: 883 Length: The length of the metadata carried in the Metadata field in 884 octets not including any padding. 886 Metadata Type: The type of the metadata present. Values for this 887 field are taken from the "MD Types" registry maintained by IANA 888 and defined in [RFC8300]. 890 Metadata: The actual metadata formatted as described in whatever 891 document defines the metadata. This field is end-padded with zero 892 to three octets of zeroes to take it up to a four octet boundary. 894 13. Worked Examples 896 This section reverts to the simplified descriptions of networks that 897 rely wholly on label swapping or label stacking. As described in 898 Section 4, actual deployment scenarios may depend on the use of both 899 mechanisms and utilize a mixed mode as described in Section 8. 901 Consider the simplistic MPLS SFC overlay network shown in Figure 10. 902 A packet is classified for an SFP that will see it pass through two 903 Service Functions, SFa and SFb, that are accessed through Service 904 Function Forwarders SFFa and SFFb respectively. The packet is 905 ultimately delivered to destination, D. 907 Let us assume that the SFP is computed and assigned the SPI of 239. 908 The forwarding details of the SFP are distributed (perhaps using the 909 mechanisms of [I-D.ietf-bess-nsh-bgp-control-plane]) so that the SFFs 910 are programmed with the necessary forwarding instructions. 912 The packet progresses as follows: 914 a. The classifier assigns the packet to the SFP and imposes two 915 label stack entries comprising a single basic unit of MPLS SFC 916 representation: 918 * The higher label stack entry contains a label carrying the SPI 919 value of 239. 921 * The lower label stack entry contains a label carrying the SI 922 value of 255. 924 Further labels may be imposed to tunnel the packet from the 925 classifier to SFFa. 927 b. When the packet arrives at SFFa it strips any labels associated 928 with the tunnel that runs from the classifier to SFFa. SFFa 929 examines the top labels and matches the SPI/SI to identify that 930 the packet should be forwarded to SFa. The packet is forwarded 931 to SFa unmodified. 933 c. SFa performs its designated function and returns the packet to 934 SFFa. 936 d. SFFa modifies the SI in the lower label stack entry (to 254) and 937 uses the SPI/SI to look up the forwarding instructions. It sends 938 the packet with two label stack entries: 940 * The higher label stack entry contains a label carrying the SPI 941 value of 239. 943 * The lower label stack entry contains a label carrying the SI 944 value of 254. 946 Further labels may be imposed to tunnel the packet from the SFFa 947 to SFFb. 949 e. When the packet arrives at SFFb it strips any labels associated 950 with the tunnel from SFFa. SFFb examines the top labels and 951 matches the SPI/SI to identify that the packet should be 952 forwarded to SFb. The packet is forwarded to SFb unmodified. 954 f. SFb performs its designated function and returns the packet to 955 SFFb. 957 g. SFFb modifies the SI in the lower label stack entry (to 253) and 958 uses the SPI/SI to lookup up the forwarding instructions. It 959 determines that it is the last SFF in the SFP so it strips the 960 two SFC label stack entries and forwards the payload toward D 961 using the payload protocol. 963 +---------------------------------------------------+ 964 | MPLS SFC Network | 965 | | 966 | +---------+ +---------+ | 967 | | SFa | | SFb | | 968 | +----+----+ +----+----+ | 969 | ^ | | ^ | | | 970 | (b)| | |(c) (e)| | |(f) | 971 | (a) | | V (d) | | V (g) | 972 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 973 |Classifier+------+ SFFa +-------+ SFFb +------+ D | 974 +----------+ +---------+ +---------+ +-------+ 975 | | 976 +---------------------------------------------------+ 978 Figure 10: Service Function Chaining in an MPLS Network 980 Alternatively, consider the MPLS SFC overlay network shown in 981 Figure 11. A packet is classified for an SFP that will see it pass 982 through two Service Functions, SFx and SFy, that are accessed through 983 Service Function Forwarders SFFx and SFFy respectively. The packet 984 is ultimately delivered to destination, D. 986 Let us assume that the SFP is computed and assigned the SPI of 239. 987 However, the forwarding state for the SFP is not distributed and 988 installed in the network. Instead it will be attached to the 989 individual packets using the MPLS label stack. 991 The packet progresses as follows: 993 1. The classifier assigns the packet to the SFP and imposes two 994 basic units of MPLS SFC representation to describe the full SFP: 996 * The top basic unit comprises two label stack entries as 997 follows: 999 + The higher label stack entry contains a label carrying the 1000 SFC context. 1002 + The lower label stack entry contains a label carrying the 1003 SF indicator for SFx. 1005 * The lower basic unit comprises two label stack entries as 1006 follows: 1008 + The higher label stack entry contains a label carrying the 1009 SFC context. 1011 + The lower label stack entry contains a label carrying the 1012 SF indicator for SFy. 1014 Further labels may be imposed to tunnel the packet from the 1015 classifier to SFFx. 1017 2. When the packet arrives at SFFx it strips any labels associated 1018 with the tunnel from the classifier. SFFx examines the top 1019 labels and matches the context/SF values to identify that the 1020 packet should be forwarded to SFx. The packet is forwarded to 1021 SFx unmodified. 1023 3. SFx performs its designated function and returns the packet to 1024 SFFx. 1026 4. SFFx strips the top basic unit of MPLS SFC representation 1027 revealing the next basic unit. It then uses the revealed 1028 context/SF values to determine how to route the packet to the 1029 next SFF, SFFy. It sends the packet with just one basic unit of 1030 MPLS SFC representation comprising two label stack entries: 1032 * The higher label stack entry contains a label carrying the SFC 1033 context. 1035 * The lower label stack entry contains a label carrying the SF 1036 indicator for SFy. 1038 Further labels may be imposed to tunnel the packet from the SFFx 1039 to SFFy. 1041 5. When the packet arrives at SFFy it strips any labels associated 1042 with the tunnel from SFFx. SFFy examines the top labels and 1043 matches the context/SF values to identify that the packet should 1044 be forwarded to SFy. The packet is forwarded to SFy unmodified. 1046 6. SFy performs its designated function and returns the packet to 1047 SFFy. 1049 7. SFFy strips the top basic unit of MPLS SFC representation 1050 revealing the payload packet. It forwards the payload toward D 1051 using the payload protocol. 1053 +---------------------------------------------------+ 1054 | MPLS SFC Network | 1055 | | 1056 | +---------+ +---------+ | 1057 | | SFx | | SFy | | 1058 | +----+----+ +----+----+ | 1059 | ^ | | ^ | | | 1060 | (2)| | |(3) (5)| | |(6) | 1061 | (1) | | V (4) | | V (7) | 1062 +----------+ ---> +----+----+ ----> +----+----+ ---> +-------+ 1063 |Classifier+------+ SFFx +-------+ SFFy +------+ D | 1064 +----------+ +---------+ +---------+ +-------+ 1065 | | 1066 +---------------------------------------------------+ 1068 Figure 11: Service Function Chaining Using MPLS Label Stacking 1070 14. Implementation Notes 1072 It is not the job of an IETF specification to describe the internals 1073 of an implementation except where that directly impacts upon the bits 1074 on the wire that change the likelihood of interoperability, or where 1075 the availability of configuration or security options directly affect 1076 the utility of an implementation. 1078 However, in view of the objective of this document to acknowledge 1079 that there may be a need for an interim deployment of SFC 1080 functionality in brownfield MPLS networks, this section provides some 1081 observations about how an SFF might utilize MPLS features that are 1082 available in existing routers. This section is not intended to be 1083 definitive or technically complete, but is indicative. 1085 Consider the mechanism used to indicate to which Virtual Routing and 1086 Forwarding (VRF) an incoming MPLS packet should be routed in a Layer 1087 3 Virtual Private Network (L3VPN) [RFC4364]. In this case, the top 1088 MPLS label is an indicator of the VRF that is to be used to route the 1089 payload. 1091 A similar approach can be taken with the label swapping SFC technique 1092 described in Section 6 such that the SFC Context Label identifies a 1093 routing table specific to the SFP. The SF Label can be looked up in 1094 the context of this routing table to determine to which SF to direct 1095 the packet, and how to forward it to the next SFF. 1097 Advanced features (such as metadata) are not inspected by SFFs. The 1098 packets are passed to SFIs that are MPLS-SFC-aware or to SFC proxies, 1099 and those components are responsible for handling all metadata 1100 issues. 1102 Of course, an actual implementation might make considerable 1103 optimizations on this approach, but this section should provide hints 1104 about how MPLS-based SFC might be achieved with relatively small 1105 modifications to deployed MPLS devices. 1107 15. Security Considerations 1109 Discussion of the security properties of SFC networks can be found in 1110 [RFC7665]. Further security discussion for the NSH and its use is 1111 present in [RFC8300]. 1113 It is fundamental to the SFC design that the classifier is a trusted 1114 resource which determines the processing that the packet will be 1115 subject to, including for example the firewall. It is also 1116 fundamental to the MPLS design that packets are routed through the 1117 network using the path specified by the node imposing the labels, and 1118 that labels are swapped or popped correctly. Where an SF is not 1119 encapsulation aware the encapsulation may be stripped by an SFC proxy 1120 such that packet may exist as a native packet (perhaps IP) on the 1121 path between SFC proxy and SF, however this is an intrinsic part of 1122 the SFC design which needs to define how a packet is protected in 1123 that environment. 1125 Additionally, where a tunnel is used to link two non-MPLS domains, 1126 the tunnel design needs to specify how the tunnel is secured. 1128 Thus the security vulnerabilities are addressed (or should be 1129 addressed) in all the underlying technologies used by this design, 1130 which itself does not introduce any new security vulnerabilities. 1132 16. IANA Considerations 1134 This document requests IANA to make allocations from the "Extended 1135 Special-Purpose MPLS Label Values" subregistry of the "Special- 1136 Purpose Multiprotocol Label Switching (MPLS) Label Values" registry 1137 as follows: 1139 Value | Description | 1140 -------+-----------------------------------+-------------- 1141 TBD1 | Metadata Label Indicator (MLI) | [This.I-D] 1142 TBD2 | Metadata Present Indicator (MPI) | [This.I-D] 1144 17. Acknowledgements 1146 This document derives ideas and text from 1147 [I-D.ietf-bess-nsh-bgp-control-plane]. 1149 The authors are grateful to all those who contributed to the 1150 discussions that led to this work: Loa Andersson, Andrew G. Malis, 1151 Alexander Vainshtein, Joel M. Halpern, Tony Przygienda, Stuart 1152 Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided 1153 helpful review comments. 1155 Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern, 1156 and Mach Chen for reviews of this text. 1158 The authors would like to be able to thank the authors of 1159 [I-D.xuclad-spring-sr-service-chaining] and [RFC8402] whose original 1160 work on service chaining and the identification of services using 1161 SIDs, and conversation with whom helped clarify the application of 1162 MPLS-SR to SFC. 1164 Particular thanks to Loa Andersson for conversations and advice about 1165 working group process. 1167 18. Contributors 1169 The following people contributed text to this document: 1171 Andrew Malis 1172 Email: agmalis@gmail.com 1174 19. References 1176 19.1. Normative References 1178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1179 Requirement Levels", BCP 14, RFC 2119, 1180 DOI 10.17487/RFC2119, March 1997, 1181 . 1183 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 1184 and Retiring Special-Purpose MPLS Labels", RFC 7274, 1185 DOI 10.17487/RFC7274, June 2014, 1186 . 1188 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1189 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1190 May 2017, . 1192 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1193 "Network Service Header (NSH)", RFC 8300, 1194 DOI 10.17487/RFC8300, January 2018, 1195 . 1197 [RFC8393] Farrel, A. and J. Drake, "Operating the Network Service 1198 Header (NSH) with Next Protocol "None"", RFC 8393, 1199 DOI 10.17487/RFC8393, May 2018, 1200 . 1202 19.2. Informative References 1204 [I-D.ietf-bess-nsh-bgp-control-plane] 1205 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 1206 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 1207 nsh-bgp-control-plane-04 (work in progress), July 2018. 1209 [I-D.ietf-sfc-hierarchical] 1210 Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 1211 "Hierarchical Service Function Chaining (hSFC)", draft- 1212 ietf-sfc-hierarchical-11 (work in progress), June 2018. 1214 [I-D.ietf-spring-segment-routing-mpls] 1215 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 1216 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 1217 data plane", draft-ietf-spring-segment-routing-mpls-14 1218 (work in progress), June 2018. 1220 [I-D.xuclad-spring-sr-service-chaining] 1221 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1222 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1223 Henderickx, W., and S. Salsano, "Segment Routing for 1224 Service Chaining", draft-xuclad-spring-sr-service- 1225 chaining-01 (work in progress), March 2018. 1227 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1228 Label Switching Architecture", RFC 3031, 1229 DOI 10.17487/RFC3031, January 2001, 1230 . 1232 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1233 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1234 2006, . 1236 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1237 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1238 RFC 6790, DOI 10.17487/RFC6790, November 2012, 1239 . 1241 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1242 Chaining (SFC) Architecture", RFC 7665, 1243 DOI 10.17487/RFC7665, October 2015, 1244 . 1246 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1247 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1248 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1249 July 2018, . 1251 Authors' Addresses 1253 Adrian Farrel 1254 Juniper Networks 1256 Email: afarrel@juniper.net 1258 Stewart Bryant 1259 Huawei 1261 Email: stewart.bryant@gmail.com 1263 John Drake 1264 Juniper Networks 1266 Email: jdrake@juniper.net