idnits 2.17.1 draft-ietf-bess-nsh-bgp-control-plane-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2017) is 2404 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) == Missing Reference: 'SPI' is mentioned on line 1304, but not defined == Missing Reference: 'SI' is mentioned on line 1304, but not defined == Missing Reference: 'SFT' is mentioned on line 1304, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-07 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-23 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group A. Farrel 3 Internet-Draft J. Drake 4 Intended status: Standards Track E. Rosen 5 Expires: March 29, 2018 Juniper Networks 6 J. Uttaro 7 AT&T 8 L. Jalil 9 Verizon 10 September 25, 2017 12 BGP Control Plane for NSH SFC 13 draft-ietf-bess-nsh-bgp-control-plane-01 15 Abstract 17 This document describes the use of BGP as a control plane for 18 networks that support Service Function Chaining (SFC). The document 19 introduces a new BGP address family called the SFC AFI/SAFI with two 20 route types. One route type is originated by a node to advertise 21 that it hosts a particular instance of a specified service function. 22 This route type also provides "instructions" on how to send a packet 23 to the hosting node in a way that indicates that the service function 24 has to be applied to the packet. The other route type is used by a 25 Controller to advertise the paths of "chains" of service functions, 26 and to give a unique designator to each such path so that they can be 27 used in conjunction with the Network Service Header. 29 This document adopts the SFC architecture described in RFC 7665. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [RFC2119]. 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 March 29, 2018. 54 Copyright Notice 56 Copyright (c) 2017 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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5 75 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7 76 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10 78 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 11 79 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 12 80 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 16 81 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 17 82 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 17 83 4.2. Service Function Instance Routes . . . . . . . . . . . . 17 84 4.3. Service Function Path Routes . . . . . . . . . . . . . . 18 85 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 19 86 4.5. Service Function Forwarder Operation . . . . . . . . . . 20 87 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 21 88 5. Selection in Service Function Paths . . . . . . . . . . . . . 22 89 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 24 90 6.1. Protocol Control of Looping, Jumping, and Branching . . . 24 91 6.2. Implications for Forwarding State . . . . . . . . . . . . 25 92 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 25 93 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 25 94 7.2. Correlating Service Function Path Instances . . . . . . . 26 95 7.3. Considerations for Stateful Service Functions . . . . . . 27 96 7.4. VPN Considerations and Private Service Functions . . . . 28 97 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 28 98 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 30 99 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 31 100 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 101 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 34 102 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 34 103 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 35 104 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 36 105 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 36 106 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 37 107 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 37 108 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 38 109 8.9. Examples of SFPs with Stateful Service Functions . . . . 39 110 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 39 111 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 40 112 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 41 113 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 43 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 116 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 47 117 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 47 118 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 47 119 10.4. New SFP Association Type Registry . . . . . . . . . . . 48 120 10.5. New Service Function Type Registry . . . . . . . . . . . 48 121 10.6. New Generic Transitive Experimental Use Extended 122 Community Sub-Type . . . . . . . . . . . . . . . . . . . 49 123 10.7. SPI/SI Representation . . . . . . . . . . . . . . . . . 49 124 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 125 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 126 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 127 13.1. Normative References . . . . . . . . . . . . . . . . . . 50 128 13.2. Informative References . . . . . . . . . . . . . . . . . 51 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 131 1. Introduction 133 As described in [RFC7498], the delivery of end-to-end services can 134 require a packet to pass through a series of Service Functions (SFs) 135 (e.g., classifiers, firewalls, TCP accelerators, and server load 136 balancers) in a specified order: this is termed "Service Function 137 Chaining" (SFC). There are a number of issues associated with 138 deploying and maintaining service function chaining in production 139 networks, which are described below. 141 Conventionally, if a packet needs to travel through a particular 142 service chain, the nodes hosting the service functions of that chain 143 are placed in the network topology in such a way that the packet 144 cannot reach its ultimate destination without first passing through 145 all the service functions in the proper order. This need to place 146 the service functions at particular topological locations limits the 147 ability to adapt a service function chain to changes in network 148 topology (e.g., link or node failures), network utilization, or 149 offered service load. These topological restrictions on where the 150 service functions can be placed raise the following issues: 152 1. The process of configuring or modifying a service function chain 153 is operationally complex and may require changes to the network 154 topology. 156 2. Alternate or redundant service functions may need to be co- 157 located with the primary service functions. 159 3. When there is more than one path between source and destination, 160 forwarding may be asymmetric and it may be difficult to support 161 bidirectional service function chains using simple routing 162 methodologies and protocols without adding mechanisms for traffic 163 steering or traffic engineering. 165 In order to address these issues, the SFC architecture describes 166 Service Function Chains that are built in their own overlay network 167 (the service function overlay network), coexisting with other overlay 168 networks, over a common underlay network [RFC7665]. A Service 169 Function Chain is a sequence of Service Functions through which 170 packet flows that satisfy specified criteria will pass. 172 This document describes the use of BGP as a control plane for 173 networks that support Service Function Chaining (SFC). The document 174 introduces a new BGP address family called the SFC AFI/SAFI with two 175 route types. One route type is originated by a node to advertise 176 that it hosts a particular instance of a specified service function. 177 This route type also provides "instructions" on how to send a packet 178 to the hosting node in a way that indicates that the service function 179 has to be applied to the packet. The other route type is used by a 180 Controller to advertise the paths of "chains" of service functions, 181 and to give a unique designator to each such path so that they can be 182 used in conjunction with the Network Service Header. 184 This document adopts the SFC architecture described in [RFC7665]. 186 1.1. Terminology 188 This document uses the following terms from [RFC7665]: 190 o Bidirectional Service Function Chain 192 o Classifier 193 o Service Function (SF) 195 o Service Function Chain (SFC) 197 o Service Function Forwarder (SFF) 199 o Service Function Instance (SFI) 201 o Service Function Path (SFP) 203 o SFC branching 205 Additionally, this document uses the following terms from 206 [I-D.ietf-sfc-nsh]: 208 o Network Service Header (NSH) 210 o Service Index (SI) 212 o Service Path Identifier (SPI) 214 This document introduces the following terms: 216 o Service Function Instance Route (SFIR) 218 o Service Function Overlay Network 220 o Service Function Path Route (SFPR) 222 o Service Function Type (SFT) 224 2. Overview 226 2.1. Functional Overview 228 In [I-D.ietf-sfc-nsh] a Service Function Chain (SFC) is an ordered 229 list of Service Functions (SFs). A Service Function Path (SFP) is an 230 indication of which instances of SFs are acceptable to be traversed 231 in an instantiation of an SFC in a service function overlay network. 232 The Service Path Identifier (SPI) is a 24-bit number that identifies 233 a specific SFP, and a Service Index (SI) is an 8-bit number that 234 identifies a specific point in that path. In the context of a 235 particular SFP (identified by an SPI), an SI represents a particular 236 Service Function, and indicates the order of that SF in the SFP. 238 In fact, each SI is mapped to one or more SFs that are implemented by 239 one or more Service Function Instances (SFIs) that support those 240 specified SFs. Thus an SI may represent a choice of SFIs of one or 241 more Service Function Types. By deploying multiple SFIs for a single 242 SF, one can provide load balancing and redundancy. 244 A special Service Function, called a Classifier, is located at each 245 ingress point to a service function overlay network. It assigns the 246 packets of a given packet flow to a specific Service Function Path. 247 This may be done by comparing specific fields in a packet's header 248 with local policy, which may be customer/network/service specific. 249 The classifier picks an SFP and sets the SPI accordingly, it then 250 sets the SI to the value of the SI for the first hop in the SFP, and 251 then prepends a Network Services Header (NSH) [I-D.ietf-sfc-nsh] 252 containing the assigned SPI/SI to that packet. Note that the 253 Classifier and the node that hosts the first Service Function in a 254 Service Function Path need not be located at the same point in the 255 service function overlay network. 257 Note that the presence of the NSH can make it difficult for nodes in 258 the underlay network to locate the fields in the original packet that 259 would normally be used to constrain equal cost multipath (ECMP) 260 forwarding. Therefore, it is recommended, as described in 261 Section 7.1, that the node prepending the NSH also provide some form 262 of entropy indicator that can be used in the underlay network. 264 The Service Function Forwarder (SFF) receives a packet from the 265 previous node in a Service Function Path, removes the packet's link 266 layer or tunnel encapsulation and hands the packet and the NSH to the 267 Service Function Instance for processing. The SFI has no knowledge 268 of the SFP. 270 When the SFF receives the packet and the NSH back from the SFI it 271 must select the next SFI along the path using the SPI and SI in the 272 NSH and potentially choosing between multiple SFIs (possibly of 273 different Service Function Types) as described in Section 5. In the 274 normal case the SPI remains unchanged and the SI will have been 275 decremented to indicate the next SF along the path. But other 276 possibilities exist if the SF makes other changes to the NSH through 277 a process of re-classification: 279 o The SI in the NSH may indicate: 281 * A previous SF in the path: known as "looping" (see Section 6). 283 * An SF further down the path: known as "jumping" (see also 284 Section 6). 286 o The SPI and the SI may point to an SF on a different SFP: known as 287 "branching" (see also Section 6). 289 Such modifications are limited to within the same service function 290 overlay network. That is, an SPI is known within the scope of 291 service function overlay network. Furthermore, the new SI value is 292 interpreted in the context of the SFP identified by the SPI. 294 An unknown or invalid SPI SHALL be treated as an error and the SFF 295 MUST drop the packet. Such errors SHOULD be logged, and such logs 296 MUST be subject to rate limits. 298 An SFF receiving an SI that is unknown in the context of the SPI MAY 299 reduce the value to the next meaningful SI value in the SFP indicated 300 by the SPI. If no such value exists or if the SFF does not support 301 this function it MUST drop the packet and SHOULD log the event: such 302 logs MUST be subject to rate limits. 304 The SFF then selects an SFI that provides the SF denoted by the SPI/ 305 SI, and forwards the packet to the SFF that supports that SFI. 307 2.2. Control Plane Overview 309 To accomplish the function described in Section 2.1, this document 310 introduces a new BGP AFI/SAFI [values to be assigned by IANA] for 311 "SFC Routes". Two SFC Route Types are defined by this document: the 312 Service Function Instance Route (SFIR), and the Service Function Path 313 Route (SFPR). As detailed in Section 3, the route type is indicated 314 by a sub-field in the NLRI. 316 o The SFIR is advertised by the node hosting the service function 317 instance. The SFIR describes a particular instance of a 318 particular Service Function and the way to forward a packet to it 319 through the underlay network, i.e., IP address and encapsulation 320 information. 322 o The SFPRs are originated by Controllers. One SFPR is originated 323 for each Service Function Path. The SFPR specifies: 325 A. the SPI of the path 327 B. the sequence of SFTs and/or SFIs of which the path consists 329 C. for each such SFT or SFI, the SI that represents it in the 330 identified path. 332 This approach assumes that there is an underlay network that provides 333 connectivity between SFFs and Controllers, and that the SFFs are 334 grouped to form one or more service function overlay networks through 335 which SFPs are built. We assume BGP connectivity between the 336 Controllers and all SFFs within each service function overlay 337 network. 339 In addition, we also introduce the Service Function Type (SFT) that 340 is the category of SF that is supported by an SFF (such as 341 "firewall"). An IANA registry of Service Function Types is 342 introduced in Section 10. An SFF may support SFs of multiple 343 different SFTs, and may support multiple SFIs of each SF. 345 When choosing the next SFI in a path, the SFF uses the SPI and SI as 346 well as the SFT to choose among the SFIs, applying, for example, a 347 load balancing algorithm or direct knowledge of the underlay network 348 topology as described in Section 4. 350 The SFF then encapsulates the packet using the encapsulation 351 specified by the SFIR of the selected SFI and forwards the packet. 352 See Figure 1. 354 Thus the SFF can be seen as a portal in the underlay network through 355 which a particular SFI is reached. 357 Packets 358 | | | 359 | | | 360 | | | 361 ------------ 362 | | 363 | Classifier | 364 | | 365 ------------ 366 | 367 | 368 ------- ------- 369 | | Tunnel | | 370 | SFF |=============| SFF |=========== ......... 371 | | | | # : SFT : 372 | | -+---+- # : ----- : 373 | | / \ # : | SFI | : 374 | | ....../.......\...... # : --+-- : 375 | | : / \ : # ....|.... 376 | | : -+--- ---+- : # | 377 | | : | SFI | | SFI | : # ---+--- 378 | | : ----- ----- : ====| |--- 379 | | : : | SFF |--- Dests 380 | | : ----- : ====| |--- 381 | | : | SFI | : # ------- 382 | | : --+-- : # 383 | | : SFT | : # 384 | | ..........|.......... # 385 | | | # 386 | | | # 387 | | ---+--- # 388 | | | | # 389 | |=============| SFF |=========== 390 ------- | | 391 ------- 393 Figure 1: The SFC Architecture Reference Model 395 3. BGP SFC Routes 397 This document defines a new AFI/SAFI for BGP, known as "SFC", with an 398 NLRI that is described in this section. 400 The format of the SFC NLRI is shown in Figure 2. 402 +---------------------------------------+ 403 | Route Type (2 octets) | 404 +---------------------------------------+ 405 | Length (2 octets) | 406 +---------------------------------------+ 407 | Route Type specific (variable) | 408 +---------------------------------------+ 410 Figure 2: The Format of the SFC NLRI 412 The Route Type field determines the encoding of the rest of the route 413 type specific SFC NLRI. 415 The Length field indicates the length in octets of the route type 416 specific field of the SFC NLRI. 418 This document defines the following Route Types: 420 1. Service Function Instance Route (SFIR) 422 2. Service Function Path Route (SFPR) 424 A Service Function Instance Route (SFIR) is used to identify an SFI. 425 A Service Function Path Route (SFPR) defines a sequence of Service 426 Functions (each of which has at least one instance advertised in an 427 SFIR) that form an SFP. 429 The detailed encoding and procedures for these Route Types are 430 described in subsequent sections. 432 The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol 433 Extensions [RFC4760] with an Address Family Identifier (AFI) of TBD1 434 and a Subsequent Address Family Identifier (SAFI) of TBD2. The NLRI 435 field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC 436 NLRI, encoded as specified above. 438 In order for two BGP speakers to exchange SFC NLRIs, they must use 439 BGP Capabilities Advertisements to ensure that they both are capable 440 of properly processing such NLRIs. This is done as specified in 441 [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI 442 of TBD1 and a SAFI of TBD2. 444 3.1. Service Function Instance Route (SFIR) 446 Figure 3 shows the Route Type specific NLRI of the SFIR. 448 +--------------------------------------------+ 449 | Route Distinguisher (RD) (8 octets) | 450 +--------------------------------------------+ 451 | Service Function Type (2 octets) | 452 +--------------------------------------------+ 454 Figure 3: SFIR Route Type specific NLRI 456 Per [RFC4364] the RD field comprises a two byte Type field and a six 457 byte Value field. Two SFIs of the same SFT must be associated with 458 different RDs, where the association of an SFI with an RD is 459 determined by provisioning. If two SFIRs are originated from 460 different administrative domains, they must have different RDs. In 461 particular, SFIRs from different VPNs (for different service function 462 overlay networks) must have different RDs, and those RDs must be 463 different from any non-VPN SFIRs. 465 The Service Function Type identifies a service function, e.g., 466 classifier, firewall, load balancer, etc. There may be several SFIs 467 that can perform a given Service Function. Each node hosting an SFI 468 must originate an SFIR for each SFI that it hosts. The SFIR 469 representing a given SFI will contain an NLRI with RD field set to an 470 RD as specified above, and with SFT field set to identify that SFI's 471 Service Function Type. The values for the SFT field are taken from a 472 registry administered by IANA (see Section 10). A BGP Update 473 containing one or more SFIRs will also include a Tunnel Encapsulation 474 attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be 475 sent to an SFI identified in one of the SFIRs, it will be 476 encapsulated as specified by the Tunnel Encapsulation attribute, and 477 then transmitted through the underlay network. 479 3.2. Service Function Path Route (SFPR) 481 Figure 4 shows the Route Type specific NLRI of the SFPR. 483 +-----------------------------------------------+ 484 | Route Distinguisher (RD) (8 octets) | 485 +-----------------------------------------------+ 486 | Service Path Identifier (SPI) (3 octets) | 487 +-----------------------------------------------+ 489 Figure 4: SFPR Route Type Specific NLRI 491 Per [RFC4364] the RD field comprises a two byte Type field and a six 492 byte Value field. All SFPs must be associated with different RDs. 494 The association of an SFP with an RD is determined by provisioning. 495 If two SFPRs are originated from different Controllers they must have 496 different RDs. Additionally, SFPRs from different VPNs (i.e., in 497 different service function overlay networks) must have different RDs, 498 and those RDs must be different from any non-VPN SFPRs. 500 The Service Path Identifier is defined in [I-D.ietf-sfc-nsh] and is 501 the value to be placed in the Service Path Identifier field of the 502 NSH header of any packet sent on this Service Function Path. It is 503 expected that one or more Controllers will originate these routes in 504 order to configure a service function overlay network. 506 The SFP is described in a new BGP Path attribute, the SFP attribute. 507 Section 3.2.1 shows the format of that attribute. 509 3.2.1. The SFP Attribute 511 [RFC4271] defines the BGP Path attribute. This document introduces a 512 new Path attribute called the SFP attribute with value TBD3 to be 513 assigned by IANA. The first SFP attribute MUST be processed and 514 subsequent instances MUST be ignored. 516 The common fields of the SFP attribute are set as follows: 518 o Optional bit is set to 1 to indicate that this is an optional 519 attribute. 521 o The Transitive bit is set to 1 to indicate that this is a 522 transitive attribute. 524 o The Extended Length bit is set according to the length of the SFP 525 attribute as defined in [RFC4271]. 527 o The Attribute Type Code is set to TBD3. 529 The content of the SFP attribute is a series of Type-Length-Variable 530 (TLV) constructs. Each TLV may include sub-TLVs. All TLVs and sub- 531 TLVs have a common format that is: 533 o Type: A single octet indicating the type of the SFP attribute TLV. 534 Values are taken from the registry described in Section 10.3. 536 o Length: A two octet field indicating the length of the data 537 following the Length field counted in octets. 539 o Value: The contents of the TLV. 541 The formats of the TLVs defined in this document are shown in the 542 following sections. The presence rules and meanings are as follows. 544 o The SFP attribute contains a sequence of zero or more Association 545 TLVs. That is, the Association TLV is optional. Each Association 546 TLV provides an association between this SFPR and another SFPR. 547 Each associated SFPR is indicated using the RD with which it is 548 advertised (we say the SFPR-RD to avoid ambiguity). 550 o The SFP attribute contains a sequence of one or more Hop TLVs. 551 Each Hop TLV contains all of the information about a single hop in 552 the SFP. 554 o Each Hop TLV contains an SI value and a sequence of one or more 555 SFT TLVs. Each SFT TLV contains an SFI reference for each 556 instance of an SF that is allowed at this hop of the SFP for the 557 specific SFT. Each SFI is indicated using the RD with which it is 558 advertised (we say the SFIR-RD to avoid ambiguity). 560 3.2.1.1. The Association TLV 562 The Association TLV is an optional TLV in the SFP attribute. It may 563 be present multiple times. Each occurrence provides an association 564 with another SFP as advertised in another SFPR. The format of the 565 Association TLV is shown in Figure 5 567 +--------------------------------------------+ 568 | Type = 1 (1 octet) | 569 +--------------------------------------------| 570 | Length (2 octets) | 571 +--------------------------------------------| 572 | Association Type (1 octet) | 573 +--------------------------------------------| 574 | Associated SFPR-RD (8 octets) | 575 +--------------------------------------------| 576 | Associated SPI (3 octets) | 577 +--------------------------------------------+ 579 Figure 5: The Format of the Association TLV 581 The fields are as follows: 583 Type is set to 1 to indicate an Association TLV. 585 Length indicates the length in octets of the Association Type and 586 Associated SFPR-RD fields. The value of the Length field is 12. 588 The Association Type field indicate the type of association. The 589 values are tracked in an IANA registry (see Section 10.4). Only 590 one value is defined in this document: type 1 indicates 591 association of two unidirectional SFPs to form a bidirectional 592 SFP. An SFP attribute SHOULD NOT contain more than one 593 Association TLV with Association Type 1: if more than one is 594 present, the first one MUST be processed and subsequent instances 595 MUST be ignored. Note that documents that define new Association 596 Types must also define the presence rules for Association TLVs of 597 the new type. 599 The Associated SFPR-RD contains the RD of some other SFPR 600 advertisement that contains the SFP with which this SFP is 601 associated. 603 The Associated SPI contains the SPI of the associated SFP as 604 advertised in the SFPR indicated by the Associated SFPR-RD field. 606 Association TLVs with unknown Association Type values SHOULD be 607 ignored. Association TLVs that contain an Associated SFPR-RD value 608 equal to the RD of the SFPR in which they are contained SHOULD be 609 ignored. If the Associated SPI is not equal to the SPI advertised in 610 the SFPR indicated by the Associated SFPR-RD then the Association TLV 611 SHOULD be ignored. 613 Note that when two SFPRs reference each other using the Association 614 TLV, one SFPR advertisement will be received before the other. 615 Therefore, processing of an association MUST NOT be rejected simply 616 because the Associated SFPR-RD is unknown. 618 Further discussion of correlation of SFPRs is provided in 619 Section 7.2. 621 3.2.1.2. The Hop TLV 623 There is one Hop TLV in the SFP attribute for each hop in the SFP. 624 The format of the Hop TLV is shown in Figure 6. At least one Hop TLV 625 must be present in an SFP attribute. 627 +--------------------------------------------+ 628 | Type = 2 (1 octet) | 629 +--------------------------------------------| 630 | Length (2 octets) | 631 +--------------------------------------------| 632 | Service Index (1 octet) | 633 +--------------------------------------------| 634 | Hop Details (variable) | 635 +--------------------------------------------+ 637 Figure 6: The Format of the Hop TLV 639 The fields are as follows: 641 Type is set to 2 to indicate a Hop TLV. 643 Length indicates the length in octets of the Service Index and Hop 644 Details fields. 646 The Service Index is defined in [I-D.ietf-sfc-nsh] and is the 647 value found in the Service Index field of the NSH header that an 648 SFF will use to lookup to which next SFI a packet should be sent. 650 The Hop Details consist of a sequence of one or more SFT TLVs. 652 3.2.1.3. The SFT TLV 654 There is one or more SFT TLV in each Hop TLV. There is one SFT TLV 655 for each SFT supported in the specific hop of the SFP. The format of 656 the SFT TLV is shown in Figure 7. 658 +--------------------------------------------+ 659 | Type = 3 (1 octet) | 660 +--------------------------------------------| 661 | Length (2 octets) | 662 +--------------------------------------------| 663 | Service Function Type (2 octets) | 664 +--------------------------------------------| 665 | SFIR-RD List (variable) | 666 +--------------------------------------------+ 668 Figure 7: The Format of the SFT TLV 670 The fields are as follows: 672 Type is set to 3 to indicate an SFT TLV. 674 Length indicates the length in octets of the Service Function Type 675 and SFIR-RD List fields. 677 The Service Function Type is used to identify a Service Function 678 Instance Route in the service function overlay network which, in 679 turn, will allow lookup of routes to SFIs implementing the SF. 680 SFT values in the range 1-31 are Special Purpose SFT values and 681 have meanings defined by the documents that describe them - the 682 value 'Change Sequence' is defined in Section 6.1 of this 683 document. 685 The SFIR-RD List is made up of one or more SFIR-RD values from the 686 advertisements of SFIs in SFIRs. An SFIR-RD of value zero has 687 special meaning as described in Section 5. Each entry in the list 688 is 8 octets long, and the number of entries in the list can be 689 deduced from the value of the Length field. 691 3.2.2. General Rules For The SFP Attribute 693 It is possible for the same SFI, as described by an SFIR, to be used 694 in multiple SFPRs. 696 When two SFPRs have the same SPI but different SFPR-RDs there can be 697 three cases: 699 o Two or more Controllers are originating SFPRs for the same SFP. 700 In this case the content of the SFPRs is identical and the 701 duplication is to ensure receipt and to provide Controller 702 redundancy. 704 o There is a transition in content of the advertised SFP and the 705 advertisements may originate from one or more Controllers. In 706 this case the content of the SFPRs will be different. 708 o The reuse of an SPI may result from a configuration error. 710 In all cases, there is no way for the receiving SFF to know which 711 SFPR to process, and the SFPRs could be received in any order. At 712 any point in time, when multiple SFPRs have the same SPI but 713 different SFPR-RDs, the SFF MUST use the SFPR with the numerically 714 lowest SFPR-RD. The SFF SHOULD log this occurrence to assist with 715 debugging. 717 Furthermore, a Controller that wants to change the content of an SFP 718 is RECOMMENDED to use a new SPI and so create a new SFP onto which 719 the Classifiers can transition packet flows before the SFPR for the 720 old SFP is withdrawn. This avoids any race conditions with SFPR 721 advertisements. 723 Additionally, a Controller SHOULD NOT re-use an SPI after it has 724 withdrawn the SFPR that used it until at least a configurable amount 725 of time has passed. This timer SHOULD have a default of one hour. 727 4. Mode of Operation 729 This document describes the use of BGP as a control plane to create 730 and manage a service function overlay network. 732 4.1. Route Targets 734 The main feature introduced by this document is the ability to create 735 multiple service function overlay networks through the use of Route 736 Targets (RTs) [RFC4364]. 738 Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. 739 The RT carried by a particular SFIR or SFPR is determined by the 740 provisioning of the route's originator. 742 Every node in a service function overlay network is configured with 743 one or more import RTs. Thus, each SFF will import only the SFPRs 744 with matching RTs allowing the construction of multiple service 745 function overlay networks or the instantiation of Service Function 746 Chains within an L3VPN or EVPN instance (see Section 7.4). An SFF 747 that has a presence in multiple service function overlay networks 748 (i.e., imports more than one RT) may find it helpful to maintain 749 separate forwarding state for each overlay network. 751 4.2. Service Function Instance Routes 753 The SFIR (see Section 3.1) is used to advertise the existence and 754 location of a specific Service Function Instance and consists of: 756 o The RT as just described. 758 o A Service Function Type (SFT) that is the category of Service 759 Function that is provided (such as "firewall"). 761 o A Route Distinguisher (RD) that is unique to a specific instance 762 of a service function. 764 4.3. Service Function Path Routes 766 The SFPR (see Section 3.2) describes a specific path of a Service 767 Function Chain. The SFPR contains the Service Path Identifier (SPI) 768 used to identify the SFP in the NSH in the data plane. It also 769 contains a sequence of Service Indexes (SIs). Each SI identifies a 770 hop in the SFP, and each hop is a choice between one of more SFIs. 772 As described in this document, each Service Function Path Route is 773 identified in the service function overlay network by an RD and an 774 SPI. The SPI is unique within a single VPN instance supported by the 775 underlay network. 777 The SFPR advertisement comprises: 779 o An RT as described in Section 4.1. 781 o A tuple that identifies the SFPR 783 * An RD that identifies an advertisement of an SFPR. 785 * The SPI that uniquely identifies this path within the VPN 786 instance distinguished by the RD. This SPI also appears in the 787 NSH. 789 o A series of Service Indexes. Each SI is used in the context of a 790 particular SPI and identifies one or more SFs (distinguished by 791 their SFTs) and for each SF a set of SFIs that instantiate the SF. 792 The values of the SI indicate the order in which the SFs are to be 793 executed in the SFP that is represented by the SPI. 795 o The SI is used in the NSH to identify the entries in the SFP. 796 Note that the SI values have meaning only relative to a specific 797 path. They have no semantic other than to indicate the order of 798 Service Functions within the path and are assumed to be 799 monotonically decreasing from the start to the end of the path 800 [I-D.ietf-sfc-nsh]. 802 o Each Service Index is associated with a set of one or more Service 803 Function Instances that can be used to provide the indexed Service 804 Function within the path. Each member of the set comprises: 806 * The RD used in an SFIR advertisement of the SFI. 808 * The SFT that indicates the type of function as used in the same 809 SFIR advertisement of the SFI. 811 This may be summarized as follows where the notations "SFPR-RD" and 812 "SFIR-RD" are used to distinguish the two different RDs: 814 RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } } 816 Where: 818 RT: Route Target 820 SFPR-RD: The Route Descriptor of the Service Function Path Route 821 advertisement 823 SPI: Service Path Identifier used in the NSH 825 m: The number of hops in the Service Function Path 827 n: The number of choices of Service Function Type for a specific 828 hop 830 p: The number of choices of Service Function Instance for given 831 Service Function Type in a specific hop 833 SI: Service Index used in the NSH to indicate a specific hop 835 SFT: The Service Function Type used in the same advertisement of 836 the Service Function Instance Route 838 SFIR-RD: The Route Descriptor used in an advertisement of the 839 Service Function Instance Route 841 Note that the values of SI are from the set {255, ..., 1} and are 842 monotonically decreasing within the SFP. SIs MUST appear in order 843 within the SFPR (i.e., monotonically decreasing) and MUST NOT appear 844 more than once. Gaps MAY appear in the sequence as described in 845 Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any 846 previous instance of the SFPR (same SFPR-RD and SPI) to be discarded. 848 The choice of SFI is explained further in Section 5. Note that an 849 SFIR-RD value of zero has special meaning as described in that 850 Section. 852 4.4. Classifier Operation 854 As shown in Figure 1, the Classifier is a special Service Function 855 that is used to assign packets to an SFP. 857 The Classifier is responsible for determining to which packet flow a 858 packet belongs (usually by inspecting the packet header), imposing an 859 NSH, and initializing the NSH to include the SPI of the selected SFPR 860 and to include the SI from first hop of the selected SFP. 862 The Classifier may also provide an entropy indicator as described in 863 Section 7.1. 865 4.5. Service Function Forwarder Operation 867 Each packet sent to an SFF is transmitted encapsulated in an NSH. 868 The NSH includes an SPI and SI: the SPI indicates the SFPR 869 advertisement that announced the Service Function Path; the tuple 870 SPI/SI indicates a specific hop in a specific path and maps to the 871 RD/SFT of a particular SFIR advertisement. 873 When an SFF gets an SFPR advertisement it will first determine 874 whether to import the route by examining the RT. If the SFPR is 875 imported the SFF then determines whether it is on the SFP by looking 876 for its own SFIR-RDs in the SFPR. For each occurrence in the SFP, 877 the SFF creates forwarding state for incoming packets and forwarding 878 state for outgoing packets that have been processed by the specified 879 SFI. 881 The SFF creates local forwarding state for packets that it receives 882 from other SFFs. This state makes the association between the SPI/SI 883 in the NSH of the received packet and one or more specific local SFIs 884 as identified by the SFIR-RD/SFT. If there are multiple local SFIs 885 that match this is because a single advertisement was made for a set 886 of equivalent SFIs and the SFF may use local policy (such as load 887 balancing) to determine to which SFI to forward a received packet. 889 The SFF also creates next hop forwarding state for packets received 890 back from the local SFI that need to be forwarded to the next hop in 891 the SFP. There may be a choice of next hops as described in 892 Section 4.3. The SFF could install forwarding state for all 893 potential next hops, or it could choose to only install forwarding 894 state to a subset of the potential next hops. If a choice is made 895 then it will be as described in Section 5. 897 The installed forwarding state may change over time reacting to 898 changes in the underlay network and the availability of particular 899 SFIs. 901 Note that SFFs only create and store forwarding state for the SFPs on 902 which they are included. They do not retain state for all SFPs 903 advertised. 905 An SFF may also install forwarding state to support looping, jumping, 906 and branching. The protocol mechanism for explicit control of 907 looping, jumping, and branching is described in Section 6.1 using a 908 special value of the SFT within an entry in an SFPR. 910 4.5.1. Processing With 'Gaps' in the SI Sequence 912 The behavior of an SF as described in [I-D.ietf-sfc-nsh] is to 913 decrement the value of the SI field in the NSH by one before 914 returning a packet to the local SFF for further processing. This 915 means that there is a good reason to assume that the SFP is composed 916 of a series of SFs each indicated by an SI value one less than the 917 previous. 919 However, there is an advantage to having non-successive SIs in an 920 SPI. Consider the case where an SPI needs to be modified by the 921 insertion or removal of an SF. In the latter case this would lead to 922 a "gap" in the sequence of SIs, and in the former case, this could 923 only be achieved if a gap already existed into which the new SF with 924 its new SI value could be inserted. Otherwise, all "downstream" SFs 925 would need to be renumbered. 927 Now, of course, such renumbering could be performed, but would lead 928 to a significant disruption to the SFC as all the SFFs along the SFP 929 were "reprogrammed". Thus, to achieve dynamic modification of an SFP 930 (and even, in-service modification) it is desirable to be able to 931 make these modifications without changing the SIs of the elements 932 that were present before the modification. This will produce much 933 more consistent/predictable behavior during the convergence period 934 where otherwise the change would need to be fully propagated. 936 Another approach says that any change to an SFP simply creates a new 937 SFP that can be assigned a new SPI. All that would be needed would 938 be to give a new instruction to the Classifier and traffic would be 939 switched to the new SFP that contains the new set of SFs. This 940 approach is practical, but neglects to consider that the SFP may be 941 referenced by other SFPs (through "branch" instructions) and used by 942 many Classifiers. In those cases the corresponding configuration 943 resulting from a change in SPI may have wide ripples and give scope 944 for errors that are hard to trace. 946 Therefore, while this document requires that the SI values in an SFP 947 are monotonic decreasing, it makes no assumption that the SI values 948 are sequential. Configuration tools may apply that rule, but they 949 are not required to. To support this, an SFF SHOULD process as 950 follows when it receives a packet: 952 o If the SI indicates a known entry in the SFP, the SFF MUST process 953 the packet as normal, looking up the SI and determining whether to 954 deliver the packet to a local SFI or to forward it to another SFF. 956 o If the SI does not match an entry in the SFP, the SFF MUST reduce 957 the SI value to the next (smaller) value present in the SFP and 958 process the packet using that SI. 960 o If there is no smaller SI (i.e., if the end of the SFP has been 961 reached) the SFF MUST treat the SI value as invalid as described 962 in [I-D.ietf-sfc-nsh]. 964 SFF implementations MAY choose to only support contiguous SI values 965 in an SFP. Such an implementation will not support receiving an SI 966 value that is not present in the SFP and will discard the packets as 967 described in [I-D.ietf-sfc-nsh]. 969 5. Selection in Service Function Paths 971 As described in Section 2 the SPI/SI in the NSH passed back from an 972 SFI to the SFF may leave the SFF with a choice of next hop SFTs, and 973 a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, 974 and the SI indicates an entry in that SFPR. Each entry in an SFPR is 975 a set of one or more SFT/SFIR-RD pairs. The SFF must choose one of 976 these, identify the SFF that supports the chosen SFI, and send the 977 packet to that next hop SFF. 979 The choice may offered for load balancing across multiple SFIs, or 980 for discrimination between different actions necessary at a specific 981 hop in the SFP. Different SFT values may exist at a given hop in an 982 SFP to support several cases: 984 o There may be multiple instances of similar service functions that 985 are distinguished by different SFT values. For example, firewalls 986 made by vendor A and vendor B may need to be identified by 987 different SFT values because, while they have similar 988 functionality, their behavior is not identical. Then, some SFPs 989 may limit the choice of SF at a given hop by specifying the SFT 990 for vendor A, but other SFPs might not need to control which 991 vendor's SF is used and so can indicate that either SFT can be 992 used. 994 o There may be an obvious branch needed in an SFP such as the 995 processing after a firewall where admitted packets continue along 996 the SFP, but suspect packets are diverted to a "penalty box". In 997 this case, the next hop in the SFP will be indicated with two 998 different SFT values. 1000 In the typical case, the SFF chooses a next hop SFF by looking at the 1001 set of all SFFs that support the SFs identified by the SI (that set 1002 having been advertised in individual SFIR advertisements), finding 1003 the one or more that are "nearest" in the underlay network, and 1004 choosing between next hop SFFs using its own load-balancing 1005 algorithm. 1007 An SFI may influence this choice process by passing additional 1008 information back along with the packet and NSH. This information may 1009 influence local policy at the SFF to cause it to favor a next hop SFF 1010 (perhaps selecting one that is not nearest in the underlay), or to 1011 influence the load-balancing algorithm. 1013 This selection applies to the normal case, but also applies in the 1014 case of looping, jumping, and branching (see Section 6). 1016 Suppose an SFF in a particular service overlay network (identified by 1017 a particular import RT, RT-z) needs to forward an NSH-encapsulated 1018 packet whose SPI is SPI-x and whose SI is SI-y. It does the 1019 following: 1021 1. It looks for an installed SFPR that carries RT-z and that has 1022 SPI-x in its NLRI. If there is none, then such packets cannot be 1023 forwarded. 1025 2. From the SFP attribute of that SFPR, it finds the Hop TLV with SI 1026 value set to SI-y. If there is no such Hop TLV, then such 1027 packets cannot be forwarded. 1029 3. It then finds the "relevant" set of SFIRs by going through the 1030 list of SFT TLVs contained in the Hop TLV as follows: 1032 A. An SFIR is relevant if it carries RT-z, the SFT in its NLRI 1033 matches the SFT value in one of the SFT TLVs, and the RD 1034 value in its NLRI matches an entry in the list of SFIR-RDs in 1035 that SFT TLV. 1037 B. If an entry in the SFIR-RD list of an SFT TLV contains the 1038 value zero, then an SFIR is relevant if it carries RT-z and 1039 the SFT in its NLRI matches the SFT value in that SFT TLV. 1040 I.e., any SFIR in the service function overlay network 1041 defined by RT-z and with the correct SFT is relevant. 1043 Each of the relevant SFIRs identifies a single SFI, and contains a 1044 Tunnel Encapsulation attribute that specifies how to send a packet to 1045 that SFI. For a particular packet, the SFF chooses a particular SFI 1046 from the set of relevant SFIRs. This choice is made according to 1047 local policy. 1049 A typical policy might be to figure out the set of SFIs that are 1050 closest, and to load balance among them. But this is not the only 1051 possible policy. 1053 6. Looping, Jumping, and Branching 1055 As described in Section 2 an SFI or an SFF may cause a packets to 1056 "loop back" to a previous SF on a path in order that a sequence of 1057 functions may be re-executed. This is simply achieved by replacing 1058 the SI in the NSH with a higher value instead of decreasing it as 1059 would normally be the case to determine the next hop in the path. 1061 Section 2 also describes how an SFI or an SFF may cause a packets to 1062 "jump forward" to an SF on a path that is not the immediate next SF 1063 in the SFP. This is simply achieved by replacing the SI in the NSH 1064 with a lower value than would be achieved by decreasing it by the 1065 normal amount. 1067 A more complex option to move packets from one SFP to another is 1068 described in [I-D.ietf-sfc-nsh] and Section 2 where it is termed 1069 "branching". This mechanism allows an SFI or SFF to make a choice of 1070 downstream treatments for packets based on local policy and output of 1071 the local SF. Branching is achieved by changing the SPI in the NSH 1072 to indicate the new path and setting the SI to indicate the point in 1073 the path at which the packets should enter. 1075 Note that the NSH does not include a marker to indicate whether a 1076 specific packet has been around a loop before. Therefore, the use of 1077 NSH metadata may be required in order to prevent infinite loops. 1079 6.1. Protocol Control of Looping, Jumping, and Branching 1081 If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT 1082 value "Change Sequence" (see Section 10) then this is an indication 1083 that the SFF may make a loop, jump, or branch according to local 1084 policy and information returned by the local SFI. 1086 In this case, the SPI and SI of the next hop is encoded in the eight 1087 bytes of an entry in the SFIR-RD list as follows: 1089 3 bytes SPI 1091 2 bytes SI 1093 3 bytes Reserved (SHOULD be set to zero and ignored) 1095 If the SI in this encoding is not part of the SFPR indicated by the 1096 SPI in this encoding, then this is an explicit error that SHOULD be 1097 detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT 1098 cause any forwarding state to be installed in the SFF and packets 1099 received with the SPI that indicates this SFPR SHOULD be silently 1100 discarded. 1102 If the SPI in this encoding is unknown, the SFF SHOULD NOT install 1103 any forwarding state for this SFPR, but MAY hold the SFPR pending 1104 receipt of another SFPR that does use the encoded SPI. 1106 If the SPI matches the current SPI for the path, this is a loop or 1107 jump. In this case, if the SI is greater than to the current SI it 1108 is a loop. If the SPI matches and the SI is less than the next SI, 1109 it is a jump. 1111 If the SPI indicates anther path, this is a branch and the SI 1112 indicates the point at which to enter that path. 1114 The Change Sequence SFT is just another SFT that may appear in a set 1115 of SFI/SFT tuples within an SI and is selected as described in 1116 Section 5. 1118 Note that Special Purpose SFTs MUST NOT be advertised in SFIRs. 1120 6.2. Implications for Forwarding State 1122 Support for looping and jumping requires that the SFF has forwarding 1123 state established to an SFF that provides access to an instance of 1124 the appropriate SF. This means that the SFF must have seen the 1125 relevant SFIR advertisements and known that it needed to create the 1126 forwarding state. This is a matter of local configuration and 1127 implementation: for example, an implementation could be configured to 1128 install forwarding state for specific looping/jumping. 1130 Support for branching requires that the SFF has forwarding state 1131 established to an SFF that provides access to an instance of the 1132 appropriate entry SF on the other SFP. This means that the SFF must 1133 have seen the relevant SFIR and SFPR advertisements and known that it 1134 needed to create the forwarding state. This is a matter of local 1135 configuration and implementation: for example, an implementation 1136 could be configured to install forwarding state for specific 1137 branching (identified by SPI and SI). 1139 7. Advanced Topics 1141 This section highlights several advanced topics introduced elsewhere 1142 in this document. 1144 7.1. Preserving Entropy 1146 Forwarding decisions in the underlay network in the presence of equal 1147 cost multipath (ECMP) are usually made by inspecting key invariant 1148 fields in a packet header so that all packets from the same packet 1149 flow receive the same forwarding treatment. However, when an NSH is 1150 included in a packet, those key fields may be inaccessible. For 1151 example, the fields may be too far inside the packet for a forwarding 1152 engine to quickly find them and extract their values, or the node 1153 performing the examination may be unaware of the format and meaning 1154 of the NSH and so unable to parse far enough into the packet. 1156 Various mechanisms exist within forwarding technologies to include an 1157 "entropy indicator" within a forwarded packet. For example, in MPLS 1158 there is the entropy label [RFC6790], while for encapsulations in UDP 1159 the source port field is often used to carry an entropy indicator 1160 (such as for MPLS in UDP [RFC7510]). 1162 Implementations of this specification are RECOMMENDED to include an 1163 entropy indicator within the packet's underlay network header, and 1164 SHOULD preserve any entropy indicator from a received packet for use 1165 on the same packet when it is forwarded along the path but MAY choose 1166 to generate a new entropy indicator so long as the method used is 1167 constant for all packets. Note that preserving per packet entropy 1168 may require that the entropy indicator is passed to and returned by 1169 the SFI to prevent the SFF from having to maintain per-packet state. 1171 7.2. Correlating Service Function Path Instances 1173 It is often useful to create bidirectional SFPs to enable packet 1174 flows to traverse the same set of SFs, but in the reverse order. 1175 However, packets on SFPs in the data plane (per [I-D.ietf-sfc-nsh]) 1176 do not contain a direction indicator, so each direction must use a 1177 different SPI. 1179 As described in Section 3.2.1.1 an SFPR can contain one or more 1180 correlators encoded in Association TLVs. If the Association Type 1181 indicates "Bidirectional SFP" then the SFP advertised in the SFPR is 1182 one direction of a bidirectional pair of SFPs where the other in the 1183 pair is advertised in the SFPR with RD as carried in the Associated 1184 SFPR-RD field of the Association TLV. The SPI carried in the 1185 Associated SPI field of the Association TLV provides a cross-check 1186 and should match the SPI advertised in the SFPR with RD as carried in 1187 the Associated SFPR-RD field of the Association TLV. 1189 As noted in Section 3.2.1.1 SFPRs reference each other one SFPR 1190 advertisement will be received before the other. Therefore 1191 processing of an association will require that the first SFPR is not 1192 rejected simply because the Associated SFPR-RD it carries is unknown. 1193 However, the SFP defined by the first SFPR is valid and SHOULD be 1194 available for use as a unidirectional SFP even in the absence of an 1195 advertisement of its partner. 1197 Furthermore, in error cases where SFPR-a associates with SFPR-b, but 1198 SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs 1199 cannot be formed, the individual SFPs are still valid and SHOULD be 1200 available for use as unidirectional SFPs. An implementation SHOULD 1201 log this situation because it represents a Controller error. 1203 Usage of a bidirectional SFP may be programmed into the Classifiers 1204 by the Controller. Alternatively, a Classifier may look at incoming 1205 packets on a bidirectional packet flow, extract the SPI from the 1206 received NSH, and look up the SFPR to find the reverse direction SFP 1207 to use when it sends packets. 1209 See Section 8 for an example of how this works. 1211 7.3. Considerations for Stateful Service Functions 1213 Some service functions are stateful. That means that they build and 1214 maintain state derived from configuration or from the packet flows 1215 that they handle. In such cases it can be important or necessary 1216 that all packets from a flow continue to traverse the same instance 1217 of a service function so that the state can be leveraged and does not 1218 need to be regenerated. 1220 In the case of bidirectional SFPs, it may be necessary to traverse 1221 the same instances of a stateful service function in both directions. 1222 A firewall is a good example of such a service function. 1224 This issue becomes a concern where there are multiple parallel 1225 instances of a service function and a determination of which one to 1226 use could normally be left to the SFF as a load-balancing or local 1227 policy choice. 1229 For the forward direction SFP, the concern is that the same choice of 1230 service function is made for all packets of a flow under normal 1231 network conditions. It may be possible to guarantee that the load 1232 balancing functions applied in the SFFs are stable and repeatable, 1233 but a controller that constructs SFPs might not want to trust to 1234 this. The controller can, in these cases, build a number of more 1235 specific SFPs each traversing a specific instance of the stateful 1236 SFs. In this case, the load balancing choice can be left up to the 1237 Classifier. Thus the Classifier selects which instance of a stateful 1238 SF is used by a particular flow by selecting the SFP that the flow 1239 uses. 1241 For bidirectional SFPs where the same instance of a stateful SF must 1242 be traversed in both directions, it is not enough to leave the choice 1243 of service function instance as a local choice even if the load 1244 balancing is stable because coordination would be required between 1245 the decision points in the forward and reverse directions and this 1246 may be hard to achieve in all cases except where it is the same SFF 1247 that makes the choice in both directions. 1249 Note that this approach necessarily increases the amount of SFP state 1250 in the network (i.e., there are more SFPs). It is possible to 1251 mitigate this effect by careful construction of SFPs built from a 1252 concatenation of other SFPs. 1254 Section 8.9 includes some simple examples of SFPs for stateful 1255 service functions. 1257 7.4. VPN Considerations and Private Service Functions 1259 Likely deployments include reserving specific instances of Service 1260 Functions for specific customers or allowing customers to deploy 1261 their own Service Functions within the network. Building Service 1262 Functions in such environments requires that suitable identifiers are 1263 used to ensure that SFFs distinguish which SFIs can be used and which 1264 cannot. 1266 This problem is similar to how VPNs are supported and is solved in a 1267 similar way. The RT field is used to indicate a set of Service 1268 Functions from which all choices must be made. 1270 7.5. Flow Spec for SFC Classifiers 1272 [RFC5575] defines a set of BGP routes that can be used to identify 1273 the packets in a given flow using fields in the header of each 1274 packet, and a set of actions, encoded as extended communities, that 1275 can be used to disposition those packets. This document enables the 1276 use of RFC 5575 mechanisms by SFC Classifiers by defining a new 1277 action extended community called "Flow spec for SFC classifiers" 1278 identified by the value TBD4. Note that other action extended 1279 communities may also be present. 1281 This extended community is encoded as an 8-octet value, as shown in 1282 Figure 8: 1284 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 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Type=0x80 | Sub-Type=TBD4 | SPI | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | SPI (cont.) | SI | SFT | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 Figure 8: The Format of the Flow Spec for SFC Classifiers Extended 1292 Community 1294 The extended community contains the Service Path Identifier (SPI), 1295 Service Index (SI), and Service Function Type (SFT) as defined 1296 elsewhere in this document. Thus, each action extended community 1297 defines the entry point (not necessarily the first hop) into a 1298 specific service function path. This allows, for example, different 1299 flows to enter the same service function path at different points. 1301 Note that a given Flow Spec update according to [RFC5575] may include 1302 multiple of these action extended communities, and that if a given 1303 action extended community does not contain an installed SFPR with the 1304 specified [SPI, SI, SFT] it MUST NOT be used for dispositioning the 1305 packets of the specified flow. 1307 The normal case of packet classification for SFC will see a packet 1308 enter the SFP at its first hop. In this case the SI in the extended 1309 community is superfluous and the SFT may also be unnecessary. To 1310 allow these cases to be handled, a special meaning is assigned to a 1311 Service Index of zero (not a valid value) and an SFT of zero (a 1312 reserved value in the registry - see Section 10.5). 1314 o If an SFC Classifiers Extended Community is received with SI = 0 1315 then it means that the first hop of the SFP indicated by the SPI 1316 MUST be used. 1318 o If an SFC Classifiers Extended Community is received with SFT = 0 1319 then there are two sub-cases: 1321 * If there is a choice of SFT in the hop indicated by the value 1322 of the SI (including SI = 0) then SFT = 0 means there is a free 1323 choice according to local policy of which SFT to use). 1325 * If there is no choice of SFT in the hop indicated by the value 1326 of SI, then SFT = 0 means that the value of the SFT at that hop 1327 as indicated in the SPFR for the indicated SPI MUST be used. 1329 7.6. Choice of Data Plane SPI/SI Representation 1331 This document ties together the control and data planes of an SFC 1332 overlay network through the use of the SPI/SI which is nominally 1333 carried in the NSH of a given packet. However, in order to handle 1334 situations in which the NSH is not ubiquitously deployed, it is also 1335 possible to use alternative data plane representations of the SPI/SI 1336 by carrying the identical semantics in other protocol fields such as 1337 MPLS labels. 1339 This document defines a new sub-TLV for the Tunnel Encapsulation 1340 attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub- 1341 TLV MAY be present in each Tunnel TLV contained in a Tunnel 1342 Encapsulation attribute when the attribute is carried by an SFIR. 1343 The value field of this sub-TLV is a two octet field of flags, each 1344 of which describes how the originating SFF expects to see the SPI/SI 1345 represented in the data plane for packets carried in the tunnels 1346 described by the Tunnel TLV. 1348 The following bits are defined by this document: 1350 Bit 0: If this bit is set the NSH is to be used to carry the SPI/SI 1351 in the data plane. 1353 Bit 1: If this bit is set two labels in an MPLS label stack are to 1354 be used as described in Section 7.6.1. 1356 If a given Tunnel TLV does not contain an SPI/SI Representation sub- 1357 TLV then it MUST be processed as if such a sub-TLV is present with 1358 Bit 0 set and no other bits set. That is, the absence of the sub-TLV 1359 SHALL be interpreted to mean that the NSH is to be used. 1361 If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with 1362 value field that has no flag set then the tunnel indicated by the 1363 Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given 1364 Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit 0 1365 and bit 1 set then the tunnel indicated by the Tunnel TLV MUST NOT be 1366 used for forwarding SFC packets. The meaning and rules for presence 1367 of other bits is to be defined in future documents, but 1368 implementations of this specification MUST set other bits to zero and 1369 ignore them on receipt. 1371 If a given Tunnel TLV contains more than one SPI/SI Representation 1372 sub-TLV then the first one MUST be considered and subsequent 1373 instances MUST be ignored. 1375 Note that the MPLS representation of the logical NSH may be used even 1376 if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be 1377 used to carry other encodings of the logical NSH (specifically, the 1378 NSH itself). It is a requirement that both ends of a tunnel over the 1379 underlay network know that the tunnel is used for SFC and know what 1380 form of NSH representation is used. The signaling mechanism 1381 described here allows coordination of this information. 1383 7.6.1. MPLS Representation of the SPI/SI 1385 If bit 1 is set in the in the SPI/SI Representation sub-TLV then two 1386 labels in the label stack are used to indicate the SPI and SI to 1387 achieve the semantics of a logical NSH. The label stack appears as 1388 shown in Figure 9. 1390 --------------- 1391 | Tunnel Labels | 1392 +---------------+ 1393 ~ Optional ~ 1394 ~ Entropy Label ~ 1395 +---------------+ 1396 | SPI Label | 1397 +---------------+ 1398 | SI Label | 1399 +---------------+ 1400 | | 1401 ~ Payload ~ 1402 | | 1403 --------------- 1405 Figure 9: The MPLS Label Stack with Logical NSH 1407 As can be seen from the figure, the top of the label stack comprises 1408 the labels necessary to deliver the packet over the MPLS tunnel 1409 between SFFs. Any of the MPLS encapsulations defined for the Tunnel 1410 Encapsulation may be used (i.e., MPLS, MPLS in GRE, and MPLS in VXLAN 1411 or GPE) and an entropy label ([RFC6790]) may also be present as 1412 described in Section 7.1. 1414 Under these labels comes the SPI label stack entry and the SI label 1415 stack entry. Each of these label stack entries is formatted as 1416 normal (see [RFC3032] and the fields are encoded as follows: 1418 Label: The Label field contains the value of the SPI or SI encoded 1419 as a 20 bit integer. Since the SI only requires 8 bits, it is 1420 right-justified with the high order 12 bits set to zero. Note 1421 that an SPI as defined by [I-D.ietf-sfc-nsh] can be encoded in 3 1422 octets (i.e., 24 bits) but that the Label field allows for only 20 1423 bits. Thus, a system using MPLS representation of the logical NSH 1424 MUST NOT assign SPI values greater than 2^20 - 1. 1426 TC: The TC bits have no meaning. They SHOULD be set to zero and 1427 MUTS be ignored. 1429 S: The bottom of stack flag has its usual meaning in MPLS. It MUST 1430 be clear in the SPI label stack entry and MAY be set in the SI 1431 label stack entry depending on whether the payload is MPLS (not 1432 set) or not MPLS (set). 1434 TTL: The TTL field in the SPI label stack entry SHOULD be set to 1. 1435 The TTL in SI label stack entry (called the SI TTL) is used to 1436 count progress along the SFP and to prevent looping. It is 1437 decremented once for each hop in the SFP, i.e., for each SFI 1438 executed. 1440 * When a Classifier places a packet onto an SFP it MUST set the 1441 SI TTL to a value between 1 and 255. It should set this 1442 according to the expected length of the SFP, but it MAY set it 1443 to a larger value according to local configuration. 1445 * When an SFF receives a packet from the Classifier or another 1446 SFF it MUST discard any packets with SI TTL set to zero. It 1447 SHOULD log such occurrences, but MUST apply rate limiting to 1448 any such logs. 1450 * An SFF MUST decrement the SI TTL by one each time it sends the 1451 packet to an SFI (local or remote) or to another SFF 1453 * If an SFF decrements the SI TTL to zero it MUST NOT send the 1454 packet, but MUST discard the packet. It SHOULD log such 1455 occurrences, but MUST apply rate limiting to any such logs. 1457 * SFIs MUST ignore the SI TTL, but MUST mirror it back to the SFF 1458 unmodified along with the SI (which may have been changed). 1460 * If a Classifier along the SFP makes any change to the intended 1461 path of the packet including for looping, jumping, or branching 1462 (see Section 6 and Section 6.1) it MUST NOT change the SI TTL 1463 of the packet. In particular, every component of the SFC 1464 system MUST NOT increase the SI TTL value. 1466 8. Examples 1468 Assume we have a service function overlay network with four SFFs 1469 (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the 1470 underlay network as follows: 1472 SFF1 192.0.2.1 1473 SFF2 192.0.2.2 1474 SFF3 192.0.2.3 1475 SFF4 192.0.2.4 1477 Each SFF provides access to some SFIs from the four Service Function 1478 Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows: 1480 SFF1 SFT=41 and SFT=42 1481 SFF2 SFT=41 and SFT=43 1482 SFF3 SFT=42 and SFT=44 1483 SFF4 SFT=43 and SFT=44 1485 The service function network also contains a Controller with address 1486 198.51.100.1. 1488 This example service function overlay network is shown in Figure 10. 1490 -------------- 1491 | Controller | 1492 | 198.51.100.1 | ------ ------ ------ ------ 1493 -------------- | SFI | | SFI | | SFI | | SFI | 1494 |SFT=41| |SFT=42| |SFT=41| |SFT=43| 1495 ------ ------ ------ ------ 1496 \ / \ / 1497 --------- --------- 1498 ---------- | SFF1 | | SFF2 | 1499 Packet --> | | |192.0.2.1| |192.0.2.2| 1500 Flows --> |Classifier| --------- --------- -->Dest 1501 | | --> 1502 ---------- --------- --------- 1503 | SFF3 | | SFF4 | 1504 |192.0.2.3| |192.0.2.4| 1505 --------- --------- 1506 / \ / \ 1507 ------ ------ ------ ------ 1508 | SFI | | SFI | | SFI | | SFI | 1509 |SFT=42| |SFT=44| |SFT=43| |SFT=44| 1510 ------ ------ ------ ------ 1512 Figure 10: Example Service Function Overlay Network 1514 The SFFs advertise routes to the SFIs they support. So we see the 1515 following SFIRs: 1517 RD = 192.0.2.1,1, SFT = 41 1518 RD = 192.0.2.1,2, SFT = 42 1519 RD = 192.0.2.2,1, SFT = 41 1520 RD = 192.0.2.2,2, SFT = 43 1521 RD = 192.0.2.3,7, SFT = 42 1522 RD = 192.0.2.3,8, SFT = 44 1523 RD = 192.0.2.4,5, SFT = 43 1524 RD = 192.0.2.4,6, SFT = 44 1526 Note that the addressing used for communicating between SFFs is taken 1527 from the Tunnel Encapsulation attribute of the SFIR and not from the 1528 SFIR-RD. 1530 8.1. Example Explicit SFP With No Choices 1532 Consider the following SFPR. 1534 SFP1: RD = 198.51.100.1,101, SPI = 15, 1535 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1536 [SI = 250, SFT = 43, RD = 192.0.2.2,2] 1538 The Service Function Path consists of an SF of type 41 located at 1539 SFF1 followed by an SF of type 43 located at SFF2. This path is 1540 fully explicit and each SFF is offered no choice in forwarding packet 1541 along the path. 1543 SFF1 will receive packets on the path from the Classifier and will 1544 identify the path from the SPI (15). The initial SI will be 255 and 1545 so SFF1 will deliver the packets to the SFI for SFT 41. 1547 When the packets are returned to SFF1 by the SFI the SI will be 1548 decreased to 250 for the next hop. SFF1 has no flexibility in the 1549 choice of SFF to support the next hop SFI and will forward the packet 1550 to SFF2 which will send the packets to the SFI that supports SFT 43 1551 before forwarding the packets to their destinations. 1553 8.2. Example SFP With Choice of SFIs 1554 SFP2: RD = 198.51.100.1,102, SPI = 16, 1555 [SI = 255, SFT = 41, RD = 192.0.2.1,], 1556 [SI = 250, SFT = 43, {RD = 192.0.2.2,2, 1557 RD = 192.0.2.4,5 } ] 1559 In this example the path also consists of an SF of type 41 located at 1560 SFF1 and this is followed by an SF of type 43, but in this case the 1561 SI = 250 contains a choice between the SFI located at SFF2 and the 1562 SFI located at SFF4. 1564 SFF1 will receive packets on the path from the Classifier and will 1565 identify the path from the SPI (16). The initial SI will be 255 and 1566 so SFF1 will deliver the packets to the SFI for SFT 41. 1568 When the packets are returned to SFF1 by the SFI the SI will be 1569 decreased to 250 for the next hop. SFF1 now has a choice of next hop 1570 SFF to execute the next hop in the path. It can either forward 1571 packets to SFF2 or SFF4 to execute a function of type 43. It uses 1572 its local load balancing algorithm to make this choice. The chosen 1573 SFF will send the packets to the SFI that supports SFT 43 before 1574 forwarding the packets to their destinations. 1576 8.3. Example SFP With Open Choice of SFIs 1578 SFP3: RD = 198.51.100.1,103, SPI = 17, 1579 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1580 [SI = 250, SFT = 44, RD = 0] 1582 In this example the path also consists of an SF of type 41 located at 1583 SFF1 and this is followed by an SI with an RD of zero and SF of type 1584 44. This means that a choice can be made between any SFF that 1585 supports an SFI of type 44. 1587 SFF1 will receive packets on the path from the Classifier and will 1588 identify the path from the SPI (17). The initial SI will be 255 and 1589 so SFF1 will deliver the packets to the SFI for SFT 41. 1591 When the packets are returned to SFF1 by the SFI the SI will be 1592 decreased to 250 for the next hop. SFF1 now has a free choice of 1593 next hop SFF to execute the next hop in the path selecting between 1594 all SFFs that support SFs of type 44. Looking at the SFIRs it has 1595 received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. 1596 SFF1 uses its local load balancing algorithm to make this choice. 1597 The chosen SFF will send the packets to the SFI that supports SFT 44 1598 before forwarding the packets to their destinations. 1600 8.4. Example SFP With Choice of SFTs 1602 SFP4: RD = 198.51.100.1,104, SPI = 18, 1603 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1604 [SI = 250, {SFT = 43, RD = 192.0.2.2,2, 1605 SFT = 44, RD = 192.0.2.3,8 } ] 1607 This example provides a choice of SF type in the second hop in the 1608 path. The SI of 250 indicates a choice between SF type 43 located 1609 through SF2 and SF type 44 located at SF3. 1611 SFF1 will receive packets on the path from the Classifier and will 1612 identify the path from the SPI (18). The initial SI will be 255 and 1613 so SFF1 will deliver the packets to the SFI for SFT 41. 1615 When the packets are returned to SFF1 by the SFI the SI will be 1616 decreased to 250 for the next hop. SFF1 now has a free choice of 1617 next hop SFF to execute the next hop in the path selecting between 1618 all SFF2 that support an SF of type 43 and SFF3 that supports an SF 1619 of type 44. These may be completely different functions that are to 1620 be executed dependent on specific conditions, or may be similar 1621 functions identified with different type identifiers (such as 1622 firewalls from different vendors). SFF1 uses its local policy and 1623 load balancing algorithm to make this choice, and may use additional 1624 information passed back from the local SFI to help inform its 1625 selection. The chosen SFF will send the packets to the SFI that 1626 supports the chose SFT before forwarding the packets to their 1627 destinations. 1629 8.5. Example Correlated Bidirectional SFPs 1631 SFP5: RD = 198.51.100.1,105, SPI = 19, 1632 Assoc-Type = 1, Assoc-RD = 198.51.100.1,106, Assoc-SPI = 20, 1633 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1634 [SI = 250, SFT = 43, RD = 192.0.2.2,2] 1636 SFP6: RD = 198.51.100.1,106, SPI = 20, 1637 Assoc-Type = 1, Assoc-RD = 198.51.100.1,105, Assoc-SPI = 19, 1638 [SI = 254, SFT = 43, RD = 192.0.2.2,2], 1639 [SI = 249, SFT = 41, RD = 192.0.2.1,1] 1641 This example demonstrates correlation of two SFPs to form a 1642 bidirectional SFP as described in Section 7.2. 1644 Two SFPRs are advertised by the Controller. They have different SPIs 1645 (19 and 20) so they are known to be separate SFPs, but they both have 1646 Association TLVs with Association Type set to 1 indicating 1647 bidirectional SFPs. Each has an Associated SFPR-RD fields containing 1648 the value of the other SFPR-RD to correlated the two SFPs as a 1649 bidirectional pair. 1651 As can be seen from the SFPRs in this example, the paths are 1652 symmetric: the hops in SFP5 appear in the reverse order in SFP6. 1654 8.6. Example Correlated Asymmetrical Bidirectional SFPs 1656 SFP7: RD = 198.51.100.1,107, SPI = 21, 1657 Assoc-Type = 1, Assoc-RD = 198.51.100.1,108, Assoc-SPI = 22, 1658 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1659 [SI = 250, SFT = 43, RD = 192.0.2.2,2] 1661 SFP8: RD = 198.51.100.1,108, SPI = 22, 1662 Assoc-Type = 1, Assoc-RD = 198.51.100.1,107, Assoc-SPI = 21, 1663 [SI = 254, SFT = 44, RD = 192.0.2.4,6], 1664 [SI = 249, SFT = 41, RD = 192.0.2.1,1] 1666 Asymmetric bidirectional SFPs can also be created. This example 1667 shows a pair of SFPs with distinct SPIs (21 and 22) that are 1668 correlated in the same way as in the example in Section 8.5. 1670 However, unlike in that example, the SFPs are different in each 1671 direction. Both paths include a hop of SF type 41, but SFP7 includes 1672 a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF 1673 type 44 supported at SFF4. 1675 8.7. Example Looping in an SFP 1677 SFP9: RD = 198.51.100.1,109, SPI = 23, 1678 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1679 [SI = 250, SFT = 44, RD = 192.0.2.4,5], 1680 [SI = 245, SFT = 1, RD = {SPI=23, SI=255, Rsv=0}], 1681 [SI = 245, SFT = 42, RD = 192.0.2.3,7] 1683 Looping and jumping are described in Section 6. This example shows 1684 an SFP that contains an explicit loop-back instruction that is 1685 presented as a choice within an SFP hop. 1687 The first two hops in the path (SI = 255 and SI = 250) are normal. 1688 That is, the packets will be delivered to SFF1 and SFF4 in turn for 1689 execution of SFs of type 41 and 44 respectively. 1691 The third hop (SI = 245) presents SFF4 with a choice of next hop. It 1692 can either forward the packets to SFF3 for an SF of type 42 (the 1693 second choice), or it can loop back. 1695 The loop-back entry in the SFPR for SI = 245 is indicated by the 1696 special purpose SFT value 1 ("Change Sequence"). Within this hop, 1697 the RD is interpreted as encoding the SPI and SI of the next hop (see 1698 Section 6.1. In this case the SPI is 23 which indicates that this is 1699 loop or branch: i.e., the next hop is on the same SFP. The SI is set 1700 to 255: this is a higher number than the current SI (245) indicating 1701 a loop. 1703 SFF4 must make a choice between these two next hops. Either the 1704 packets will be forwarded to SFF3 with the NSH SI decreased to 245 or 1705 looped back to SFF1 with the NSH SI reset to 255. This choice will 1706 be made according to local policy, information passed back by the 1707 local SFI, and details in the packets' metadata that are used to 1708 prevent infinite looping. 1710 8.8. Example Branching in an SFP 1712 SFP10: RD = 198.51.100.1,110, SPI = 24, 1713 [SI = 254, SFT = 42, RD = 192.0.2.3,7], 1714 [SI = 249, SFT = 43, RD = 192.0.2.2,2] 1716 SFP11: RD = 198.51.100.1,111, SPI = 25, 1717 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1718 [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}] 1720 Branching follows a similar procedure to that for looping (and 1721 jumping) as shown in Section 8.7 however there are two SFPs involved. 1723 SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for 1724 execution of service functions of type 42 and 43 respectively. 1726 SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1 1727 processes the next hop in the path and finds a "Change Sequence" 1728 Special Purpose SFT. The SFIR-RD field includes an SPI of 24 which 1729 indicates SFP10, not the current SFP. The SI in the SFIR-RD is 254, 1730 so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and 1731 send the packets to the appropriate SFF as advertised in the SFPR for 1732 SFP10 (that is, SFF3). 1734 8.9. Examples of SFPs with Stateful Service Functions 1736 This section provides some examples to demonstrate establishing SFPs 1737 when there is a choice of service functions at a particular hop, and 1738 where consistency of choice is required in both directions. The 1739 scenarios that give rise to this requirement are discussed in 1740 Section 7.3. 1742 8.9.1. Forward and Reverse Choice Made at the SFF 1744 Consider the topology shown in Figure 11. There are three SFFs 1745 arranged neatly in a line, and the middle one (SFF2) supports three 1746 SFIs all of SFT 42. These three instances can be used by SFF2 to 1747 load balance so that no one instance is swamped. 1749 ------ ------ ------ ------ ------ 1750 | SFI | | SFIa | | SFIb | | SFIc | | SFI | 1751 |SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43| 1752 ------ ------\ ------ /------ ------ 1753 \ \ | / / 1754 --------- --------- --------- 1755 ---------- | SFF1 | | SFF2 | | SFF3 | 1756 --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> 1757 --> |Classifier| --------- --------- --------- 1758 | | 1759 ---------- 1761 Figure 11: Example Where Choice is Made at the SFF 1763 This leads to the following SFIRs being advertised. 1765 RD = 192.0.2.1,11, SFT = 41 1766 RD = 192.0.2.2,11, SFT = 42 (for SFIa) 1767 RD = 192.0.2.2,12, SFT = 42 (for SFIb) 1768 RD = 192.0.2.2,13, SFT = 42 (for SFIc) 1769 RD = 192.0.2.3,11, SFT = 43 1771 The controller can create a single forward SFP giving SFF2 the choice 1772 of which SFI to use to provide function of SFT 42 as follows. The 1773 load-balancing choice between the three available SFIs is assumed to 1774 be within the capabilities of the SFF and if the SFs are stateful it 1775 is assumed that the SFF knows this and arranges load balancing in a 1776 stable, flow-dependent way. 1778 SFP12: RD = 198.51.100.1,112, SPI = 26, 1779 Assoc-Type = 1, Assoc-RD = 198.51.100.1,113, Assoc-SPI = 27, 1780 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1781 [SI = 254, SFT = 42, {RD = 192.0.2.2,11, 1782 192.0.2.2,12, 1783 192.0.2.2,13 }], 1784 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1786 The reverse SFP in this case may also be created as shown below using 1787 association with the forward SFP and giving the load-balancing choice 1788 to SFF2. This is safe, even in the case that the SFs of type 42 are 1789 stateful because SFF2 is doing the load balancing in both directions 1790 and can apply the same algorithm to ensure that packets associated 1791 with the same flow use the same SFI regardless of the direction of 1792 travel. 1794 SFP13: RD = 198.51.100.1,113, SPI = 27, 1795 Assoc-Type = 1, Assoc-RD = 198.51.100.1,112, Assoc-SPI = 26, 1796 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1797 [SI = 254, SFT = 42, {RD = 192.0.2.2,11, 1798 192.0.2.2,12, 1799 192.0.2.2,13 }], 1800 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1802 8.9.2. Parallel End-to-End SFPs with Shared SFF 1804 The mechanism described in Section 8.9.1 might not be desirable 1805 because of the functional assumptions it places on SFF2 to be able to 1806 load balance with suitable flow identification, stability, and 1807 equality in both directions. Instead, it may be desirable to place 1808 the responsibility for flow classification in the Classifier and let 1809 it determine load balancing with the implied choice of SFIs. 1811 Consider the network graph as shown in Figure 11 and with the same 1812 set of SFIRs as listed in Section 8.9.1. In this case the controller 1813 could specify three forward SFPs with their corresponding associated 1814 reverse SFPs. Each bidirectional pair of SFPs uses a different SFI 1815 for the SF of type 42. The controller can instruct the Classifier 1816 how to place traffic on the three bidirectional SFPs, or can treat 1817 them as a group leaving the Classifier responsible for balancing the 1818 load. 1820 SFP14: RD = 198.51.100.1,114, SPI = 28, 1821 Assoc-Type = 1, Assoc-RD = 198.51.100.1,117, Assoc-SPI = 31, 1822 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1823 [SI = 254, SFT = 42, RD = 192.0.2.2,11], 1824 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1826 SFP15: RD = 198.51.100.1,115, SPI = 29, 1827 Assoc-Type = 1, Assoc-RD = 198.51.100.1,118, Assoc-SPI = 32, 1828 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1829 [SI = 254, SFT = 42, RD = 192.0.2.2,12], 1830 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1832 SFP16: RD = 198.51.100.1,116, SPI = 30, 1833 Assoc-Type = 1, Assoc-RD = 198.51.100.1,119, Assoc-SPI = 33, 1834 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1835 [SI = 254, SFT = 42, RD = 192.0.2.2,13], 1836 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1838 SFP17: RD = 198.51.100.1,117, SPI = 31, 1839 Assoc-Type = 1, Assoc-RD = 198.51.100.1,114, Assoc-SPI = 28, 1840 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1841 [SI = 254, SFT = 42, RD = 192.0.2.2,11], 1842 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1844 SFP18: RD = 198.51.100.1,118, SPI = 32, 1845 Assoc-Type = 1, Assoc-RD = 198.51.100.1,115, Assoc-SPI = 29, 1846 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1847 [SI = 254, SFT = 42, RD = 192.0.2.2,12], 1848 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1850 SFP19: RD = 198.51.100.1,119, SPI = 33, 1851 Assoc-Type = 1, Assoc-RD = 198.51.100.1,116, Assoc-SPI = 30, 1852 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1853 [SI = 254, SFT = 42, RD = 192.0.2.2,13], 1854 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1856 8.9.3. Parallel End-to-End SFPs with Separate SFFs 1858 While the examples in Section 8.9.1 and Section 8.9.2 place the 1859 choice of SFI as subtended from the same SFF, it is also possible 1860 that the SFIs are ach subtended from a different SFF as shown in 1861 Figure 12. In this case it is harder to coordinate the choices for 1862 forward and reverse paths without some form of coordination between 1863 SFF1 and SFF3. Therefore it would be normal to consider end-to-end 1864 parallel SFPs as described in Section 8.9.2. 1866 ------ 1867 | SFIa | 1868 |SFT=42| 1869 ------ 1870 ------ | 1871 | SFI | --------- 1872 |SFT=41| | SFF5 | 1873 ------ ..|192.0.2.5|.. 1874 | ..: --------- :.. 1875 ---------.: :.--------- 1876 ---------- | SFF1 | --------- | SFF3 | 1877 --> | |..|192.0.2.1|....| SFF6 |....|192.0.2.3| --> 1878 --> |Classifier| ---------: |192.0.2.6| :--------- 1879 | | : --------- : | 1880 ---------- : | : ------ 1881 : ------ : | SFI | 1882 :.. | SFIb | ..: |SFT=43| 1883 :.. |SFT=42| ..: ------ 1884 : ------ : 1885 :.---------.: 1886 | SFF7 | 1887 |192.0.2.7| 1888 --------- 1889 | 1890 ------ 1891 | SFIc | 1892 |SFT=42| 1893 ------ 1895 Figure 12: Second Example With Parallel End-to-End SFPs 1897 In this case, five SFIRs are advertised as follows: 1899 RD = 192.0.2.1,11, SFT = 41 1900 RD = 192.0.2.5,11, SFT = 42 (for SFIa) 1901 RD = 192.0.2.6,11, SFT = 42 (for SFIb) 1902 RD = 192.0.2.7,11, SFT = 42 (for SFIc) 1903 RD = 192.0.2.3,11, SFT = 43 1905 In this case the controller could specify three forward SFPs with 1906 their corresponding associated reverse SFPs. Each bidirectional pair 1907 of SFPs uses a different SFF and SFI for middle hop (for an SF of 1908 type 42). The controller can instruct the Classifier how to place 1909 traffic on the three bidirectional SFPs, or can treat them as a group 1910 leaving the Classifier responsible for balancing the load. 1912 SFP20: RD = 198.51.100.1,120, SPI = 34, 1913 Assoc-Type = 1, Assoc-RD = 198.51.100.1,123, Assoc-SPI = 37, 1914 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1915 [SI = 254, SFT = 42, RD = 192.0.2.5,11], 1916 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1918 SFP21: RD = 198.51.100.1,121, SPI = 35, 1919 Assoc-Type = 1, Assoc-RD = 198.51.100.1,124, Assoc-SPI = 38, 1920 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1921 [SI = 254, SFT = 42, RD = 192.0.2.6,11], 1922 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1924 SFP22: RD = 198.51.100.1,122, SPI = 36, 1925 Assoc-Type = 1, Assoc-RD = 198.51.100.1,125, Assoc-SPI = 39, 1926 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1927 [SI = 254, SFT = 42, RD = 192.0.2.7,11], 1928 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1930 SFP23: RD = 198.51.100.1,123, SPI = 37, 1931 Assoc-Type = 1, Assoc-RD = 198.51.100.1,120, Assoc-SPI = 34, 1932 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1933 [SI = 254, SFT = 42, RD = 192.0.2.5,11], 1934 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1936 SFP24: RD = 198.51.100.1,124, SPI = 38, 1937 Assoc-Type = 1, Assoc-RD = 198.51.100.1,121, Assoc-SPI = 35, 1938 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1939 [SI = 254, SFT = 42, RD = 192.0.2.6,11], 1940 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1942 SFP25: RD = 198.51.100.1,125, SPI = 39, 1943 Assoc-Type = 1, Assoc-RD = 198.51.100.1,122, Assoc-SPI = 36, 1944 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1945 [SI = 254, SFT = 42, RD = 192.0.2.7,11], 1946 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1948 8.9.4. Parallel SFPs Downstream of the Choice 1950 The mechanism of parallel SFPs demonstrated in Section 8.9.3 is 1951 perfectly functional and may be practical in many environments. 1952 However, there may be scaling concerns because of the large amount of 1953 state (knowledge of SFPs, i.e., SFPR advertisements retained) if 1954 there is a very large amount of choice of SFIs (for example, tens of 1955 instances of the same stateful SF), or if there are multiple choices 1956 of stateful SF along a path. This situation may be mitigated using 1957 SFP fragments that are combined to form the end to end SFPs. 1959 The example presented here is necessarily simplistic, but should 1960 convey the basic principle. The example presented in Figure 13 is 1961 similar to that in Section 8.9.3 but with an additional first hop. 1963 ------ 1964 | SFIa | 1965 |SFT=43| 1966 ------ 1967 ------ ------ | 1968 | SFI | | SFI | --------- 1969 |SFT=41| |SFT=42| | SFF5 | 1970 ------ ------ ..|192.0.2.5|.. 1971 | | ..: --------- :.. 1972 --------- ---------.: :.--------- 1973 ------ | SFF1 | | SFF2 | --------- | SFF3 | 1974 -->|Class-|.|192.0.2.1|.|192.0.2.2|....| SFF6 |....|192.0.2.3|--> 1975 -->| ifier| --------- ---------: |192.0.2.6| :--------- 1976 ------ : --------- : | 1977 : | : ------ 1978 : ------ : | SFI | 1979 :.. | SFIb | ..: |SFT=44| 1980 :.. |SFT=43| ..: ------ 1981 : ------ : 1982 :.---------.: 1983 | SFF7 | 1984 |192.0.2.7| 1985 --------- 1986 | 1987 ------ 1988 | SFIc | 1989 |SFT=43| 1990 ------ 1992 Figure 13: Example With Parallel SFPs Downstream of Choice 1994 The six SFIs are advertised as follows: 1996 RD = 192.0.2.1,11, SFT = 41 1997 RD = 192.0.2.2,11, SFT = 42 1998 RD = 192.0.2.5,11, SFT = 43 (for SFIa) 1999 RD = 192.0.2.6,11, SFT = 43 (for SFIb) 2000 RD = 192.0.2.7,11, SFT = 43 (for SFIc) 2001 RD = 192.0.2.3,11, SFT = 44 2003 SFF2 is the point at which a load balancing choice must be made. So 2004 "tail-end" SFPs are constructed as follows. Each takes in a 2005 different SFF that provides access to an SF of type 43. 2007 SFP26: RD = 198.51.100.1,126, SPI = 40, 2008 Assoc-Type = 1, Assoc-RD = 198.51.100.1,130, Assoc-SPI = 44, 2009 [SI = 255, SFT = 43, RD = 192.0.2.5,11], 2010 [SI = 254, SFT = 44, RD = 192.0.2.3,11] 2012 SFP27: RD = 198.51.100.1,127, SPI = 41, 2013 Assoc-Type = 1, Assoc-RD = 198.51.100.1,131, Assoc-SPI = 45, 2014 [SI = 255, SFT = 43, RD = 192.0.2.6,11], 2015 [SI = 254, SFT = 44, RD = 192.0.2.3,11] 2017 SFP28: RD = 198.51.100.1,128, SPI = 42, 2018 Assoc-Type = 1, Assoc-RD = 198.51.100.1,132, Assoc-SPI = 46, 2019 [SI = 255, SFT = 43, RD = 192.0.2.7,11], 2020 [SI = 254, SFT = 44, RD = 192.0.2.3,11] 2022 Now an end-to-end SFP with load balancing choice can be constructed 2023 as follows. The choice made by SFF2 is expressed in terms of 2024 entering one of the three "tail end" SFPs. 2026 SFP29: RD = 198.51.100.1,129, SPI = 43, 2027 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 2028 [SI = 254, SFT = 42, RD = 192.0.2.2,11], 2029 [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0}, 2030 RD = {SPI=41, SI=255, Rsv=0}, 2031 RD = {SPI=42, SI=255, Rsv=0} } ] 2033 Now, despite the load balancing choice being made other than at the 2034 initial classifier, it is possible for the reverse SFPs to be well- 2035 constructed without any ambiguity. The three reverse paths appear as 2036 follows. 2038 SFP30: RD = 198.51.100.1,130, SPI = 44, 2039 Assoc-Type = 1, Assoc-RD = 198.51.100.1,126, Assoc-SPI = 40, 2040 [SI = 255, SFT = 44, RD = 192.0.2.4,11], 2041 [SI = 254, SFT = 43, RD = 192.0.2.5,11], 2042 [SI = 253, SFT = 42, RD = 192.0.2.2,11], 2043 [SI = 252, SFT = 41, RD = 192.0.2.1,11] 2045 SFP31: RD = 198.51.100.1,131, SPI = 45, 2046 Assoc-Type = 1, Assoc-RD = 198.51.100.1,127, Assoc-SPI = 41, 2047 [SI = 255, SFT = 44, RD = 192.0.2.4,11], 2048 [SI = 254, SFT = 43, RD = 192.0.2.6,11], 2049 [SI = 253, SFT = 42, RD = 192.0.2.2,11], 2050 [SI = 252, SFT = 41, RD = 192.0.2.1,11] 2052 SFP32: RD = 198.51.100.1,132, SPI = 46, 2053 Assoc-Type = 1, Assoc-RD = 198.51.100.1,128, Assoc-SPI = 42, 2054 [SI = 255, SFT = 44, RD = 192.0.2.4,11], 2055 [SI = 254, SFT = 43, RD = 192.0.2.7,11], 2056 [SI = 253, SFT = 42, RD = 192.0.2.2,11], 2057 [SI = 252, SFT = 41, RD = 192.0.2.1,11] 2059 9. Security Considerations 2061 This document inherits all the security considerations discussed in 2062 the documents that specify BGP, the documents that specify BGP 2063 Multiprotocol Extensions, and the documents that define the 2064 attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. For 2065 more information look in [RFC4271], [RFC4760], and 2066 [I-D.ietf-idr-tunnel-encaps]. 2068 Service Function Chaining provides a significant attack opportunity: 2069 packets can be diverted from their normal paths through the network, 2070 can be made to execute unexpected functions, and the functions that 2071 are instantiated in software can be subverted. However, this 2072 specification does not change the existence of Service Function 2073 Chaining and security issues specific to Service Function Chaining 2074 are covered in [RFC7665] and [I-D.ietf-sfc-nsh]. 2076 This document defines a control plane for Service Function Chaining. 2077 Clearly, this provides an attack vector for a Service Function 2078 Chaining system as an attack on this control plane could be used to 2079 make the system misbehave. Thus, the security of the BGP system is 2080 critically important to the security of the whole Service Function 2081 Chaining system. 2083 10. IANA Considerations 2085 10.1. New BGP AF/SAFI 2087 IANA maintains a registry of "Address Family Numbers". IANA is 2088 requested to assign a new Address Family Number from the "Standards 2089 Action" range called "BGP SFC" (TBD1 in this document) with this 2090 document as a reference. 2092 IANA maintains a registry of "Subsequent Address Family Identifiers 2093 (SAFI) Parameters". IANA is requested to assign a new SAFI value 2094 from the "Standards Action" range called "BGP SFC" (TBD2 in this 2095 document) with this document as a reference. 2097 10.2. New BGP Path Attribute 2099 IANA maintains a registry of "Border Gateway Protocol (BGP) 2100 Parameters" with a subregistry of "BGP Path Attributes". IANA is 2101 requested to assign a new Path attribute called "SFP attribute" (TBD3 2102 in this document) with this document as a reference. 2104 10.3. New SFP Attribute TLVs Type Registry 2106 IANA maintains a registry of "Border Gateway Protocol (BGP) 2107 Parameters". IANA is request to create a new subregistry called the 2108 "SFP Attribute TLVs" registry. 2110 Valid values are in the range 0 to 65535. 2112 o Values 0 and 65535 are to be marked "Reserved, not to be 2113 allocated". 2115 o Values 1 through 65524 are to be assigned according to the "First 2116 Come First Served" policy [RFC8126]. 2118 This document should be given as a reference for this registry. 2120 The new registry should track: 2122 o Type 2124 o Name 2126 o Reference Document or Contact 2128 o Registration Date 2130 The registry should initially be populated as follows: 2132 Type | Name | Reference | Date 2133 ------+-----------------------+---------------+--------------- 2134 1 | Association TLV | [This.I-D] | Date-to-be-set 2135 2 | Hop TLV | [This.I-D] | Date-to-be-set 2136 3 | SFT TLV | [This.I-D] | Date-to-be-set 2138 10.4. New SFP Association Type Registry 2140 IANA maintains a registry of "Border Gateway Protocol (BGP) 2141 Parameters". IANA is request to create a new subregistry called the 2142 "SFP Association Type" registry. 2144 Valid values are in the range 0 to 65535. 2146 o Values 0 and 65535 are to be marked "Reserved, not to be 2147 allocated". 2149 o Values 1 through 65524 are to be assigned according to the "First 2150 Come First Served" policy [RFC8126]. 2152 This document should be given as a reference for this registry. 2154 The new registry should track: 2156 o Association Type 2158 o Name 2160 o Reference Document or Contact 2162 o Registration Date 2164 The registry should initially be populated as follows: 2166 Association Type | Name | Reference | Date 2167 -----------------+--------------------+------------+--------------- 2168 1 | Bidirectional SFP | [This.I-D] | Date-to-be-set 2170 10.5. New Service Function Type Registry 2172 IANA is request to create a new top-level registry called "Service 2173 Function Chaining Service Function Types". 2175 Valid values are in the range 0 to 65535. 2177 o Values 0 and 65535 are to be marked "Reserved, not to be 2178 allocated". 2180 o Values 1 through 31 are to be assigned by "Standards Action" 2181 [RFC8126] and are referred to as the Special Purpose SFT values. 2183 o Other values (32 through 65534) are to be assigned according to 2184 the "First Come First Served" policy [RFC8126]. 2186 This document should be given as a reference for this registry. 2188 The new registry should track: 2190 o Value 2192 o Name 2194 o Reference Document or Contact 2196 o Registration Date 2198 The registry should initially be populated as follows: 2200 Value | Name | Reference | Date 2201 ------+-----------------------+---------------+--------------- 2202 1 | Change Sequence | [This.I-D] | Date-to-be-set 2204 10.6. New Generic Transitive Experimental Use Extended Community Sub- 2205 Type 2207 IANA maintains a registry of "Border Gateway Protocol (BGP) 2208 Parameters" with a subregistry of "Generic Transitive Experimental 2209 Use Extended Community Sub-Type". IANA is requested to assign a new 2210 sub-type called "Flow spec for SFC classifiers" (TBD4 in this 2211 document) with this document as the reference. 2213 10.7. SPI/SI Representation 2215 IANA is requested to assign a codepoint from the "BGP Tunnel 2216 Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI 2217 Representation Sub-TLV" (TBD5 in this document) with this document 2218 being the reference. 2220 11. Contributors 2222 Stuart Mackie 2223 Juniper Networks 2225 Email: wsmackie@juinper.net 2227 Keyur Patel 2228 Arrcus, Inc. 2230 Email: keyur@arrcus.com 2232 12. Acknowledgements 2234 Thanks to Tony Przygienda for helpful comments, and to Joel Halpern 2235 for discussions that improved this document. 2237 13. References 2239 13.1. Normative References 2241 [I-D.ietf-idr-tunnel-encaps] 2242 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 2243 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-07 2244 (work in progress), July 2017. 2246 [I-D.ietf-sfc-nsh] 2247 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 2248 Header (NSH)", draft-ietf-sfc-nsh-23 (work in progress), 2249 September 2017. 2251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2252 Requirement Levels", BCP 14, RFC 2119, 2253 DOI 10.17487/RFC2119, March 1997, 2254 . 2256 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 2257 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 2258 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 2259 . 2261 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2262 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2263 DOI 10.17487/RFC4271, January 2006, 2264 . 2266 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2267 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2268 2006, . 2270 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2271 "Multiprotocol Extensions for BGP-4", RFC 4760, 2272 DOI 10.17487/RFC4760, January 2007, 2273 . 2275 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 2276 and D. McPherson, "Dissemination of Flow Specification 2277 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 2278 . 2280 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2281 Writing an IANA Considerations Section in RFCs", BCP 26, 2282 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2283 . 2285 13.2. Informative References 2287 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 2288 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 2289 RFC 6790, DOI 10.17487/RFC6790, November 2012, 2290 . 2292 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 2293 Service Function Chaining", RFC 7498, 2294 DOI 10.17487/RFC7498, April 2015, 2295 . 2297 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 2298 "Encapsulating MPLS in UDP", RFC 7510, 2299 DOI 10.17487/RFC7510, April 2015, 2300 . 2302 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 2303 Chaining (SFC) Architecture", RFC 7665, 2304 DOI 10.17487/RFC7665, October 2015, 2305 . 2307 Authors' Addresses 2309 Adrian Farrel 2310 Juniper Networks 2312 Email: afarrel@juniper.net 2313 John Drake 2314 Juniper Networks 2316 Email: jdrake@juniper.net 2318 Eric Rosen 2319 Juniper Networks 2321 Email: erosen@juniper.net 2323 Jim Uttaro 2324 AT&T 2326 Email: ju1738@att.com 2328 Luay Jalil 2329 Verizon 2331 Email: luay.jalil@verizon.com