idnits 2.17.1 draft-ietf-bess-nsh-bgp-control-plane-04.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 (July 1, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-09 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-sfc-01 Summary: 1 error (**), 0 flaws (~~), 3 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: January 2, 2019 Juniper Networks 6 J. Uttaro 7 AT&T 8 L. Jalil 9 Verizon 10 July 1, 2018 12 BGP Control Plane for NSH SFC 13 draft-ietf-bess-nsh-bgp-control-plane-04 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 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 2, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5 70 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7 71 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10 73 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11 74 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12 75 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13 76 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13 77 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 19 78 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 20 79 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 20 80 4.2. Service Function Instance Routes . . . . . . . . . . . . 20 81 4.3. Service Function Path Routes . . . . . . . . . . . . . . 21 82 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 23 83 4.5. Service Function Forwarder Operation . . . . . . . . . . 23 84 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 24 85 5. Selection in Service Function Paths . . . . . . . . . . . . . 25 86 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 27 87 6.1. Protocol Control of Looping, Jumping, and Branching . . . 27 88 6.2. Implications for Forwarding State . . . . . . . . . . . . 28 89 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 29 90 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 29 91 7.2. Correlating Service Function Path Instances . . . . . . . 29 92 7.3. Considerations for Stateful Service Functions . . . . . . 30 93 7.4. VPN Considerations and Private Service Functions . . . . 31 94 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 31 95 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 33 96 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 34 97 7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 34 98 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 99 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 36 100 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 36 101 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 37 102 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 38 103 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 38 104 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 39 105 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 39 106 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 40 107 8.9. Examples of SFPs with Stateful Service Functions . . . . 41 108 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 41 109 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 42 110 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 43 111 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 45 112 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 113 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 114 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 49 115 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 49 116 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 49 117 10.4. New SFP Association Type Registry . . . . . . . . . . . 50 118 10.5. New Service Function Type Registry . . . . . . . . . . . 51 119 10.6. New Generic Transitive Experimental Use Extended 120 Community Sub-Types . . . . . . . . . . . . . . . . . . 51 121 10.7. New BGP Transitive Extended Community Types . . . . . . 52 122 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 52 123 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 124 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 126 13.1. Normative References . . . . . . . . . . . . . . . . . . 53 127 13.2. Informative References . . . . . . . . . . . . . . . . . 54 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 130 1. Introduction 132 As described in [RFC7498], the delivery of end-to-end services can 133 require a packet to pass through a series of Service Functions (SFs) 134 (e.g., classifiers, firewalls, TCP accelerators, and server load 135 balancers) in a specified order: this is termed "Service Function 136 Chaining" (SFC). There are a number of issues associated with 137 deploying and maintaining service function chaining in production 138 networks, which are described below. 140 Conventionally, if a packet needs to travel through a particular 141 service chain, the nodes hosting the service functions of that chain 142 are placed in the network topology in such a way that the packet 143 cannot reach its ultimate destination without first passing through 144 all the service functions in the proper order. This need to place 145 the service functions at particular topological locations limits the 146 ability to adapt a service function chain to changes in network 147 topology (e.g., link or node failures), network utilization, or 148 offered service load. These topological restrictions on where the 149 service functions can be placed raise the following issues: 151 1. The process of configuring or modifying a service function chain 152 is operationally complex and may require changes to the network 153 topology. 155 2. Alternate or redundant service functions may need to be co- 156 located with the primary service functions. 158 3. When there is more than one path between source and destination, 159 forwarding may be asymmetric and it may be difficult to support 160 bidirectional service function chains using simple routing 161 methodologies and protocols without adding mechanisms for traffic 162 steering or traffic engineering. 164 In order to address these issues, the SFC architecture describes 165 Service Function Chains that are built in their own overlay network 166 (the service function overlay network), coexisting with other overlay 167 networks, over a common underlay network [RFC7665]. A Service 168 Function Chain is a sequence of Service Functions through which 169 packet flows that satisfy specified criteria will pass. 171 This document describes the use of BGP as a control plane for 172 networks that support Service Function Chaining (SFC). The document 173 introduces a new BGP address family called the SFC AFI/SAFI with two 174 route types. One route type is originated by a node to advertise 175 that it hosts a particular instance of a specified service function. 176 This route type also provides "instructions" on how to send a packet 177 to the hosting node in a way that indicates that the service function 178 has to be applied to the packet. The other route type is used by a 179 Controller to advertise the paths of "chains" of service functions, 180 and to give a unique designator to each such path so that they can be 181 used in conjunction with the Network Service Header. 183 This document adopts the SFC architecture described in [RFC7665]. 185 1.1. Requirements Language 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in BCP 190 14 [RFC2119] [RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 1.2. Terminology 195 This document uses the following terms from [RFC7665]: 197 o Bidirectional Service Function Chain 199 o Classifier 201 o Service Function (SF) 203 o Service Function Chain (SFC) 205 o Service Function Forwarder (SFF) 207 o Service Function Instance (SFI) 209 o Service Function Path (SFP) 211 o SFC branching 213 Additionally, this document uses the following terms from [RFC8300]: 215 o Network Service Header (NSH) 217 o Service Index (SI) 219 o Service Path Identifier (SPI) 221 This document introduces the following terms: 223 o Service Function Instance Route (SFIR) 225 o Service Function Overlay Network 227 o Service Function Path Route (SFPR) 229 o Service Function Type (SFT) 231 2. Overview 233 2.1. Functional Overview 235 In [RFC8300] a Service Function Chain (SFC) is an ordered list of 236 Service Functions (SFs). A Service Function Path (SFP) is an 237 indication of which instances of SFs are acceptable to be traversed 238 in an instantiation of an SFC in a service function overlay network. 239 The Service Path Identifier (SPI) is a 24-bit number that identifies 240 a specific SFP, and a Service Index (SI) is an 8-bit number that 241 identifies a specific point in that path. In the context of a 242 particular SFP (identified by an SPI), an SI represents a particular 243 Service Function, and indicates the order of that SF in the SFP. 245 In fact, each SI is mapped to one or more SFs that are implemented by 246 one or more Service Function Instances (SFIs) that support those 247 specified SFs. Thus an SI may represent a choice of SFIs of one or 248 more Service Function Types. By deploying multiple SFIs for a single 249 SF, one can provide load balancing and redundancy. 251 A special Service Function, called a Classifier, is located at each 252 ingress point to a service function overlay network. It assigns the 253 packets of a given packet flow to a specific Service Function Path. 254 This may be done by comparing specific fields in a packet's header 255 with local policy, which may be customer/network/service specific. 256 The classifier picks an SFP and sets the SPI accordingly, it then 257 sets the SI to the value of the SI for the first hop in the SFP, and 258 then prepends a Network Services Header (NSH) [RFC8300] containing 259 the assigned SPI/SI to that packet. Note that the Classifier and the 260 node that hosts the first Service Function in a Service Function Path 261 need not be located at the same point in the service function overlay 262 network. 264 Note that the presence of the NSH can make it difficult for nodes in 265 the underlay network to locate the fields in the original packet that 266 would normally be used to constrain equal cost multipath (ECMP) 267 forwarding. Therefore, it is recommended, as described in 268 Section 7.1, that the node prepending the NSH also provide some form 269 of entropy indicator that can be used in the underlay network. 271 The Service Function Forwarder (SFF) receives a packet from the 272 previous node in a Service Function Path, removes the packet's link 273 layer or tunnel encapsulation and hands the packet and the NSH to the 274 Service Function Instance for processing. The SFI has no knowledge 275 of the SFP. 277 When the SFF receives the packet and the NSH back from the SFI it 278 must select the next SFI along the path using the SPI and SI in the 279 NSH and potentially choosing between multiple SFIs (possibly of 280 different Service Function Types) as described in Section 5. In the 281 normal case the SPI remains unchanged and the SI will have been 282 decremented to indicate the next SF along the path. But other 283 possibilities exist if the SF makes other changes to the NSH through 284 a process of re-classification: 286 o The SI in the NSH may indicate: 288 * A previous SF in the path: known as "looping" (see Section 6). 290 * An SF further down the path: known as "jumping" (see also 291 Section 6). 293 o The SPI and the SI may point to an SF on a different SFP: known as 294 "branching" (see also Section 6). 296 Such modifications are limited to within the same service function 297 overlay network. That is, an SPI is known within the scope of 298 service function overlay network. Furthermore, the new SI value is 299 interpreted in the context of the SFP identified by the SPI. 301 An unknown or invalid SPI SHALL be treated as an error and the SFF 302 MUST drop the packet. Such errors SHOULD be logged, and such logs 303 MUST be subject to rate limits. 305 An SFF receiving an SI that is unknown in the context of the SPI MAY 306 reduce the value to the next meaningful SI value in the SFP indicated 307 by the SPI. If no such value exists or if the SFF does not support 308 this function it MUST drop the packet and SHOULD log the event: such 309 logs MUST be subject to rate limits. 311 The SFF then selects an SFI that provides the SF denoted by the SPI/ 312 SI, and forwards the packet to the SFF that supports that SFI. 314 2.2. Control Plane Overview 316 To accomplish the function described in Section 2.1, this document 317 introduces a new BGP AFI/SAFI (values to be assigned by IANA) for 318 "SFC Routes". Two SFC Route Types are defined by this document: the 319 Service Function Instance Route (SFIR), and the Service Function Path 320 Route (SFPR). As detailed in Section 3, the route type is indicated 321 by a sub-field in the NLRI. 323 o The SFIR is advertised by the node hosting the service function 324 instance. The SFIR describes a particular instance of a 325 particular Service Function and the way to forward a packet to it 326 through the underlay network, i.e., IP address and encapsulation 327 information. 329 o The SFPRs are originated by Controllers. One SFPR is originated 330 for each Service Function Path. The SFPR specifies: 332 A. the SPI of the path 334 B. the sequence of SFTs and/or SFIs of which the path consists 336 C. for each such SFT or SFI, the SI that represents it in the 337 identified path. 339 This approach assumes that there is an underlay network that provides 340 connectivity between SFFs and Controllers, and that the SFFs are 341 grouped to form one or more service function overlay networks through 342 which SFPs are built. We assume BGP connectivity between the 343 Controllers and all SFFs within each service function overlay 344 network. 346 In addition, we also introduce the Service Function Type (SFT) that 347 is the category of SF that is supported by an SFF (such as 348 "firewall"). An IANA registry of Service Function Types is 349 introduced in Section 10. An SFF may support SFs of multiple 350 different SFTs, and may support multiple SFIs of each SF. 352 When choosing the next SFI in a path, the SFF uses the SPI and SI as 353 well as the SFT to choose among the SFIs, applying, for example, a 354 load balancing algorithm or direct knowledge of the underlay network 355 topology as described in Section 4. 357 The SFF then encapsulates the packet using the encapsulation 358 specified by the SFIR of the selected SFI and forwards the packet. 359 See Figure 1. 361 Thus the SFF can be seen as a portal in the underlay network through 362 which a particular SFI is reached. 364 Packets 365 | | | 366 | | | 367 | | | 368 ------------ 369 | | 370 | Classifier | 371 | | 372 ------------ 373 | 374 | 375 ------- ------- 376 | | Tunnel | | 377 | SFF |=============| SFF |=========== ......... 378 | | | | # : SFT : 379 | | -+---+- # : ----- : 380 | | / \ # : | SFI | : 381 | | ....../.......\...... # : --+-- : 382 | | : / \ : # ....|.... 383 | | : -+--- ---+- : # | 384 | | : | SFI | | SFI | : # ---+--- 385 | | : ----- ----- : ====| |--- 386 | | : : | SFF |--- Dests 387 | | : ----- : ====| |--- 388 | | : | SFI | : # ------- 389 | | : --+-- : # 390 | | : SFT | : # 391 | | ..........|.......... # 392 | | | # 393 | | | # 394 | | ---+--- # 395 | | | | # 396 | |=============| SFF |=========== 397 ------- | | 398 ------- 400 Figure 1: The SFC Architecture Reference Model 402 3. BGP SFC Routes 404 This document defines a new AFI/SAFI for BGP, known as "SFC", with an 405 NLRI that is described in this section. 407 The format of the SFC NLRI is shown in Figure 2. 409 +---------------------------------------+ 410 | Route Type (2 octets) | 411 +---------------------------------------+ 412 | Length (2 octets) | 413 +---------------------------------------+ 414 | Route Type specific (variable) | 415 +---------------------------------------+ 417 Figure 2: The Format of the SFC NLRI 419 The Route Type field determines the encoding of the rest of the route 420 type specific SFC NLRI. 422 The Length field indicates the length in octets of the route type 423 specific field of the SFC NLRI. 425 This document defines the following Route Types: 427 1. Service Function Instance Route (SFIR) 429 2. Service Function Path Route (SFPR) 431 A Service Function Instance Route (SFIR) is used to identify an SFI. 432 A Service Function Path Route (SFPR) defines a sequence of Service 433 Functions (each of which has at least one instance advertised in an 434 SFIR) that form an SFP. 436 The detailed encoding and procedures for these Route Types are 437 described in subsequent sections. 439 The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol 440 Extensions [RFC4760] with an Address Family Identifier (AFI) of TBD1 441 and a Subsequent Address Family Identifier (SAFI) of TBD2. The NLRI 442 field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC 443 NLRI, encoded as specified above. 445 In order for two BGP speakers to exchange SFC NLRIs, they must use 446 BGP Capabilities Advertisements to ensure that they both are capable 447 of properly processing such NLRIs. This is done as specified in 448 [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI 449 of TBD1 and a SAFI of TBD2. 451 3.1. Service Function Instance Route (SFIR) 453 Figure 3 shows the Route Type specific NLRI of the SFIR. 455 +--------------------------------------------+ 456 | Route Distinguisher (RD) (8 octets) | 457 +--------------------------------------------+ 458 | Service Function Type (2 octets) | 459 +--------------------------------------------+ 461 Figure 3: SFIR Route Type specific NLRI 463 Per [RFC4364] the RD field comprises a two byte Type field and a six 464 byte Value field. Two SFIs of the same SFT must be associated with 465 different RDs, where the association of an SFI with an RD is 466 determined by provisioning. If two SFIRs are originated from 467 different administrative domains, they must have different RDs. In 468 particular, SFIRs from different VPNs (for different service function 469 overlay networks) must have different RDs, and those RDs must be 470 different from any non-VPN SFIRs. 472 The Service Function Type identifies a service function, e.g., 473 classifier, firewall, load balancer, etc. There may be several SFIs 474 that can perform a given Service Function. Each node hosting an SFI 475 must originate an SFIR for each SFI that it hosts. The SFIR 476 representing a given SFI will contain an NLRI with RD field set to an 477 RD as specified above, and with SFT field set to identify that SFI's 478 Service Function Type. The values for the SFT field are taken from a 479 registry administered by IANA (see Section 10). A BGP Update 480 containing one or more SFIRs will also include a Tunnel Encapsulation 481 attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be 482 sent to an SFI identified in one of the SFIRs, it will be 483 encapsulated as specified by the Tunnel Encapsulation attribute, and 484 then transmitted through the underlay network. 486 3.1.1. SFI Pool Identifier Extended Community 488 This document defines a new transitive extended community with Sub- 489 Type TBD6 called the SFI Pool Identifier extended community. It can 490 be included in SFIR advertisements, and is used to indicate the 491 identity of a pool of SFIRs to which an SFIR belongs. Since an SFIR 492 may be a member of multiple pools, multiple of these extended 493 communities may be present on a single SFIR advertisement. 495 SFIR pools allow SFIRs to be grouped for any purpose. Possible uses 496 include control plane scalability and stability. 498 The SFI Pool Identifier extended community is encoded in 8 octets as 499 shown in Figure 4. 501 +--------------------------------------------+ 502 | Type = 0x80 (1 octet) | 503 +--------------------------------------------+ 504 | Sub-Type = TBD6 (1 octet) | 505 +--------------------------------------------+ 506 | SFI Pool Identifier (6 octets) | 507 +--------------------------------------------+ 509 Figure 4: The SFI Pool Identifier Extended Community 511 The SFI Pool Identifier is encoded in a 6 octet field in network 512 byte order and is a globally unique value. 514 3.1.2. MPLS Mixed Swapping/Stacking Extended Community 516 This document defines a new transitive extended community with Sub- 517 Type TBD7 called the MPLS Mixed Swapping/Stacking Labels. The 518 community is encoded as shown in Figure 5. It contains a pair of 519 MPLS labels: an SFC Context Label and an SF Label as described in 520 [I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a 3-octet (24 521 bit) field with 4 trailing bits that MUST be set to zero. 523 +--------------------------------------------+ 524 | Type = 0x80 (1 octet) | 525 +--------------------------------------------| 526 | Sub-Type = TBD7 (1 octet) | 527 +--------------------------------------------| 528 | SFC Context Label (3 octets) | 529 +--------------------------------------------| 530 | SF Label (3 octets) | 531 +--------------------------------------------+ 533 Figure 5: The MPLS Mixed Swapping/Stacking Labels 535 Note that it is assumed that each SFF has one or more globally unique 536 SFC Context Labels and that the context label space and the SPI 537 address space are disjoint. 539 See Section 7.7 for a description of how this extended community is 540 used. 542 3.2. Service Function Path Route (SFPR) 544 Figure 6 shows the Route Type specific NLRI of the SFPR. 546 +-----------------------------------------------+ 547 | Route Distinguisher (RD) (8 octets) | 548 +-----------------------------------------------+ 549 | Service Path Identifier (SPI) (3 octets) | 550 +-----------------------------------------------+ 552 Figure 6: SFPR Route Type Specific NLRI 554 Per [RFC4364] the RD field comprises a two byte Type field and a six 555 byte Value field. All SFPs must be associated with different RDs. 556 The association of an SFP with an RD is determined by provisioning. 557 If two SFPRs are originated from different Controllers they must have 558 different RDs. Additionally, SFPRs from different VPNs (i.e., in 559 different service function overlay networks) must have different RDs, 560 and those RDs must be different from any non-VPN SFPRs. 562 The Service Path Identifier is defined in [RFC8300] and is the value 563 to be placed in the Service Path Identifier field of the NSH header 564 of any packet sent on this Service Function Path. It is expected 565 that one or more Controllers will originate these routes in order to 566 configure a service function overlay network. 568 The SFP is described in a new BGP Path attribute, the SFP attribute. 569 Section 3.2.1 shows the format of that attribute. 571 3.2.1. The SFP Attribute 573 [RFC4271] defines the BGP Path attribute. This document introduces a 574 new Path attribute called the SFP attribute with value TBD3 to be 575 assigned by IANA. The first SFP attribute MUST be processed and 576 subsequent instances MUST be ignored. 578 The common fields of the SFP attribute are set as follows: 580 o Optional bit is set to 1 to indicate that this is an optional 581 attribute. 583 o The Transitive bit is set to 1 to indicate that this is a 584 transitive attribute. 586 o The Extended Length bit is set according to the length of the SFP 587 attribute as defined in [RFC4271]. 589 o The Attribute Type Code is set to TBD3. 591 The content of the SFP attribute is a series of Type-Length-Variable 592 (TLV) constructs. Each TLV may include sub-TLVs. All TLVs and sub- 593 TLVs have a common format that is: 595 o Type: A single octet indicating the type of the SFP attribute TLV. 596 Values are taken from the registry described in Section 10.3. 598 o Length: A two octet field indicating the length of the data 599 following the Length field counted in octets. 601 o Value: The contents of the TLV. 603 The formats of the TLVs defined in this document are shown in the 604 following sections. The presence rules and meanings are as follows. 606 o The SFP attribute contains a sequence of zero or more Association 607 TLVs. That is, the Association TLV is optional. Each Association 608 TLV provides an association between this SFPR and another SFPR. 609 Each associated SFPR is indicated using the RD with which it is 610 advertised (we say the SFPR-RD to avoid ambiguity). 612 o The SFP attribute contains a sequence of one or more Hop TLVs. 613 Each Hop TLV contains all of the information about a single hop in 614 the SFP. 616 o Each Hop TLV contains an SI value and a sequence of one or more 617 SFT TLVs. Each SFT TLV contains an SFI reference for each 618 instance of an SF that is allowed at this hop of the SFP for the 619 specific SFT. Each SFI is indicated using the RD with which it is 620 advertised (we say the SFIR-RD to avoid ambiguity). 622 3.2.1.1. The Association TLV 624 The Association TLV is an optional TLV in the SFP attribute. It may 625 be present multiple times. Each occurrence provides an association 626 with another SFP as advertised in another SFPR. The format of the 627 Association TLV is shown in Figure 7 628 +--------------------------------------------+ 629 | Type = 1 (1 octet) | 630 +--------------------------------------------| 631 | Length (2 octets) | 632 +--------------------------------------------| 633 | Association Type (1 octet) | 634 +--------------------------------------------| 635 | Associated SFPR-RD (8 octets) | 636 +--------------------------------------------| 637 | Associated SPI (3 octets) | 638 +--------------------------------------------+ 640 Figure 7: The Format of the Association TLV 642 The fields are as follows: 644 Type is set to 1 to indicate an Association TLV. 646 Length indicates the length in octets of the Association Type and 647 Associated SFPR-RD fields. The value of the Length field is 12. 649 The Association Type field indicate the type of association. The 650 values are tracked in an IANA registry (see Section 10.4). Only 651 one value is defined in this document: type 1 indicates 652 association of two unidirectional SFPs to form a bidirectional 653 SFP. An SFP attribute SHOULD NOT contain more than one 654 Association TLV with Association Type 1: if more than one is 655 present, the first one MUST be processed and subsequent instances 656 MUST be ignored. Note that documents that define new Association 657 Types must also define the presence rules for Association TLVs of 658 the new type. 660 The Associated SFPR-RD contains the RD of some other SFPR 661 advertisement that contains the SFP with which this SFP is 662 associated. 664 The Associated SPI contains the SPI of the associated SFP as 665 advertised in the SFPR indicated by the Associated SFPR-RD field. 667 Association TLVs with unknown Association Type values SHOULD be 668 ignored. Association TLVs that contain an Associated SFPR-RD value 669 equal to the RD of the SFPR in which they are contained SHOULD be 670 ignored. If the Associated SPI is not equal to the SPI advertised in 671 the SFPR indicated by the Associated SFPR-RD then the Association TLV 672 SHOULD be ignored. 674 Note that when two SFPRs reference each other using the Association 675 TLV, one SFPR advertisement will be received before the other. 676 Therefore, processing of an association MUST NOT be rejected simply 677 because the Associated SFPR-RD is unknown. 679 Further discussion of correlation of SFPRs is provided in 680 Section 7.2. 682 3.2.1.2. The Hop TLV 684 There is one Hop TLV in the SFP attribute for each hop in the SFP. 685 The format of the Hop TLV is shown in Figure 8. At least one Hop TLV 686 must be present in an SFP attribute. 688 +--------------------------------------------+ 689 | Type = 2 (1 octet) | 690 +--------------------------------------------| 691 | Length (2 octets) | 692 +--------------------------------------------| 693 | Service Index (1 octet) | 694 +--------------------------------------------| 695 | Hop Details (variable) | 696 +--------------------------------------------+ 698 Figure 8: The Format of the Hop TLV 700 The fields are as follows: 702 Type is set to 2 to indicate a Hop TLV. 704 Length indicates the length in octets of the Service Index and Hop 705 Details fields. 707 The Service Index is defined in [RFC8300] and is the value found 708 in the Service Index field of the NSH header that an SFF will use 709 to lookup to which next SFI a packet should be sent. 711 The Hop Details field consists of a sequence of one or more sub- 712 TLVs. These may be SFT-SFI TLVs and SFT-Pool TLVs. 714 Each hop of the SFP may demand that a specific type of SF is 715 executed, and that type is indicated in sub-TLVs of the Hop TLV. At 716 least one sub-TLV MUST be present, and the list of sub-TLVs may 717 include SFT-SFI and SFT-Pool TLVs as described in the following 718 sections. This provides a list of which types of SF are acceptable 719 at a specific hop, and for each type it allow a degree of control to 720 be imposed on the choice of SFIs of that particular type. 722 3.2.1.3. The SFT-SFI TLV 724 The SFT-SFI TLV MAY be included in the list of sub-TLVs of the Hop 725 TLV. The format of the SFT-SFI TLV is shown in Figure 9. The TLV 726 contains a list of SFIR-RD values each taken from the advertisement 727 of an SFI. Together they form a list of acceptable SFIs of the 728 indicated type. 730 +--------------------------------------------+ 731 | Type = 3 (1 octet) | 732 +--------------------------------------------| 733 | Length (2 octets) | 734 +--------------------------------------------| 735 | Service Function Type (2 octets) | 736 +--------------------------------------------| 737 | SFIR-RD List (variable) | 738 +--------------------------------------------+ 740 Figure 9: The Format of the SFT-SFI TLV 742 The fields are as follows: 744 Type is set to 3 to indicate an SFT TLV. 746 Length indicates the length in octets of the Service Function Type 747 and SFIR-RD List fields. 749 The Service Function Type value indicates the category (type) of 750 SF that is to be executed at this hop. The types are as 751 advertised for the SFs supported by the SFFs SFT values in the 752 range 1-31 are Special Purpose SFT values and have meanings 753 defined by the documents that describe them - the value 'Change 754 Sequence' is defined in Section 6.1 of this document. 756 The hop description is further qualified beyond the specification 757 of the SFTs by listing, for each SFT in each hop, the SFIs that 758 may be used at the hop. The SFIs are identified using the SFIR- 759 RDs from the advertisements of the SFIs in the SFIRs. An SFIR-RD 760 of value zero has special meaning as described in Section 5. Each 761 entry in the list is 8 octets long, and the number of entries in 762 the list can be deduced from the value of the Length field. 764 3.2.1.4. The SFT-Pool TLV 766 The SFT-Pool TLV MAY be included in the list of sub-TLVs of the Hop 767 TLV. The format of the SFT-Pool TLV is shown in Figure 10. The TLV 768 contains a list of SFI Pool Identifier values each taken from the 769 advertisement of an SFI. Together they form a list of pools of 770 acceptable SFIs of the indicated type. 772 +--------------------------------------------+ 773 | Type = 4 (1 octet) | 774 +--------------------------------------------| 775 | Length (2 octets) | 776 +--------------------------------------------| 777 | Service Function Type (2 octets) | 778 +--------------------------------------------| 779 | SFI Pool List (variable) | 780 +--------------------------------------------+ 782 Figure 10: The Format of the SFT TLV 784 The fields are as follows: 786 Type is set to 4 to indicate an SFT TLV. 788 Length indicates the length in octets of the Service Function Type 789 and SFIR-RD List fields. 791 The Service Function Type value indicates the category (type) of 792 SF that is to be executed at this hop. The types are as 793 advertised for the SFs supported by the SFFs SFT values in the 794 range 1-31 are Special Purpose SFT values and have meanings 795 defined by the documents that describe them - the value 'Change 796 Sequence' is defined in Section 6.1 of this document. 798 The hop description is further qualified beyond the specification 799 of the SFTs by listing, for each SFT in each hop, the SFI Pool 800 Identifiers that may be used at the hop. The SFI pools are 801 identified using SFI Pool Identifiers from the advertisements of 802 the SFIs in the SFIRs. Each entry in the list is 6 octets long, 803 and the number of entries in the list can be deduced from the 804 value of the Length field. 806 3.2.1.5. MPLS Swapping/Stacking TLV 808 The MPLS Swapping/Stacking TLV (Type value 5) is a zero length sub- 809 TLV that can be carried in the Hop TLV and is used when the data 810 representation is MPLS (see Section 7.6). It indicates to the 811 Classifier that imposes an MPLS label stack whether the current hop 812 is to use an {SPI, SI} label pair for label swapping or a {Context 813 label, SF label}. See Section 7.7 for more details. 815 3.2.1.6. SFP Traversal With MPLS Label Stack TLV 817 The SFP Traversal With MPLS Label Stack TLV (Type value 6) is a zero 818 length sub-TLV that can be carried in the SFP Attribute and indicates 819 to the Classifier and the SFFs on the SFP that an MPLS labels stack 820 with label swapping/stacking is to be used for packets traversing the 821 SFP. All of the SFF specified at each the SFP's hops must have 822 advertised an SPI/SI Representation sub-TLV (see Section 7.6) with 823 bit 0 set to 0 and bit 1 set to 1 for the SFP to be considered 824 usable. 826 3.2.2. General Rules For The SFP Attribute 828 It is possible for the same SFI, as described by an SFIR, to be used 829 in multiple SFPRs. 831 When two SFPRs have the same SPI but different SFPR-RDs there can be 832 three cases: 834 o Two or more Controllers are originating SFPRs for the same SFP. 835 In this case the content of the SFPRs is identical and the 836 duplication is to ensure receipt and to provide Controller 837 redundancy. 839 o There is a transition in content of the advertised SFP and the 840 advertisements may originate from one or more Controllers. In 841 this case the content of the SFPRs will be different. 843 o The reuse of an SPI may result from a configuration error. 845 In all cases, there is no way for the receiving SFF to know which 846 SFPR to process, and the SFPRs could be received in any order. At 847 any point in time, when multiple SFPRs have the same SPI but 848 different SFPR-RDs, the SFF MUST use the SFPR with the numerically 849 lowest SFPR-RD. The SFF SHOULD log this occurrence to assist with 850 debugging. 852 Furthermore, a Controller that wants to change the content of an SFP 853 is RECOMMENDED to use a new SPI and so create a new SFP onto which 854 the Classifiers can transition packet flows before the SFPR for the 855 old SFP is withdrawn. This avoids any race conditions with SFPR 856 advertisements. 858 Additionally, a Controller SHOULD NOT re-use an SPI after it has 859 withdrawn the SFPR that used it until at least a configurable amount 860 of time has passed. This timer SHOULD have a default of one hour. 862 4. Mode of Operation 864 This document describes the use of BGP as a control plane to create 865 and manage a service function overlay network. 867 4.1. Route Targets 869 The main feature introduced by this document is the ability to create 870 multiple service function overlay networks through the use of Route 871 Targets (RTs) [RFC4364]. 873 Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. 874 The RT carried by a particular SFIR or SFPR is determined by the 875 provisioning of the route's originator. 877 Every node in a service function overlay network is configured with 878 one or more import RTs. Thus, each SFF will import only the SFPRs 879 with matching RTs allowing the construction of multiple service 880 function overlay networks or the instantiation of Service Function 881 Chains within an L3VPN or EVPN instance (see Section 7.4). An SFF 882 that has a presence in multiple service function overlay networks 883 (i.e., imports more than one RT) may find it helpful to maintain 884 separate forwarding state for each overlay network. 886 4.2. Service Function Instance Routes 888 The SFIR (see Section 3.1) is used to advertise the existence and 889 location of a specific Service Function Instance and consists of: 891 o The RT as just described. 893 o A Service Function Type (SFT) that is the category of Service 894 Function that is provided (such as "firewall"). 896 o A Route Distinguisher (RD) that is unique to a specific instance 897 of a service function. 899 4.3. Service Function Path Routes 901 The SFPR (see Section 3.2) describes a specific path of a Service 902 Function Chain. The SFPR contains the Service Path Identifier (SPI) 903 used to identify the SFP in the NSH in the data plane. It also 904 contains a sequence of Service Indexes (SIs). Each SI identifies a 905 hop in the SFP, and each hop is a choice between one of more SFIs. 907 As described in this document, each Service Function Path Route is 908 identified in the service function overlay network by an RD and an 909 SPI. The SPI is unique within a single VPN instance supported by the 910 underlay network. 912 The SFPR advertisement comprises: 914 o An RT as described in Section 4.1. 916 o A tuple that identifies the SFPR 918 * An RD that identifies an advertisement of an SFPR. 920 * The SPI that uniquely identifies this path within the VPN 921 instance distinguished by the RD. This SPI also appears in the 922 NSH. 924 o A series of Service Indexes. Each SI is used in the context of a 925 particular SPI and identifies one or more SFs (distinguished by 926 their SFTs) and for each SF a set of SFIs that instantiate the SF. 927 The values of the SI indicate the order in which the SFs are to be 928 executed in the SFP that is represented by the SPI. 930 o The SI is used in the NSH to identify the entries in the SFP. 931 Note that the SI values have meaning only relative to a specific 932 path. They have no semantic other than to indicate the order of 933 Service Functions within the path and are assumed to be 934 monotonically decreasing from the start to the end of the path 935 [RFC8300]. 937 o Each Service Index is associated with a set of one or more Service 938 Function Instances that can be used to provide the indexed Service 939 Function within the path. Each member of the set comprises: 941 * The RD used in an SFIR advertisement of the SFI. 943 * The SFT that indicates the type of function as used in the same 944 SFIR advertisement of the SFI. 946 This may be summarized as follows where the notations "SFPR-RD" and 947 "SFIR-RD" are used to distinguish the two different RDs: 949 RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } } 951 Where: 953 RT: Route Target 955 SFPR-RD: The Route Descriptor of the Service Function Path Route 956 advertisement 958 SPI: Service Path Identifier used in the NSH 960 m: The number of hops in the Service Function Path 962 n: The number of choices of Service Function Type for a specific 963 hop 965 p: The number of choices of Service Function Instance for given 966 Service Function Type in a specific hop 968 SI: Service Index used in the NSH to indicate a specific hop 970 SFT: The Service Function Type used in the same advertisement of 971 the Service Function Instance Route 973 SFIR-RD: The Route Descriptor used in an advertisement of the 974 Service Function Instance Route 976 Note that the values of SI are from the set {255, ..., 1} and are 977 monotonically decreasing within the SFP. SIs MUST appear in order 978 within the SFPR (i.e., monotonically decreasing) and MUST NOT appear 979 more than once. Gaps MAY appear in the sequence as described in 980 Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any 981 previous instance of the SFPR (same SFPR-RD and SPI) to be discarded. 983 Note that if the SFIR-RD list in an SFT TLV contains one or more SFI 984 Pool identifiers, then in the above expression, 'p' is the sum of the 985 number of individual SFIR-RD values and the sum for each SFI Pool 986 Identifier of the number of SFIRs advertised with that SFI Pool 987 Identifier. I.e., the list of SFIR-RD values is effectively expanded 988 to include the SFIR-RD of each SFIR advertised with each SFI Pool 989 Identifier in the SFIR-RD list. 991 The choice of SFI is explained further in Section 5. Note that an 992 SFIR-RD value of zero has special meaning as described in that 993 Section. 995 4.4. Classifier Operation 997 As shown in Figure 1, the Classifier is a special Service Function 998 that is used to assign packets to an SFP. 1000 The Classifier is responsible for determining to which packet flow a 1001 packet belongs (usually by inspecting the packet header), imposing an 1002 NSH, and initializing the NSH to include the SPI of the selected SFPR 1003 and to include the SI from first hop of the selected SFP. 1005 The Classifier may also provide an entropy indicator as described in 1006 Section 7.1. 1008 4.5. Service Function Forwarder Operation 1010 Each packet sent to an SFF is transmitted encapsulated in an NSH. 1011 The NSH includes an SPI and SI: the SPI indicates the SFPR 1012 advertisement that announced the Service Function Path; the tuple 1013 SPI/SI indicates a specific hop in a specific path and maps to the 1014 RD/SFT of a particular SFIR advertisement. 1016 When an SFF gets an SFPR advertisement it will first determine 1017 whether to import the route by examining the RT. If the SFPR is 1018 imported the SFF then determines whether it is on the SFP by looking 1019 for its own SFIR-RDs in the SFPR. For each occurrence in the SFP, 1020 the SFF creates forwarding state for incoming packets and forwarding 1021 state for outgoing packets that have been processed by the specified 1022 SFI. 1024 The SFF creates local forwarding state for packets that it receives 1025 from other SFFs. This state makes the association between the SPI/SI 1026 in the NSH of the received packet and one or more specific local SFIs 1027 as identified by the SFIR-RD/SFT. If there are multiple local SFIs 1028 that match this is because a single advertisement was made for a set 1029 of equivalent SFIs and the SFF may use local policy (such as load 1030 balancing) to determine to which SFI to forward a received packet. 1032 The SFF also creates next hop forwarding state for packets received 1033 back from the local SFI that need to be forwarded to the next hop in 1034 the SFP. There may be a choice of next hops as described in 1035 Section 4.3. The SFF could install forwarding state for all 1036 potential next hops, or it could choose to only install forwarding 1037 state to a subset of the potential next hops. If a choice is made 1038 then it will be as described in Section 5. 1040 The installed forwarding state may change over time reacting to 1041 changes in the underlay network and the availability of particular 1042 SFIs. 1044 Note that SFFs only create and store forwarding state for the SFPs on 1045 which they are included. They do not retain state for all SFPs 1046 advertised. 1048 An SFF may also install forwarding state to support looping, jumping, 1049 and branching. The protocol mechanism for explicit control of 1050 looping, jumping, and branching is described in Section 6.1 using a 1051 special value of the SFT within an entry in an SFPR. 1053 4.5.1. Processing With 'Gaps' in the SI Sequence 1055 The behavior of an SF as described in [RFC8300] is to decrement the 1056 value of the SI field in the NSH by one before returning a packet to 1057 the local SFF for further processing. This means that there is a 1058 good reason to assume that the SFP is composed of a series of SFs 1059 each indicated by an SI value one less than the previous. 1061 However, there is an advantage to having non-successive SIs in an 1062 SPI. Consider the case where an SPI needs to be modified by the 1063 insertion or removal of an SF. In the latter case this would lead to 1064 a "gap" in the sequence of SIs, and in the former case, this could 1065 only be achieved if a gap already existed into which the new SF with 1066 its new SI value could be inserted. Otherwise, all "downstream" SFs 1067 would need to be renumbered. 1069 Now, of course, such renumbering could be performed, but would lead 1070 to a significant disruption to the SFC as all the SFFs along the SFP 1071 were "reprogrammed". Thus, to achieve dynamic modification of an SFP 1072 (and even, in-service modification) it is desirable to be able to 1073 make these modifications without changing the SIs of the elements 1074 that were present before the modification. This will produce much 1075 more consistent/predictable behavior during the convergence period 1076 where otherwise the change would need to be fully propagated. 1078 Another approach says that any change to an SFP simply creates a new 1079 SFP that can be assigned a new SPI. All that would be needed would 1080 be to give a new instruction to the Classifier and traffic would be 1081 switched to the new SFP that contains the new set of SFs. This 1082 approach is practical, but neglects to consider that the SFP may be 1083 referenced by other SFPs (through "branch" instructions) and used by 1084 many Classifiers. In those cases the corresponding configuration 1085 resulting from a change in SPI may have wide ripples and give scope 1086 for errors that are hard to trace. 1088 Therefore, while this document requires that the SI values in an SFP 1089 are monotonic decreasing, it makes no assumption that the SI values 1090 are sequential. Configuration tools may apply that rule, but they 1091 are not required to. To support this, an SFF SHOULD process as 1092 follows when it receives a packet: 1094 o If the SI indicates a known entry in the SFP, the SFF MUST process 1095 the packet as normal, looking up the SI and determining whether to 1096 deliver the packet to a local SFI or to forward it to another SFF. 1098 o If the SI does not match an entry in the SFP, the SFF MUST reduce 1099 the SI value to the next (smaller) value present in the SFP and 1100 process the packet using that SI. 1102 o If there is no smaller SI (i.e., if the end of the SFP has been 1103 reached) the SFF MUST treat the SI value as invalid as described 1104 in [RFC8300]. 1106 SFF implementations MAY choose to only support contiguous SI values 1107 in an SFP. Such an implementation will not support receiving an SI 1108 value that is not present in the SFP and will discard the packets as 1109 described in [RFC8300]. 1111 5. Selection in Service Function Paths 1113 As described in Section 2 the SPI/SI in the NSH passed back from an 1114 SFI to the SFF may leave the SFF with a choice of next hop SFTs, and 1115 a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, 1116 and the SI indicates an entry in that SFPR. Each entry in an SFPR is 1117 a set of one or more SFT/SFIR-RD pairs. The SFF must choose one of 1118 these, identify the SFF that supports the chosen SFI, and send the 1119 packet to that next hop SFF. 1121 The choice may offered for load balancing across multiple SFIs, or 1122 for discrimination between different actions necessary at a specific 1123 hop in the SFP. Different SFT values may exist at a given hop in an 1124 SFP to support several cases: 1126 o There may be multiple instances of similar service functions that 1127 are distinguished by different SFT values. For example, firewalls 1128 made by vendor A and vendor B may need to be identified by 1129 different SFT values because, while they have similar 1130 functionality, their behavior is not identical. Then, some SFPs 1131 may limit the choice of SF at a given hop by specifying the SFT 1132 for vendor A, but other SFPs might not need to control which 1133 vendor's SF is used and so can indicate that either SFT can be 1134 used. 1136 o There may be an obvious branch needed in an SFP such as the 1137 processing after a firewall where admitted packets continue along 1138 the SFP, but suspect packets are diverted to a "penalty box". In 1139 this case, the next hop in the SFP will be indicated with two 1140 different SFT values. 1142 In the typical case, the SFF chooses a next hop SFF by looking at the 1143 set of all SFFs that support the SFs identified by the SI (that set 1144 having been advertised in individual SFIR advertisements), finding 1145 the one or more that are "nearest" in the underlay network, and 1146 choosing between next hop SFFs using its own load-balancing 1147 algorithm. 1149 An SFI may influence this choice process by passing additional 1150 information back along with the packet and NSH. This information may 1151 influence local policy at the SFF to cause it to favor a next hop SFF 1152 (perhaps selecting one that is not nearest in the underlay), or to 1153 influence the load-balancing algorithm. 1155 This selection applies to the normal case, but also applies in the 1156 case of looping, jumping, and branching (see Section 6). 1158 Suppose an SFF in a particular service overlay network (identified by 1159 a particular import RT, RT-z) needs to forward an NSH-encapsulated 1160 packet whose SPI is SPI-x and whose SI is SI-y. It does the 1161 following: 1163 1. It looks for an installed SFPR that carries RT-z and that has 1164 SPI-x in its NLRI. If there is none, then such packets cannot be 1165 forwarded. 1167 2. From the SFP attribute of that SFPR, it finds the Hop TLV with SI 1168 value set to SI-y. If there is no such Hop TLV, then such 1169 packets cannot be forwarded. 1171 3. It then finds the "relevant" set of SFIRs by going through the 1172 list of SFT TLVs contained in the Hop TLV as follows: 1174 A. An SFIR is relevant if it carries RT-z, the SFT in its NLRI 1175 matches the SFT value in one of the SFT TLVs, and the RD 1176 value in its NLRI matches an entry in the list of SFIR-RDs in 1177 that SFT TLV. 1179 B. If an entry in the SFIR-RD list of an SFT TLV contains the 1180 value zero, then an SFIR is relevant if it carries RT-z and 1181 the SFT in its NLRI matches the SFT value in that SFT TLV. 1182 I.e., any SFIR in the service function overlay network 1183 defined by RT-z and with the correct SFT is relevant. 1185 Each of the relevant SFIRs identifies a single SFI, and contains a 1186 Tunnel Encapsulation attribute that specifies how to send a packet to 1187 that SFI. For a particular packet, the SFF chooses a particular SFI 1188 from the set of relevant SFIRs. This choice is made according to 1189 local policy. 1191 A typical policy might be to figure out the set of SFIs that are 1192 closest, and to load balance among them. But this is not the only 1193 possible policy. 1195 6. Looping, Jumping, and Branching 1197 As described in Section 2 an SFI or an SFF may cause a packet to 1198 "loop back" to a previous SF on a path in order that a sequence of 1199 functions may be re-executed. This is simply achieved by replacing 1200 the SI in the NSH with a higher value instead of decreasing it as 1201 would normally be the case to determine the next hop in the path. 1203 Section 2 also describes how an SFI or an SFF may cause a packets to 1204 "jump forward" to an SF on a path that is not the immediate next SF 1205 in the SFP. This is simply achieved by replacing the SI in the NSH 1206 with a lower value than would be achieved by decreasing it by the 1207 normal amount. 1209 A more complex option to move packets from one SFP to another is 1210 described in [RFC8300] and Section 2 where it is termed "branching". 1211 This mechanism allows an SFI or SFF to make a choice of downstream 1212 treatments for packets based on local policy and output of the local 1213 SF. Branching is achieved by changing the SPI in the NSH to indicate 1214 the new path and setting the SI to indicate the point in the path at 1215 which the packets should enter. 1217 Note that the NSH does not include a marker to indicate whether a 1218 specific packet has been around a loop before. Therefore, the use of 1219 NSH metadata may be required in order to prevent infinite loops. 1221 6.1. Protocol Control of Looping, Jumping, and Branching 1223 If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT 1224 value "Change Sequence" (see Section 10) then this is an indication 1225 that the SFF may make a loop, jump, or branch according to local 1226 policy and information returned by the local SFI. 1228 In this case, the SPI and SI of the next hop is encoded in the eight 1229 bytes of an entry in the SFIR-RD list as follows: 1231 3 bytes SPI 1233 2 bytes SI 1234 3 bytes Reserved (SHOULD be set to zero and ignored) 1236 If the SI in this encoding is not part of the SFPR indicated by the 1237 SPI in this encoding, then this is an explicit error that SHOULD be 1238 detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT 1239 cause any forwarding state to be installed in the SFF and packets 1240 received with the SPI that indicates this SFPR SHOULD be silently 1241 discarded. 1243 If the SPI in this encoding is unknown, the SFF SHOULD NOT install 1244 any forwarding state for this SFPR, but MAY hold the SFPR pending 1245 receipt of another SFPR that does use the encoded SPI. 1247 If the SPI matches the current SPI for the path, this is a loop or 1248 jump. In this case, if the SI is greater than to the current SI it 1249 is a loop. If the SPI matches and the SI is less than the next SI, 1250 it is a jump. 1252 If the SPI indicates anther path, this is a branch and the SI 1253 indicates the point at which to enter that path. 1255 The Change Sequence SFT is just another SFT that may appear in a set 1256 of SFI/SFT tuples within an SI and is selected as described in 1257 Section 5. 1259 Note that Special Purpose SFTs MUST NOT be advertised in SFIRs. 1261 6.2. Implications for Forwarding State 1263 Support for looping and jumping requires that the SFF has forwarding 1264 state established to an SFF that provides access to an instance of 1265 the appropriate SF. This means that the SFF must have seen the 1266 relevant SFIR advertisements and known that it needed to create the 1267 forwarding state. This is a matter of local configuration and 1268 implementation: for example, an implementation could be configured to 1269 install forwarding state for specific looping/jumping. 1271 Support for branching requires that the SFF has forwarding state 1272 established to an SFF that provides access to an instance of the 1273 appropriate entry SF on the other SFP. This means that the SFF must 1274 have seen the relevant SFIR and SFPR advertisements and known that it 1275 needed to create the forwarding state. This is a matter of local 1276 configuration and implementation: for example, an implementation 1277 could be configured to install forwarding state for specific 1278 branching (identified by SPI and SI). 1280 7. Advanced Topics 1282 This section highlights several advanced topics introduced elsewhere 1283 in this document. 1285 7.1. Preserving Entropy 1287 Forwarding decisions in the underlay network in the presence of equal 1288 cost multipath (ECMP) are usually made by inspecting key invariant 1289 fields in a packet header so that all packets from the same packet 1290 flow receive the same forwarding treatment. However, when an NSH is 1291 included in a packet, those key fields may be inaccessible. For 1292 example, the fields may be too far inside the packet for a forwarding 1293 engine to quickly find them and extract their values, or the node 1294 performing the examination may be unaware of the format and meaning 1295 of the NSH and so unable to parse far enough into the packet. 1297 Various mechanisms exist within forwarding technologies to include an 1298 "entropy indicator" within a forwarded packet. For example, in MPLS 1299 there is the entropy label [RFC6790], while for encapsulations in UDP 1300 the source port field is often used to carry an entropy indicator 1301 (such as for MPLS in UDP [RFC7510]). 1303 Implementations of this specification are RECOMMENDED to include an 1304 entropy indicator within the packet's underlay network header, and 1305 SHOULD preserve any entropy indicator from a received packet for use 1306 on the same packet when it is forwarded along the path but MAY choose 1307 to generate a new entropy indicator so long as the method used is 1308 constant for all packets. Note that preserving per packet entropy 1309 may require that the entropy indicator is passed to and returned by 1310 the SFI to prevent the SFF from having to maintain per-packet state. 1312 7.2. Correlating Service Function Path Instances 1314 It is often useful to create bidirectional SFPs to enable packet 1315 flows to traverse the same set of SFs, but in the reverse order. 1316 However, packets on SFPs in the data plane (per [RFC8300]) do not 1317 contain a direction indicator, so each direction must use a different 1318 SPI. 1320 As described in Section 3.2.1.1 an SFPR can contain one or more 1321 correlators encoded in Association TLVs. If the Association Type 1322 indicates "Bidirectional SFP" then the SFP advertised in the SFPR is 1323 one direction of a bidirectional pair of SFPs where the other in the 1324 pair is advertised in the SFPR with RD as carried in the Associated 1325 SFPR-RD field of the Association TLV. The SPI carried in the 1326 Associated SPI field of the Association TLV provides a cross-check 1327 and should match the SPI advertised in the SFPR with RD as carried in 1328 the Associated SFPR-RD field of the Association TLV. 1330 As noted in Section 3.2.1.1 SFPRs reference each other one SFPR 1331 advertisement will be received before the other. Therefore 1332 processing of an association will require that the first SFPR is not 1333 rejected simply because the Associated SFPR-RD it carries is unknown. 1334 However, the SFP defined by the first SFPR is valid and SHOULD be 1335 available for use as a unidirectional SFP even in the absence of an 1336 advertisement of its partner. 1338 Furthermore, in error cases where SFPR-a associates with SFPR-b, but 1339 SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs 1340 cannot be formed, the individual SFPs are still valid and SHOULD be 1341 available for use as unidirectional SFPs. An implementation SHOULD 1342 log this situation because it represents a Controller error. 1344 Usage of a bidirectional SFP may be programmed into the Classifiers 1345 by the Controller. Alternatively, a Classifier may look at incoming 1346 packets on a bidirectional packet flow, extract the SPI from the 1347 received NSH, and look up the SFPR to find the reverse direction SFP 1348 to use when it sends packets. 1350 See Section 8 for an example of how this works. 1352 7.3. Considerations for Stateful Service Functions 1354 Some service functions are stateful. That means that they build and 1355 maintain state derived from configuration or from the packet flows 1356 that they handle. In such cases it can be important or necessary 1357 that all packets from a flow continue to traverse the same instance 1358 of a service function so that the state can be leveraged and does not 1359 need to be regenerated. 1361 In the case of bidirectional SFPs, it may be necessary to traverse 1362 the same instances of a stateful service function in both directions. 1363 A firewall is a good example of such a service function. 1365 This issue becomes a concern where there are multiple parallel 1366 instances of a service function and a determination of which one to 1367 use could normally be left to the SFF as a load-balancing or local 1368 policy choice. 1370 For the forward direction SFP, the concern is that the same choice of 1371 service function is made for all packets of a flow under normal 1372 network conditions. It may be possible to guarantee that the load 1373 balancing functions applied in the SFFs are stable and repeatable, 1374 but a controller that constructs SFPs might not want to trust to 1375 this. The controller can, in these cases, build a number of more 1376 specific SFPs each traversing a specific instance of the stateful 1377 SFs. In this case, the load balancing choice can be left up to the 1378 Classifier. Thus the Classifier selects which instance of a stateful 1379 SF is used by a particular flow by selecting the SFP that the flow 1380 uses. 1382 For bidirectional SFPs where the same instance of a stateful SF must 1383 be traversed in both directions, it is not enough to leave the choice 1384 of service function instance as a local choice even if the load 1385 balancing is stable because coordination would be required between 1386 the decision points in the forward and reverse directions and this 1387 may be hard to achieve in all cases except where it is the same SFF 1388 that makes the choice in both directions. 1390 Note that this approach necessarily increases the amount of SFP state 1391 in the network (i.e., there are more SFPs). It is possible to 1392 mitigate this effect by careful construction of SFPs built from a 1393 concatenation of other SFPs. 1395 Section 8.9 includes some simple examples of SFPs for stateful 1396 service functions. 1398 7.4. VPN Considerations and Private Service Functions 1400 Likely deployments include reserving specific instances of Service 1401 Functions for specific customers or allowing customers to deploy 1402 their own Service Functions within the network. Building Service 1403 Functions in such environments requires that suitable identifiers are 1404 used to ensure that SFFs distinguish which SFIs can be used and which 1405 cannot. 1407 This problem is similar to how VPNs are supported and is solved in a 1408 similar way. The RT field is used to indicate a set of Service 1409 Functions from which all choices must be made. 1411 7.5. Flow Spec for SFC Classifiers 1413 [RFC5575] defines a set of BGP routes that can be used to identify 1414 the packets in a given flow using fields in the header of each 1415 packet, and a set of actions, encoded as extended communities, that 1416 can be used to disposition those packets. This document enables the 1417 use of RFC 5575 mechanisms by SFC Classifiers by defining a new 1418 action extended community called "Flow Spec for SFC classifiers" 1419 identified by the value TBD4. Note that other action extended 1420 communities may also be present. 1422 This extended community is encoded as an 8-octet value, as shown in 1423 Figure 11: 1425 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 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Type=0x80 | Sub-Type=TBD4 | SPI | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | SPI (cont.) | SI | SFT | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 Figure 11: The Format of the Flow Spec for SFC Classifiers Extended 1433 Community 1435 The extended community contains the Service Path Identifier (SPI), 1436 Service Index (SI), and Service Function Type (SFT) as defined 1437 elsewhere in this document. Thus, each action extended community 1438 defines the entry point (not necessarily the first hop) into a 1439 specific service function path. This allows, for example, different 1440 flows to enter the same service function path at different points. 1442 Note that a given Flow Spec update according to [RFC5575] may include 1443 multiple of these action extended communities, and that if a given 1444 action extended community does not contain an installed SFPR with the 1445 specified {SPI, SI, SFT} it MUST NOT be used for dispositioning the 1446 packets of the specified flow. 1448 The normal case of packet classification for SFC will see a packet 1449 enter the SFP at its first hop. In this case the SI in the extended 1450 community is superfluous and the SFT may also be unnecessary. To 1451 allow these cases to be handled, a special meaning is assigned to a 1452 Service Index of zero (not a valid value) and an SFT of zero (a 1453 reserved value in the registry - see Section 10.5). 1455 o If an SFC Classifiers Extended Community is received with SI = 0 1456 then it means that the first hop of the SFP indicated by the SPI 1457 MUST be used. 1459 o If an SFC Classifiers Extended Community is received with SFT = 0 1460 then there are two sub-cases: 1462 * If there is a choice of SFT in the hop indicated by the value 1463 of the SI (including SI = 0) then SFT = 0 means there is a free 1464 choice according to local policy of which SFT to use). 1466 * If there is no choice of SFT in the hop indicated by the value 1467 of SI, then SFT = 0 means that the value of the SFT at that hop 1468 as indicated in the SPFR for the indicated SPI MUST be used. 1470 7.6. Choice of Data Plane SPI/SI Representation 1472 This document ties together the control and data planes of an SFC 1473 overlay network through the use of the SPI/SI which is nominally 1474 carried in the NSH of a given packet. However, in order to handle 1475 situations in which the NSH is not ubiquitously deployed, it is also 1476 possible to use alternative data plane representations of the SPI/SI 1477 by carrying the identical semantics in other protocol fields such as 1478 MPLS labels [I-D.ietf-mpls-sfc]. 1480 This document defines a new sub-TLV for the Tunnel Encapsulation 1481 attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub- 1482 TLV MAY be present in each Tunnel TLV contained in a Tunnel 1483 Encapsulation attribute when the attribute is carried by an SFIR. 1484 The value field of this sub-TLV is a two octet field of flags, each 1485 of which describes how the originating SFF expects to see the SPI/SI 1486 represented in the data plane for packets carried in the tunnels 1487 described by the Tunnel TLV. 1489 The following bits are defined by this document: 1491 Bit 0: If this bit is set the NSH is to be used to carry the SPI/SI 1492 in the data plane. 1494 Bit 1: If this bit is set two labels in an MPLS label stack are to 1495 be used as described in Section 7.6.1. 1497 If a given Tunnel TLV does not contain an SPI/SI Representation sub- 1498 TLV then it MUST be processed as if such a sub-TLV is present with 1499 Bit 0 set and no other bits set. That is, the absence of the sub-TLV 1500 SHALL be interpreted to mean that the NSH is to be used. 1502 If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with 1503 value field that has no flag set then the tunnel indicated by the 1504 Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given 1505 Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit 0 1506 and bit 1 set then the tunnel indicated by the Tunnel TLV MUST NOT be 1507 used for forwarding SFC packets. The meaning and rules for presence 1508 of other bits is to be defined in future documents, but 1509 implementations of this specification MUST set other bits to zero and 1510 ignore them on receipt. 1512 If a given Tunnel TLV contains more than one SPI/SI Representation 1513 sub-TLV then the first one MUST be considered and subsequent 1514 instances MUST be ignored. 1516 Note that the MPLS representation of the logical NSH may be used even 1517 if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be 1518 used to carry other encodings of the logical NSH (specifically, the 1519 NSH itself). It is a requirement that both ends of a tunnel over the 1520 underlay network know that the tunnel is used for SFC and know what 1521 form of NSH representation is used. The signaling mechanism 1522 described here allows coordination of this information. 1524 7.6.1. MPLS Representation of the SPI/SI 1526 If bit 1 is set in the in the SPI/SI Representation sub-TLV then 1527 labels in the MPLS label stack are used to indicate SFC forwarding 1528 and processing instructions to achieve the semantics of a logical 1529 NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc]. 1531 7.7. MPLS Label Swapping/Stacking Operation 1533 When a classifier constructs an MPLS label stack for an SFP it starts 1534 with that SFP' last hop. If the last hop requires an {SPI, SI} label 1535 pair for label swapping, it pushes the SI (set to the SI value of the 1536 last hop) and the SFP's SPI onto the MPLS label stack. If the last 1537 hop requires a {context label, SFI label} label pair for label 1538 stcking it selects a specific SFIR and pushes that SFIR's SFI label 1539 and context label onto the MPLS label stack. 1541 The classifier then moves sequentially back through the SFP one hop 1542 at a time. For each hop, if the hop requires an {SPI, SI]} and there 1543 is an {SPI, SI} at the top of the MPLS label stack, the SI is set to 1544 the SI value of the current hop. If there is not an {SPI, SI} at the 1545 top of the MPLS label stack, it pushes the SI (set to the SI value of 1546 the current hop) and the SFP's SPI onto the MPLS label stack. 1548 If the hop requires a {context label, SFI label}, it selects a 1549 specific SFIR and pushes that SFIR's SFI label and context label onto 1550 the MPLS label stack. 1552 8. Examples 1554 Assume we have a service function overlay network with four SFFs 1555 (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the 1556 underlay network as follows: 1558 SFF1 192.0.2.1 1559 SFF2 192.0.2.2 1560 SFF3 192.0.2.3 1561 SFF4 192.0.2.4 1563 Each SFF provides access to some SFIs from the four Service Function 1564 Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows: 1566 SFF1 SFT=41 and SFT=42 1567 SFF2 SFT=41 and SFT=43 1568 SFF3 SFT=42 and SFT=44 1569 SFF4 SFT=43 and SFT=44 1571 The service function network also contains a Controller with address 1572 198.51.100.1. 1574 This example service function overlay network is shown in Figure 12. 1576 -------------- 1577 | Controller | 1578 | 198.51.100.1 | ------ ------ ------ ------ 1579 -------------- | SFI | | SFI | | SFI | | SFI | 1580 |SFT=41| |SFT=42| |SFT=41| |SFT=43| 1581 ------ ------ ------ ------ 1582 \ / \ / 1583 --------- --------- 1584 ---------- | SFF1 | | SFF2 | 1585 Packet --> | | |192.0.2.1| |192.0.2.2| 1586 Flows --> |Classifier| --------- --------- -->Dest 1587 | | --> 1588 ---------- --------- --------- 1589 | SFF3 | | SFF4 | 1590 |192.0.2.3| |192.0.2.4| 1591 --------- --------- 1592 / \ / \ 1593 ------ ------ ------ ------ 1594 | SFI | | SFI | | SFI | | SFI | 1595 |SFT=42| |SFT=44| |SFT=43| |SFT=44| 1596 ------ ------ ------ ------ 1598 Figure 12: Example Service Function Overlay Network 1600 The SFFs advertise routes to the SFIs they support. So we see the 1601 following SFIRs: 1603 RD = 192.0.2.1,1, SFT = 41 1604 RD = 192.0.2.1,2, SFT = 42 1605 RD = 192.0.2.2,1, SFT = 41 1606 RD = 192.0.2.2,2, SFT = 43 1607 RD = 192.0.2.3,7, SFT = 42 1608 RD = 192.0.2.3,8, SFT = 44 1609 RD = 192.0.2.4,5, SFT = 43 1610 RD = 192.0.2.4,6, SFT = 44 1612 Note that the addressing used for communicating between SFFs is taken 1613 from the Tunnel Encapsulation attribute of the SFIR and not from the 1614 SFIR-RD. 1616 8.1. Example Explicit SFP With No Choices 1618 Consider the following SFPR. 1620 SFP1: RD = 198.51.100.1,101, SPI = 15, 1621 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1622 [SI = 250, SFT = 43, RD = 192.0.2.2,2] 1624 The Service Function Path consists of an SF of type 41 located at 1625 SFF1 followed by an SF of type 43 located at SFF2. This path is 1626 fully explicit and each SFF is offered no choice in forwarding packet 1627 along the path. 1629 SFF1 will receive packets on the path from the Classifier and will 1630 identify the path from the SPI (15). The initial SI will be 255 and 1631 so SFF1 will deliver the packets to the SFI for SFT 41. 1633 When the packets are returned to SFF1 by the SFI the SI will be 1634 decreased to 250 for the next hop. SFF1 has no flexibility in the 1635 choice of SFF to support the next hop SFI and will forward the packet 1636 to SFF2 which will send the packets to the SFI that supports SFT 43 1637 before forwarding the packets to their destinations. 1639 8.2. Example SFP With Choice of SFIs 1640 SFP2: RD = 198.51.100.1,102, SPI = 16, 1641 [SI = 255, SFT = 41, RD = 192.0.2.1,], 1642 [SI = 250, SFT = 43, {RD = 192.0.2.2,2, 1643 RD = 192.0.2.4,5 } ] 1645 In this example the path also consists of an SF of type 41 located at 1646 SFF1 and this is followed by an SF of type 43, but in this case the 1647 SI = 250 contains a choice between the SFI located at SFF2 and the 1648 SFI located at SFF4. 1650 SFF1 will receive packets on the path from the Classifier and will 1651 identify the path from the SPI (16). The initial SI will be 255 and 1652 so SFF1 will deliver the packets to the SFI for SFT 41. 1654 When the packets are returned to SFF1 by the SFI the SI will be 1655 decreased to 250 for the next hop. SFF1 now has a choice of next hop 1656 SFF to execute the next hop in the path. It can either forward 1657 packets to SFF2 or SFF4 to execute a function of type 43. It uses 1658 its local load balancing algorithm to make this choice. The chosen 1659 SFF will send the packets to the SFI that supports SFT 43 before 1660 forwarding the packets to their destinations. 1662 8.3. Example SFP With Open Choice of SFIs 1664 SFP3: RD = 198.51.100.1,103, SPI = 17, 1665 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1666 [SI = 250, SFT = 44, RD = 0] 1668 In this example the path also consists of an SF of type 41 located at 1669 SFF1 and this is followed by an SI with an RD of zero and SF of type 1670 44. This means that a choice can be made between any SFF that 1671 supports an SFI of type 44. 1673 SFF1 will receive packets on the path from the Classifier and will 1674 identify the path from the SPI (17). The initial SI will be 255 and 1675 so SFF1 will deliver the packets to the SFI for SFT 41. 1677 When the packets are returned to SFF1 by the SFI the SI will be 1678 decreased to 250 for the next hop. SFF1 now has a free choice of 1679 next hop SFF to execute the next hop in the path selecting between 1680 all SFFs that support SFs of type 44. Looking at the SFIRs it has 1681 received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. 1682 SFF1 uses its local load balancing algorithm to make this choice. 1683 The chosen SFF will send the packets to the SFI that supports SFT 44 1684 before forwarding the packets to their destinations. 1686 8.4. Example SFP With Choice of SFTs 1688 SFP4: RD = 198.51.100.1,104, SPI = 18, 1689 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1690 [SI = 250, {SFT = 43, RD = 192.0.2.2,2, 1691 SFT = 44, RD = 192.0.2.3,8 } ] 1693 This example provides a choice of SF type in the second hop in the 1694 path. The SI of 250 indicates a choice between SF type 43 located 1695 through SF2 and SF type 44 located at SF3. 1697 SFF1 will receive packets on the path from the Classifier and will 1698 identify the path from the SPI (18). The initial SI will be 255 and 1699 so SFF1 will deliver the packets to the SFI for SFT 41. 1701 When the packets are returned to SFF1 by the SFI the SI will be 1702 decreased to 250 for the next hop. SFF1 now has a free choice of 1703 next hop SFF to execute the next hop in the path selecting between 1704 all SFF2 that support an SF of type 43 and SFF3 that supports an SF 1705 of type 44. These may be completely different functions that are to 1706 be executed dependent on specific conditions, or may be similar 1707 functions identified with different type identifiers (such as 1708 firewalls from different vendors). SFF1 uses its local policy and 1709 load balancing algorithm to make this choice, and may use additional 1710 information passed back from the local SFI to help inform its 1711 selection. The chosen SFF will send the packets to the SFI that 1712 supports the chose SFT before forwarding the packets to their 1713 destinations. 1715 8.5. Example Correlated Bidirectional SFPs 1717 SFP5: RD = 198.51.100.1,105, SPI = 19, 1718 Assoc-Type = 1, Assoc-RD = 198.51.100.1,106, Assoc-SPI = 20, 1719 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1720 [SI = 250, SFT = 43, RD = 192.0.2.2,2] 1722 SFP6: RD = 198.51.100.1,106, SPI = 20, 1723 Assoc-Type = 1, Assoc-RD = 198.51.100.1,105, Assoc-SPI = 19, 1724 [SI = 254, SFT = 43, RD = 192.0.2.2,2], 1725 [SI = 249, SFT = 41, RD = 192.0.2.1,1] 1727 This example demonstrates correlation of two SFPs to form a 1728 bidirectional SFP as described in Section 7.2. 1730 Two SFPRs are advertised by the Controller. They have different SPIs 1731 (19 and 20) so they are known to be separate SFPs, but they both have 1732 Association TLVs with Association Type set to 1 indicating 1733 bidirectional SFPs. Each has an Associated SFPR-RD fields containing 1734 the value of the other SFPR-RD to correlated the two SFPs as a 1735 bidirectional pair. 1737 As can be seen from the SFPRs in this example, the paths are 1738 symmetric: the hops in SFP5 appear in the reverse order in SFP6. 1740 8.6. Example Correlated Asymmetrical Bidirectional SFPs 1742 SFP7: RD = 198.51.100.1,107, SPI = 21, 1743 Assoc-Type = 1, Assoc-RD = 198.51.100.1,108, Assoc-SPI = 22, 1744 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1745 [SI = 250, SFT = 43, RD = 192.0.2.2,2] 1747 SFP8: RD = 198.51.100.1,108, SPI = 22, 1748 Assoc-Type = 1, Assoc-RD = 198.51.100.1,107, Assoc-SPI = 21, 1749 [SI = 254, SFT = 44, RD = 192.0.2.4,6], 1750 [SI = 249, SFT = 41, RD = 192.0.2.1,1] 1752 Asymmetric bidirectional SFPs can also be created. This example 1753 shows a pair of SFPs with distinct SPIs (21 and 22) that are 1754 correlated in the same way as in the example in Section 8.5. 1756 However, unlike in that example, the SFPs are different in each 1757 direction. Both paths include a hop of SF type 41, but SFP7 includes 1758 a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF 1759 type 44 supported at SFF4. 1761 8.7. Example Looping in an SFP 1763 SFP9: RD = 198.51.100.1,109, SPI = 23, 1764 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1765 [SI = 250, SFT = 44, RD = 192.0.2.4,5], 1766 [SI = 245, SFT = 1, RD = {SPI=23, SI=255, Rsv=0}], 1767 [SI = 245, SFT = 42, RD = 192.0.2.3,7] 1769 Looping and jumping are described in Section 6. This example shows 1770 an SFP that contains an explicit loop-back instruction that is 1771 presented as a choice within an SFP hop. 1773 The first two hops in the path (SI = 255 and SI = 250) are normal. 1774 That is, the packets will be delivered to SFF1 and SFF4 in turn for 1775 execution of SFs of type 41 and 44 respectively. 1777 The third hop (SI = 245) presents SFF4 with a choice of next hop. It 1778 can either forward the packets to SFF3 for an SF of type 42 (the 1779 second choice), or it can loop back. 1781 The loop-back entry in the SFPR for SI = 245 is indicated by the 1782 special purpose SFT value 1 ("Change Sequence"). Within this hop, 1783 the RD is interpreted as encoding the SPI and SI of the next hop (see 1784 Section 6.1. In this case the SPI is 23 which indicates that this is 1785 loop or branch: i.e., the next hop is on the same SFP. The SI is set 1786 to 255: this is a higher number than the current SI (245) indicating 1787 a loop. 1789 SFF4 must make a choice between these two next hops. Either the 1790 packets will be forwarded to SFF3 with the NSH SI decreased to 245 or 1791 looped back to SFF1 with the NSH SI reset to 255. This choice will 1792 be made according to local policy, information passed back by the 1793 local SFI, and details in the packets' metadata that are used to 1794 prevent infinite looping. 1796 8.8. Example Branching in an SFP 1798 SFP10: RD = 198.51.100.1,110, SPI = 24, 1799 [SI = 254, SFT = 42, RD = 192.0.2.3,7], 1800 [SI = 249, SFT = 43, RD = 192.0.2.2,2] 1802 SFP11: RD = 198.51.100.1,111, SPI = 25, 1803 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1804 [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}] 1806 Branching follows a similar procedure to that for looping (and 1807 jumping) as shown in Section 8.7 however there are two SFPs involved. 1809 SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for 1810 execution of service functions of type 42 and 43 respectively. 1812 SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1 1813 processes the next hop in the path and finds a "Change Sequence" 1814 Special Purpose SFT. The SFIR-RD field includes an SPI of 24 which 1815 indicates SFP10, not the current SFP. The SI in the SFIR-RD is 254, 1816 so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and 1817 send the packets to the appropriate SFF as advertised in the SFPR for 1818 SFP10 (that is, SFF3). 1820 8.9. Examples of SFPs with Stateful Service Functions 1822 This section provides some examples to demonstrate establishing SFPs 1823 when there is a choice of service functions at a particular hop, and 1824 where consistency of choice is required in both directions. The 1825 scenarios that give rise to this requirement are discussed in 1826 Section 7.3. 1828 8.9.1. Forward and Reverse Choice Made at the SFF 1830 Consider the topology shown in Figure 13. There are three SFFs 1831 arranged neatly in a line, and the middle one (SFF2) supports three 1832 SFIs all of SFT 42. These three instances can be used by SFF2 to 1833 load balance so that no one instance is swamped. 1835 ------ ------ ------ ------ ------ 1836 | SFI | | SFIa | | SFIb | | SFIc | | SFI | 1837 |SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43| 1838 ------ ------\ ------ /------ ------ 1839 \ \ | / / 1840 --------- --------- --------- 1841 ---------- | SFF1 | | SFF2 | | SFF3 | 1842 --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> 1843 --> |Classifier| --------- --------- --------- 1844 | | 1845 ---------- 1847 Figure 13: Example Where Choice is Made at the SFF 1849 This leads to the following SFIRs being advertised. 1851 RD = 192.0.2.1,11, SFT = 41 1852 RD = 192.0.2.2,11, SFT = 42 (for SFIa) 1853 RD = 192.0.2.2,12, SFT = 42 (for SFIb) 1854 RD = 192.0.2.2,13, SFT = 42 (for SFIc) 1855 RD = 192.0.2.3,11, SFT = 43 1857 The controller can create a single forward SFP giving SFF2 the choice 1858 of which SFI to use to provide function of SFT 42 as follows. The 1859 load-balancing choice between the three available SFIs is assumed to 1860 be within the capabilities of the SFF and if the SFs are stateful it 1861 is assumed that the SFF knows this and arranges load balancing in a 1862 stable, flow-dependent way. 1864 SFP12: RD = 198.51.100.1,112, SPI = 26, 1865 Assoc-Type = 1, Assoc-RD = 198.51.100.1,113, Assoc-SPI = 27, 1866 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1867 [SI = 254, SFT = 42, {RD = 192.0.2.2,11, 1868 192.0.2.2,12, 1869 192.0.2.2,13 }], 1870 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1872 The reverse SFP in this case may also be created as shown below using 1873 association with the forward SFP and giving the load-balancing choice 1874 to SFF2. This is safe, even in the case that the SFs of type 42 are 1875 stateful because SFF2 is doing the load balancing in both directions 1876 and can apply the same algorithm to ensure that packets associated 1877 with the same flow use the same SFI regardless of the direction of 1878 travel. 1880 SFP13: RD = 198.51.100.1,113, SPI = 27, 1881 Assoc-Type = 1, Assoc-RD = 198.51.100.1,112, Assoc-SPI = 26, 1882 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1883 [SI = 254, SFT = 42, {RD = 192.0.2.2,11, 1884 192.0.2.2,12, 1885 192.0.2.2,13 }], 1886 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1888 8.9.2. Parallel End-to-End SFPs with Shared SFF 1890 The mechanism described in Section 8.9.1 might not be desirable 1891 because of the functional assumptions it places on SFF2 to be able to 1892 load balance with suitable flow identification, stability, and 1893 equality in both directions. Instead, it may be desirable to place 1894 the responsibility for flow classification in the Classifier and let 1895 it determine load balancing with the implied choice of SFIs. 1897 Consider the network graph as shown in Figure 13 and with the same 1898 set of SFIRs as listed in Section 8.9.1. In this case the controller 1899 could specify three forward SFPs with their corresponding associated 1900 reverse SFPs. Each bidirectional pair of SFPs uses a different SFI 1901 for the SF of type 42. The controller can instruct the Classifier 1902 how to place traffic on the three bidirectional SFPs, or can treat 1903 them as a group leaving the Classifier responsible for balancing the 1904 load. 1906 SFP14: RD = 198.51.100.1,114, SPI = 28, 1907 Assoc-Type = 1, Assoc-RD = 198.51.100.1,117, Assoc-SPI = 31, 1908 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1909 [SI = 254, SFT = 42, RD = 192.0.2.2,11], 1910 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1912 SFP15: RD = 198.51.100.1,115, SPI = 29, 1913 Assoc-Type = 1, Assoc-RD = 198.51.100.1,118, Assoc-SPI = 32, 1914 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1915 [SI = 254, SFT = 42, RD = 192.0.2.2,12], 1916 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1918 SFP16: RD = 198.51.100.1,116, SPI = 30, 1919 Assoc-Type = 1, Assoc-RD = 198.51.100.1,119, Assoc-SPI = 33, 1920 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1921 [SI = 254, SFT = 42, RD = 192.0.2.2,13], 1922 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1924 SFP17: RD = 198.51.100.1,117, SPI = 31, 1925 Assoc-Type = 1, Assoc-RD = 198.51.100.1,114, Assoc-SPI = 28, 1926 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1927 [SI = 254, SFT = 42, RD = 192.0.2.2,11], 1928 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1930 SFP18: RD = 198.51.100.1,118, SPI = 32, 1931 Assoc-Type = 1, Assoc-RD = 198.51.100.1,115, Assoc-SPI = 29, 1932 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1933 [SI = 254, SFT = 42, RD = 192.0.2.2,12], 1934 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1936 SFP19: RD = 198.51.100.1,119, SPI = 33, 1937 Assoc-Type = 1, Assoc-RD = 198.51.100.1,116, Assoc-SPI = 30, 1938 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1939 [SI = 254, SFT = 42, RD = 192.0.2.2,13], 1940 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1942 8.9.3. Parallel End-to-End SFPs with Separate SFFs 1944 While the examples in Section 8.9.1 and Section 8.9.2 place the 1945 choice of SFI as subtended from the same SFF, it is also possible 1946 that the SFIs are each subtended from a different SFF as shown in 1947 Figure 14. In this case it is harder to coordinate the choices for 1948 forward and reverse paths without some form of coordination between 1949 SFF1 and SFF3. Therefore it would be normal to consider end-to-end 1950 parallel SFPs as described in Section 8.9.2. 1952 ------ 1953 | SFIa | 1954 |SFT=42| 1955 ------ 1956 ------ | 1957 | SFI | --------- 1958 |SFT=41| | SFF5 | 1959 ------ ..|192.0.2.5|.. 1960 | ..: --------- :.. 1961 ---------.: :.--------- 1962 ---------- | SFF1 | --------- | SFF3 | 1963 --> | |..|192.0.2.1|....| SFF6 |....|192.0.2.3| --> 1964 --> |Classifier| ---------: |192.0.2.6| :--------- 1965 | | : --------- : | 1966 ---------- : | : ------ 1967 : ------ : | SFI | 1968 :.. | SFIb | ..: |SFT=43| 1969 :.. |SFT=42| ..: ------ 1970 : ------ : 1971 :.---------.: 1972 | SFF7 | 1973 |192.0.2.7| 1974 --------- 1975 | 1976 ------ 1977 | SFIc | 1978 |SFT=42| 1979 ------ 1981 Figure 14: Second Example With Parallel End-to-End SFPs 1983 In this case, five SFIRs are advertised as follows: 1985 RD = 192.0.2.1,11, SFT = 41 1986 RD = 192.0.2.5,11, SFT = 42 (for SFIa) 1987 RD = 192.0.2.6,11, SFT = 42 (for SFIb) 1988 RD = 192.0.2.7,11, SFT = 42 (for SFIc) 1989 RD = 192.0.2.3,11, SFT = 43 1991 In this case the controller could specify three forward SFPs with 1992 their corresponding associated reverse SFPs. Each bidirectional pair 1993 of SFPs uses a different SFF and SFI for middle hop (for an SF of 1994 type 42). The controller can instruct the Classifier how to place 1995 traffic on the three bidirectional SFPs, or can treat them as a group 1996 leaving the Classifier responsible for balancing the load. 1998 SFP20: RD = 198.51.100.1,120, SPI = 34, 1999 Assoc-Type = 1, Assoc-RD = 198.51.100.1,123, Assoc-SPI = 37, 2000 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 2001 [SI = 254, SFT = 42, RD = 192.0.2.5,11], 2002 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 2004 SFP21: RD = 198.51.100.1,121, SPI = 35, 2005 Assoc-Type = 1, Assoc-RD = 198.51.100.1,124, Assoc-SPI = 38, 2006 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 2007 [SI = 254, SFT = 42, RD = 192.0.2.6,11], 2008 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 2010 SFP22: RD = 198.51.100.1,122, SPI = 36, 2011 Assoc-Type = 1, Assoc-RD = 198.51.100.1,125, Assoc-SPI = 39, 2012 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 2013 [SI = 254, SFT = 42, RD = 192.0.2.7,11], 2014 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 2016 SFP23: RD = 198.51.100.1,123, SPI = 37, 2017 Assoc-Type = 1, Assoc-RD = 198.51.100.1,120, Assoc-SPI = 34, 2018 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 2019 [SI = 254, SFT = 42, RD = 192.0.2.5,11], 2020 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 2022 SFP24: RD = 198.51.100.1,124, SPI = 38, 2023 Assoc-Type = 1, Assoc-RD = 198.51.100.1,121, Assoc-SPI = 35, 2024 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 2025 [SI = 254, SFT = 42, RD = 192.0.2.6,11], 2026 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 2028 SFP25: RD = 198.51.100.1,125, SPI = 39, 2029 Assoc-Type = 1, Assoc-RD = 198.51.100.1,122, Assoc-SPI = 36, 2030 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 2031 [SI = 254, SFT = 42, RD = 192.0.2.7,11], 2032 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 2034 8.9.4. Parallel SFPs Downstream of the Choice 2036 The mechanism of parallel SFPs demonstrated in Section 8.9.3 is 2037 perfectly functional and may be practical in many environments. 2038 However, there may be scaling concerns because of the large amount of 2039 state (knowledge of SFPs, i.e., SFPR advertisements retained) if 2040 there is a very large amount of choice of SFIs (for example, tens of 2041 instances of the same stateful SF), or if there are multiple choices 2042 of stateful SF along a path. This situation may be mitigated using 2043 SFP fragments that are combined to form the end to end SFPs. 2045 The example presented here is necessarily simplistic, but should 2046 convey the basic principle. The example presented in Figure 15 is 2047 similar to that in Section 8.9.3 but with an additional first hop. 2049 ------ 2050 | SFIa | 2051 |SFT=43| 2052 ------ 2053 ------ ------ | 2054 | SFI | | SFI | --------- 2055 |SFT=41| |SFT=42| | SFF5 | 2056 ------ ------ ..|192.0.2.5|.. 2057 | | ..: --------- :.. 2058 --------- ---------.: :.--------- 2059 ------ | SFF1 | | SFF2 | --------- | SFF3 | 2060 -->|Class-|.|192.0.2.1|.|192.0.2.2|....| SFF6 |....|192.0.2.3|--> 2061 -->| ifier| --------- ---------: |192.0.2.6| :--------- 2062 ------ : --------- : | 2063 : | : ------ 2064 : ------ : | SFI | 2065 :.. | SFIb | ..: |SFT=44| 2066 :.. |SFT=43| ..: ------ 2067 : ------ : 2068 :.---------.: 2069 | SFF7 | 2070 |192.0.2.7| 2071 --------- 2072 | 2073 ------ 2074 | SFIc | 2075 |SFT=43| 2076 ------ 2078 Figure 15: Example With Parallel SFPs Downstream of Choice 2080 The six SFIs are advertised as follows: 2082 RD = 192.0.2.1,11, SFT = 41 2083 RD = 192.0.2.2,11, SFT = 42 2084 RD = 192.0.2.5,11, SFT = 43 (for SFIa) 2085 RD = 192.0.2.6,11, SFT = 43 (for SFIb) 2086 RD = 192.0.2.7,11, SFT = 43 (for SFIc) 2087 RD = 192.0.2.3,11, SFT = 44 2089 SFF2 is the point at which a load balancing choice must be made. So 2090 "tail-end" SFPs are constructed as follows. Each takes in a 2091 different SFF that provides access to an SF of type 43. 2093 SFP26: RD = 198.51.100.1,126, SPI = 40, 2094 Assoc-Type = 1, Assoc-RD = 198.51.100.1,130, Assoc-SPI = 44, 2095 [SI = 255, SFT = 43, RD = 192.0.2.5,11], 2096 [SI = 254, SFT = 44, RD = 192.0.2.3,11] 2098 SFP27: RD = 198.51.100.1,127, SPI = 41, 2099 Assoc-Type = 1, Assoc-RD = 198.51.100.1,131, Assoc-SPI = 45, 2100 [SI = 255, SFT = 43, RD = 192.0.2.6,11], 2101 [SI = 254, SFT = 44, RD = 192.0.2.3,11] 2103 SFP28: RD = 198.51.100.1,128, SPI = 42, 2104 Assoc-Type = 1, Assoc-RD = 198.51.100.1,132, Assoc-SPI = 46, 2105 [SI = 255, SFT = 43, RD = 192.0.2.7,11], 2106 [SI = 254, SFT = 44, RD = 192.0.2.3,11] 2108 Now an end-to-end SFP with load balancing choice can be constructed 2109 as follows. The choice made by SFF2 is expressed in terms of 2110 entering one of the three "tail end" SFPs. 2112 SFP29: RD = 198.51.100.1,129, SPI = 43, 2113 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 2114 [SI = 254, SFT = 42, RD = 192.0.2.2,11], 2115 [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0}, 2116 RD = {SPI=41, SI=255, Rsv=0}, 2117 RD = {SPI=42, SI=255, Rsv=0} } ] 2119 Now, despite the load balancing choice being made other than at the 2120 initial classifier, it is possible for the reverse SFPs to be well- 2121 constructed without any ambiguity. The three reverse paths appear as 2122 follows. 2124 SFP30: RD = 198.51.100.1,130, SPI = 44, 2125 Assoc-Type = 1, Assoc-RD = 198.51.100.1,126, Assoc-SPI = 40, 2126 [SI = 255, SFT = 44, RD = 192.0.2.4,11], 2127 [SI = 254, SFT = 43, RD = 192.0.2.5,11], 2128 [SI = 253, SFT = 42, RD = 192.0.2.2,11], 2129 [SI = 252, SFT = 41, RD = 192.0.2.1,11] 2131 SFP31: RD = 198.51.100.1,131, SPI = 45, 2132 Assoc-Type = 1, Assoc-RD = 198.51.100.1,127, Assoc-SPI = 41, 2133 [SI = 255, SFT = 44, RD = 192.0.2.4,11], 2134 [SI = 254, SFT = 43, RD = 192.0.2.6,11], 2135 [SI = 253, SFT = 42, RD = 192.0.2.2,11], 2136 [SI = 252, SFT = 41, RD = 192.0.2.1,11] 2138 SFP32: RD = 198.51.100.1,132, SPI = 46, 2139 Assoc-Type = 1, Assoc-RD = 198.51.100.1,128, Assoc-SPI = 42, 2140 [SI = 255, SFT = 44, RD = 192.0.2.4,11], 2141 [SI = 254, SFT = 43, RD = 192.0.2.7,11], 2142 [SI = 253, SFT = 42, RD = 192.0.2.2,11], 2143 [SI = 252, SFT = 41, RD = 192.0.2.1,11] 2145 9. Security Considerations 2147 This document inherits all the security considerations discussed in 2148 the documents that specify BGP, the documents that specify BGP 2149 Multiprotocol Extensions, and the documents that define the 2150 attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. For 2151 more information look in [RFC4271], [RFC4760], and 2152 [I-D.ietf-idr-tunnel-encaps]. 2154 Service Function Chaining provides a significant attack opportunity: 2155 packets can be diverted from their normal paths through the network, 2156 can be made to execute unexpected functions, and the functions that 2157 are instantiated in software can be subverted. However, this 2158 specification does not change the existence of Service Function 2159 Chaining and security issues specific to Service Function Chaining 2160 are covered in [RFC7665] and [RFC8300]. 2162 This document defines a control plane for Service Function Chaining. 2163 Clearly, this provides an attack vector for a Service Function 2164 Chaining system as an attack on this control plane could be used to 2165 make the system misbehave. Thus, the security of the BGP system is 2166 critically important to the security of the whole Service Function 2167 Chaining system. 2169 10. IANA Considerations 2171 10.1. New BGP AF/SAFI 2173 IANA maintains a registry of "Address Family Numbers". IANA is 2174 requested to assign a new Address Family Number from the "Standards 2175 Action" range called "BGP SFC" (TBD1 in this document) with this 2176 document as a reference. 2178 IANA maintains a registry of "Subsequent Address Family Identifiers 2179 (SAFI) Parameters". IANA is requested to assign a new SAFI value 2180 from the "Standards Action" range called "BGP SFC" (TBD2 in this 2181 document) with this document as a reference. 2183 10.2. New BGP Path Attribute 2185 IANA maintains a registry of "Border Gateway Protocol (BGP) 2186 Parameters" with a subregistry of "BGP Path Attributes". IANA is 2187 requested to assign a new Path attribute called "SFP attribute" (TBD3 2188 in this document) with this document as a reference. 2190 10.3. New SFP Attribute TLVs Type Registry 2192 IANA maintains a registry of "Border Gateway Protocol (BGP) 2193 Parameters". IANA is request to create a new subregistry called the 2194 "SFP Attribute TLVs" registry. 2196 Valid values are in the range 0 to 65535. 2198 o Values 0 and 65535 are to be marked "Reserved, not to be 2199 allocated". 2201 o Values 1 through 65524 are to be assigned according to the "First 2202 Come First Served" policy [RFC8126]. 2204 This document should be given as a reference for this registry. 2206 The new registry should track: 2208 o Type 2210 o Name 2212 o Reference Document or Contact 2214 o Registration Date 2216 The registry should initially be populated as follows: 2218 Type | Name | Reference | Date 2219 ------+-------------------------+---------------+--------------- 2220 1 | Association TLV | [This.I-D] | Date-to-be-set 2221 2 | Hop TLV | [This.I-D] | Date-to-be-set 2222 3 | SFT-SFI TLV | [This.I-D] | Date-to-be-set 2223 4 | SFT-Pool TLV | [This.I-D] | Date-to-be-set 2224 5 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set 2225 6 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set 2227 10.4. New SFP Association Type Registry 2229 IANA maintains a registry of "Border Gateway Protocol (BGP) 2230 Parameters". IANA is request to create a new subregistry called the 2231 "SFP Association Type" registry. 2233 Valid values are in the range 0 to 65535. 2235 o Values 0 and 65535 are to be marked "Reserved, not to be 2236 allocated". 2238 o Values 1 through 65524 are to be assigned according to the "First 2239 Come First Served" policy [RFC8126]. 2241 This document should be given as a reference for this registry. 2243 The new registry should track: 2245 o Association Type 2247 o Name 2249 o Reference Document or Contact 2251 o Registration Date 2253 The registry should initially be populated as follows: 2255 Association Type | Name | Reference | Date 2256 -----------------+--------------------+------------+--------------- 2257 1 | Bidirectional SFP | [This.I-D] | Date-to-be-set 2259 10.5. New Service Function Type Registry 2261 IANA is request to create a new top-level registry called "Service 2262 Function Chaining Service Function Types". 2264 Valid values are in the range 0 to 65535. 2266 o Values 0 and 65535 are to be marked "Reserved, not to be 2267 allocated". 2269 o Values 1 through 31 are to be assigned by "Standards Action" 2270 [RFC8126] and are referred to as the Special Purpose SFT values. 2272 o Other values (32 through 65534) are to be assigned according to 2273 the "First Come First Served" policy [RFC8126]. 2275 This document should be given as a reference for this registry. 2277 The new registry should track: 2279 o Value 2281 o Name 2283 o Reference Document or Contact 2285 o Registration Date 2287 The registry should initially be populated as follows: 2289 Value | Name | Reference | Date 2290 ------+-----------------------+---------------+--------------- 2291 1 | Change Sequence | [This.I-D] | Date-to-be-set 2293 10.6. New Generic Transitive Experimental Use Extended Community Sub- 2294 Types 2296 IANA maintains a registry of "Border Gateway Protocol (BGP) 2297 Parameters" with a subregistry of "Generic Transitive Experimental 2298 Use Extended Community Sub-Type". IANA is requested to assign a new 2299 sub-type as follows: 2301 "Flow Spec for SFC Classifiers" (TBD4 in this document) with this 2302 document as the reference. 2304 10.7. New BGP Transitive Extended Community Types 2306 IANA maintains a registry of "Border Gateway Protocol (BGP) 2307 Parameters" with a subregistry of "BGP Transitive Extended Community 2308 Types". IANA is requested to assign new types as follows: 2310 "SFI Pool Identifier" (TBD6 in this document) with this document 2311 as the reference. 2313 "MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this 2314 document) with this document as the reference. 2316 10.8. SPI/SI Representation 2318 IANA is requested to assign a codepoint from the "BGP Tunnel 2319 Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI 2320 Representation Sub-TLV" (TBD5 in this document) with this document 2321 being the reference. 2323 11. Contributors 2325 Stuart Mackie 2326 Juniper Networks 2328 Email: wsmackie@juinper.net 2330 Keyur Patel 2331 Arrcus, Inc. 2333 Email: keyur@arrcus.com 2335 Avinash Lingala 2336 AT&T 2338 Email: ar977m@att.com 2340 12. Acknowledgements 2342 Thanks to Tony Przygienda for helpful comments, and to Joel Halpern 2343 for discussions that improved this document. Yuanlong Jiang provided 2344 a useful review and caught some important issues. 2346 13. References 2348 13.1. Normative References 2350 [I-D.ietf-idr-tunnel-encaps] 2351 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 2352 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-09 2353 (work in progress), February 2018. 2355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2356 Requirement Levels", BCP 14, RFC 2119, 2357 DOI 10.17487/RFC2119, March 1997, 2358 . 2360 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2361 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2362 DOI 10.17487/RFC4271, January 2006, 2363 . 2365 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2366 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2367 2006, . 2369 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2370 "Multiprotocol Extensions for BGP-4", RFC 4760, 2371 DOI 10.17487/RFC4760, January 2007, 2372 . 2374 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 2375 and D. McPherson, "Dissemination of Flow Specification 2376 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 2377 . 2379 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2380 Writing an IANA Considerations Section in RFCs", BCP 26, 2381 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2382 . 2384 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2385 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2386 May 2017, . 2388 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 2389 "Network Service Header (NSH)", RFC 8300, 2390 DOI 10.17487/RFC8300, January 2018, 2391 . 2393 13.2. Informative References 2395 [I-D.ietf-mpls-sfc] 2396 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 2397 Forwarding Plane for Service Function Chaining", draft- 2398 ietf-mpls-sfc-01 (work in progress), May 2018. 2400 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 2401 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 2402 RFC 6790, DOI 10.17487/RFC6790, November 2012, 2403 . 2405 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 2406 Service Function Chaining", RFC 7498, 2407 DOI 10.17487/RFC7498, April 2015, 2408 . 2410 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 2411 "Encapsulating MPLS in UDP", RFC 7510, 2412 DOI 10.17487/RFC7510, April 2015, 2413 . 2415 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 2416 Chaining (SFC) Architecture", RFC 7665, 2417 DOI 10.17487/RFC7665, October 2015, 2418 . 2420 Authors' Addresses 2422 Adrian Farrel 2423 Juniper Networks 2425 Email: afarrel@juniper.net 2427 John Drake 2428 Juniper Networks 2430 Email: jdrake@juniper.net 2432 Eric Rosen 2433 Juniper Networks 2435 Email: erosen@juniper.net 2436 Jim Uttaro 2437 AT&T 2439 Email: ju1738@att.com 2441 Luay Jalil 2442 Verizon 2444 Email: luay.jalil@verizon.com