idnits 2.17.1 draft-ietf-bess-nsh-bgp-control-plane-08.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 (March 1, 2019) is 1882 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SPI' is mentioned on line 536, but not defined == Missing Reference: 'SI' is mentioned on line 536, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-11 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-sfc-05 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-sfc-encapsulation-03 ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-sfc-encapsulation (ref. 'I-D.ietf-mpls-sfc-encapsulation') ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Downref: Normative reference to an Informational RFC: RFC 7665 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group A. Farrel 3 Internet-Draft Old Dog Consulting 4 Intended status: Standards Track J. Drake 5 Expires: September 2, 2019 E. Rosen 6 Juniper Networks 7 J. Uttaro 8 AT&T 9 L. Jalil 10 Verizon 11 March 1, 2019 13 BGP Control Plane for NSH SFC 14 draft-ietf-bess-nsh-bgp-control-plane-08 16 Abstract 18 This document describes the use of BGP as a control plane for 19 networks that support Service Function Chaining (SFC). The document 20 introduces a new BGP address family called the SFC AFI/SAFI with two 21 route types. One route type is originated by a node to advertise 22 that it hosts a particular instance of a specified service function. 23 This route type also provides "instructions" on how to send a packet 24 to the hosting node in a way that indicates that the service function 25 has to be applied to the packet. The other route type is used by a 26 Controller to advertise the paths of "chains" of service functions, 27 and to give a unique designator to each such path so that they can be 28 used in conjunction with the Network Service Header defined in RFC 29 8300. 31 This document adopts the SFC architecture described in RFC 7665. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 2, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1. Overview of Service Function Chaining . . . . . . . . . . 6 72 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7 73 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 10 74 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 11 75 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 12 76 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 13 77 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13 78 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 14 79 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 19 80 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 20 81 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 20 82 4.2. Service Function Instance Routes . . . . . . . . . . . . 20 83 4.3. Service Function Path Routes . . . . . . . . . . . . . . 21 84 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 23 85 4.5. Service Function Forwarder Operation . . . . . . . . . . 23 86 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 24 87 5. Selection in Service Function Paths . . . . . . . . . . . . . 25 88 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 27 89 6.1. Protocol Control of Looping, Jumping, and Branching . . . 27 90 6.2. Implications for Forwarding State . . . . . . . . . . . . 28 91 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 29 92 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 29 93 7.2. Correlating Service Function Path Instances . . . . . . . 29 94 7.3. Considerations for Stateful Service Functions . . . . . . 30 95 7.4. VPN Considerations and Private Service Functions . . . . 31 96 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 31 97 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 33 98 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 34 99 7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 34 100 7.8. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 34 101 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35 102 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 36 103 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 37 104 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 38 105 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 38 106 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 39 107 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 39 108 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 40 109 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 41 110 8.9. Examples of SFPs with Stateful Service Functions . . . . 41 111 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 42 112 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 43 113 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 44 114 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 46 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 117 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 50 118 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 50 119 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 50 120 10.4. New SFP Association Type Registry . . . . . . . . . . . 51 121 10.5. New Service Function Type Registry . . . . . . . . . . . 51 122 10.6. New Generic Transitive Experimental Use Extended 123 Community Sub-Types . . . . . . . . . . . . . . . . . . 52 124 10.7. New BGP Transitive Extended Community Types . . . . . . 52 125 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 53 126 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 127 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 129 13.1. Normative References . . . . . . . . . . . . . . . . . . 54 130 13.2. Informative References . . . . . . . . . . . . . . . . . 55 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 133 1. Introduction 135 As described in [RFC7498], the delivery of end-to-end services can 136 require a packet to pass through a series of Service Functions (SFs) 137 (e.g., WAN and application accelerators, Deep Packet Inspection (DPI) 138 engines, firewalls, TCP optimizers, and server load balancers) in a 139 specified order: this is termed "Service Function Chaining" (SFC). 140 There are a number of issues associated with deploying and 141 maintaining service function chaining in production networks, which 142 are described below. 144 Historically, if a packet needed to travel through a particular 145 service chain, the nodes hosting the service functions of that chain 146 were placed in the network topology in such a way that the packet 147 could not reach its ultimate destination without first passing 148 through all the service functions in the proper order. This need to 149 place the service functions at particular topological locations 150 limited the ability to adapt a service function chain to changes in 151 network topology (e.g., link or node failures), network utilization, 152 or offered service load. These topological restrictions on where the 153 service functions can be placed raised the following issues: 155 1. The process of configuring or modifying a service function chain 156 is operationally complex and may require changes to the network 157 topology. 159 2. Alternate or redundant service functions may need to be co- 160 located with the primary service functions. 162 3. When there is more than one path between source and destination, 163 forwarding may be asymmetric and it may be difficult to support 164 bidirectional service function chains using simple routing 165 methodologies and protocols without adding mechanisms for traffic 166 steering or traffic engineering. 168 In order to address these issues, the SFC architecture describes 169 Service Function Chains that are built in their own overlay network 170 (the service function overlay network), coexisting with other overlay 171 networks, over a common underlay network [RFC7665]. A Service 172 Function Chain is a sequence of Service Functions through which 173 packet flows that satisfy specified criteria will pass. 175 This document describes the use of BGP as a control plane for 176 networks that support Service Function Chaining (SFC). The document 177 introduces a new BGP address family called the SFC AFI/SAFI with two 178 route types. One route type is originated by a node to advertise 179 that it hosts a particular instance of a specified service function. 180 This route type also provides "instructions" on how to send a packet 181 to the hosting node in a way that indicates that the service function 182 has to be applied to the packet. The other route type is used by a 183 Controller to advertise the paths of "chains" of service functions, 184 and to give a unique designator to each such path so that they can be 185 used in conjunction with the Network Service Header [RFC8300]. 187 This document adopts the SFC architecture described in [RFC7665]. 189 1.1. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in BCP 194 14 [RFC2119] [RFC8174] when, and only when, they appear in all 195 capitals, as shown here. 197 1.2. Terminology 199 This document uses the following terms from [RFC7665]: 201 o Bidirectional Service Function Chain 203 o Classifier 205 o Service Function (SF) 207 o Service Function Chain (SFC) 209 o Service Function Forwarder (SFF) 211 o Service Function Instance (SFI) 213 o Service Function Path (SFP) 215 o SFC branching 217 Additionally, this document uses the following terms from [RFC8300]: 219 o Network Service Header (NSH) 221 o Service Index (SI) 223 o Service Path Identifier (SPI) 225 This document introduces the following terms: 227 o Service Function Instance Route (SFIR). A new BGP Route Type 228 advertised by the node that hosts an SFI to describe the SFI and 229 to announce the way to forward a packet to the node through the 230 underlay network. 232 o Service Function Overlay Network. The logical network comprised 233 of Classifiers, SFFs, and SFIs that are connected by paths or 234 tunnels through underlay transport networks. 236 o Service Function Path Route (SFPR). A new BGP Route Type 237 originated by Controllers to advertise the details of each SFP. 239 o Service Function Type (SFT). An indication of the function and 240 features of an SFI. 242 2. Overview 244 2.1. Overview of Service Function Chaining 246 In [RFC8300] a Service Function Chain (SFC) is an ordered list of 247 Service Functions (SFs). A Service Function Path (SFP) is an 248 indication of which instances of SFs are acceptable to be traversed 249 in an instantiation of an SFC in a service function overlay network. 250 The Service Path Identifier (SPI) is a 24-bit number that identifies 251 a specific SFP, and a Service Index (SI) is an 8-bit number that 252 identifies a specific point in that path. In the context of a 253 particular SFP (identified by an SPI), an SI represents a particular 254 Service Function, and indicates the order of that SF in the SFP. 256 In fact, each SI is mapped to one or more SFs that are implemented by 257 one or more Service Function Instances (SFIs) that support those 258 specified SFs. Thus an SI may represent a choice of SFIs of one or 259 more Service Function Types. By deploying multiple SFIs for a single 260 SF, one can provide load balancing and redundancy. 262 A special functional element, called a Classifier, is located at each 263 ingress point to a service function overlay network. It assigns the 264 packets of a given packet flow to a specific Service Function Path. 265 This may be done by comparing specific fields in a packet's header 266 with local policy, which may be customer/network/service specific. 267 The classifier picks an SFP and sets the SPI accordingly, it then 268 sets the SI to the value of the SI for the first hop in the SFP, and 269 then prepends a Network Services Header (NSH) [RFC8300] containing 270 the assigned SPI/SI to that packet. Note that the Classifier and the 271 node that hosts the first Service Function in a Service Function Path 272 need not be located at the same point in the service function overlay 273 network. 275 Note that the presence of the NSH can make it difficult for nodes in 276 the underlay network to locate the fields in the original packet that 277 would normally be used to constrain equal cost multipath (ECMP) 278 forwarding. Therefore, it is recommended, as described in 279 Section 7.1, that the node prepending the NSH also provide some form 280 of entropy indicator that can be used in the underlay network. 282 The Service Function Forwarder (SFF) receives a packet from the 283 previous node in a Service Function Path, removes the packet's link 284 layer or tunnel encapsulation and hands the packet and the NSH to the 285 Service Function Instance for processing. The SFI has no knowledge 286 of the SFP. 288 When the SFF receives the packet and the NSH back from the SFI it 289 MUST select the next SFI along the path using the SPI and SI in the 290 NSH and potentially choosing between multiple SFIs (possibly of 291 different Service Function Types) as described in Section 5. In the 292 normal case the SPI remains unchanged and the SI will have been 293 decremented to indicate the next SF along the path. But other 294 possibilities exist if the SF makes other changes to the NSH through 295 a process of re-classification: 297 o The SI in the NSH may indicate: 299 * A previous SF in the path: known as "looping" (see Section 6). 301 * An SF further down the path: known as "jumping" (see also 302 Section 6). 304 o The SPI and the SI may point to an SF on a different SFP: known as 305 "branching" (see also Section 6). 307 Such modifications are limited to within the same service function 308 overlay network. That is, an SPI is known within the scope of 309 service function overlay network. Furthermore, the new SI value is 310 interpreted in the context of the SFP identified by the SPI. 312 As described in [RFC8300], an unknown or invalid SPI is treated as an 313 error and the SFF drops the packet. Such errors should be logged, 314 and such logs are subject to rate limits. 316 An SFF receiving an SI that is unknown in the context of the SPI can 317 reduce the value to the next meaningful SI value in the SFP indicated 318 by the SPI. If no such value exists or if the SFF does not support 319 this function, the SFF drops the packet and should log the event: 320 such logs are also subject to rate limits. 322 The SFF then selects an SFI that provides the SF denoted by the SPI/ 323 SI, and forwards the packet to the SFF that supports that SFI. 325 2.2. Control Plane Overview 327 To accomplish the function described in Section 2.1, this document 328 introduces the Service Function Type (SFT) that is the category of SF 329 that is supported by an SFF (such as "firewall"). An IANA registry 330 of Service Function Types is introduced in Section 10. An SFF may 331 support SFs of multiple different SFTs, and may support multiple SFIs 332 of each SF. 334 This document also introduces a new BGP AFI/SAFI (values to be 335 assigned by IANA) for "SFC Routes". Two SFC Route Types are defined 336 by this document: the Service Function Instance Route (SFIR), and the 337 Service Function Path Route (SFPR). As detailed in Section 3, the 338 route type is indicated by a sub-field in the NLRI. 340 o The SFIR is advertised by the node hosting the service function 341 instance. The SFIR describes a particular instance of a 342 particular Service Function (i.e., an SFI) and the way to forward 343 a packet to it through the underlay network, i.e., IP address and 344 encapsulation information. 346 o The SFPRs are originated by Controllers. One SFPR is originated 347 for each Service Function Path. The SFPR specifies: 349 A. the SPI of the path 351 B. the sequence of SFTs and/or SFIs of which the path consists 353 C. for each such SFT or SFI, the SI that represents it in the 354 identified path. 356 This approach assumes that there is an underlay network that provides 357 connectivity between SFFs and Controllers, and that the SFFs are 358 grouped to form one or more service function overlay networks through 359 which SFPs are built. We assume BGP connectivity between the 360 Controllers and all SFFs within each service function overlay 361 network. 363 When choosing the next SFI in a path, the SFF uses the SPI and SI as 364 well as the SFT to choose among the SFIs, applying, for example, a 365 load balancing algorithm or direct knowledge of the underlay network 366 topology as described in Section 4. 368 The SFF then encapsulates the packet using the encapsulation 369 specified by the SFIR of the selected SFI and forwards the packet. 370 See Figure 1. 372 Thus the SFF can be seen as a gateway in the underlay network through 373 which a particular SFI is reached. 375 Figure 1 shows a reference model for the SFC architecture. There are 376 four SFFs (SFF-1 through SFF-4) connected by tunnels across the 377 underlay network. Packets arrive at a Classifier and are channelled 378 along SFPs to destinations reachable through SFF-4. 380 SFF-1 and SFF-4 each have one instance of one SF attached (SFa and 381 SFe). SFF-2 has two types of SF attached: there is one instance of 382 one (SFc), and three instances of the other (SFb). SFF-3 has just 383 one instance of an SF (SFd), but it in this case the type of SFd is 384 the same type as SFb (SFTx). 386 This figure demonstrates how load balancing can be achieved. Suppose 387 an SFC needs to include SFa, an SF of type SFTx, and SFd. A number 388 of SFPs can be constructed using any instance of SFb or using SFd. 390 Packets 391 | | | 392 | | | 393 | | | 394 ------------ 395 | | 396 | Classifier | 397 | | 398 ------------ 399 | 400 | 401 ------- --------- ------- 402 | | Tunnel | | | | 403 | SFF-1 |===============| SFF-2 |=========| SFF-4 | 404 | | | | | | 405 | | -+-----+- | | 406 | | ,,,,,,,,,,,,,,/,, \ | | 407 | | ' .........../. ' ..\...... | | 408 | | ' : SFb / : ' : \ SFc : | | 409 | | ' : ---+- : ' : --+-- : | | 410 | | ' : -| SFI | : ' : | SFI | : | | 411 | | ' : -| ----- : ' : ----- : | | 412 | | ' : | ----- : ' ......... | | 413 | | ' : ----- : ' | | 414 | | ' ............. ' | |--- Dests 415 | | ' ' | |--- Dests 416 | | ' ' | | 417 | | ' ......... ' | | 418 | | ' : ----- : ' | | 419 | | ' : | SFI | : ' | | 420 | | ' : --+-- : ' | | 421 | | ' :SFd | : ' | | 422 | | ' ....|.... ' | | 423 | | ' | ' | | 424 | | ' SFTx | ' | | 425 | | ',,,,,,,,|,,,,,,,,' | | 426 | | | | | 427 | | | | | 428 | | ---+--- | | 429 | | | | | | 430 | |======| SFF-3 |====================| | 431 ---+--- | | ---+--- 432 | ------- | 434 ....|.... ....|.... 435 : | SFa: : | SFe: 436 : --+-- : : --+-- : 437 : | SFI | : : | SFI | : 438 : ----- : : ----- : 439 ......... ......... 441 Figure 1: The SFC Architecture Reference Model 443 3. BGP SFC Routes 445 This document defines a new AFI/SAFI for BGP, known as "SFC", with an 446 NLRI that is described in this section. 448 The format of the SFC NLRI is shown in Figure 2. 450 +---------------------------------------+ 451 | Route Type (2 octets) | 452 +---------------------------------------+ 453 | Length (2 octets) | 454 +---------------------------------------+ 455 | Route Type specific (variable) | 456 +---------------------------------------+ 458 Figure 2: The Format of the SFC NLRI 460 The Route Type field determines the encoding of the rest of the route 461 type specific SFC NLRI. 463 The Length field indicates the length in octets of the route type 464 specific field of the SFC NLRI. 466 This document defines the following Route Types: 468 1. Service Function Instance Route (SFIR) 470 2. Service Function Path Route (SFPR) 472 A Service Function Instance Route (SFIR) is used to identify an SFI. 473 A Service Function Path Route (SFPR) defines a sequence of Service 474 Functions (each of which has at least one instance advertised in an 475 SFIR) that form an SFP. 477 The detailed encoding and procedures for these Route Types are 478 described in subsequent sections. 480 The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol 481 Extensions [RFC4760] with an Address Family Identifier (AFI) of TBD1 482 and a Subsequent Address Family Identifier (SAFI) of TBD2. The NLRI 483 field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC 484 NLRI, encoded as specified above. 486 In order for two BGP speakers to exchange SFC NLRIs, they MUST use 487 BGP Capabilities Advertisements to ensure that they both are capable 488 of properly processing such NLRIs. This is done as specified in 489 [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI 490 of TBD1 and a SAFI of TBD2. 492 3.1. Service Function Instance Route (SFIR) 494 Figure 3 shows the Route Type specific NLRI of the SFIR. 496 +--------------------------------------------+ 497 | Route Distinguisher (RD) (8 octets) | 498 +--------------------------------------------+ 499 | Service Function Type (2 octets) | 500 +--------------------------------------------+ 502 Figure 3: SFIR Route Type specific NLRI 504 Per [RFC4364] the RD field comprises a two byte Type field and a six 505 byte Value field. Two SFIs of the same SFT MUST be associated with 506 different RDs, where the association of an SFI with an RD is 507 determined by provisioning. If two SFIRs are originated from 508 different administrative domains, they MUST have different RDs. In 509 particular, SFIRs from different VPNs (for different service function 510 overlay networks) MUST have different RDs, and those RDs MUST be 511 different from any non-VPN SFIRs. 513 The Service Function Type identifies a service function type, e.g., 514 classifier, firewall, load balancer, etc. There may be several SFIs 515 that can perform a given Service Function. Each node hosting an SFI 516 MUST originate an SFIR for each type of SF that it hosts, and it may 517 advertise an SFIR for each instance of each type of SF. The minimal 518 advertisement allows construction of valid SFPs and leaves the 519 selection of SFIs to the local SFF; the detailed advertisement may 520 have scaling concerns, but allows a Controller that constructs an SFP 521 to make an explicit choice of SFI. 523 The SFIR representing a given SFI will contain an NLRI with RD field 524 set to an RD as specified above, and with SFT field set to identify 525 that SFI's Service Function Type. The values for the SFT field are 526 taken from a registry administered by IANA (see Section 10). A BGP 527 Update containing one or more SFIRs MUST also include a Tunnel 528 Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data 529 packet needs to be sent to an SFI identified in one of the SFIRs, it 530 will be encapsulated as specified by the Tunnel Encapsulation 531 attribute, and then transmitted through the underlay network. 533 Note that the Tunnel Encapsulation attribute MUST contain sufficient 534 information to allow the advertising SFF to identify the overlay or 535 VPN network which a received packet is transiting. This is because 536 the [SPI, SI] in a received packet is specific to a particular 537 overlay or VPN network. 539 3.1.1. SFI Pool Identifier Extended Community 541 This document defines a new transitive extended community of type 542 TBD6 with Sub-Type 0x00 called the SFI Pool Identifier extended 543 community. It MAY be included in SFIR advertisements, and is used to 544 indicate the identity of a pool of SFIRs to which an SFIR belongs. 545 Since an SFIR may be a member of multiple pools, multiple of these 546 extended communities may be present on a single SFIR advertisement. 548 SFIR pools allow SFIRs to be grouped for any purpose. Possible uses 549 include control plane scalability and stability. A pool identifier 550 may be included in an SFPR to indicate a set of SFIs that are 551 acceptable at a specific point on an SFP (see Section 3.2.1.3 and 552 Section 4.3). 554 The SFI Pool Identifier extended community is encoded in 8 octets as 555 shown in Figure 4. 557 +--------------------------------------------+ 558 | Type = TBD6 (1 octet) | 559 +--------------------------------------------+ 560 | Sub-Type = 0x00 (1 octet) | 561 +--------------------------------------------+ 562 | SFI Pool Identifier Value (6 octets) | 563 +--------------------------------------------+ 565 Figure 4: The SFI Pool Identifier Extended Community 567 The SFI Pool Identifier Value is encoded in a 6 octet field in 568 network byte order, and is a globally unique value. This means that 569 pool identifiers need to be centrally managed, which is consistent 570 with the assignment of SFIs to pools. 572 3.1.2. MPLS Mixed Swapping/Stacking Extended Community 574 This document defines a new transitive extended community of type 575 TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking 576 Labels. The community is encoded as shown in Figure 5. It contains 577 a pair of MPLS labels: an SFC Context Label and an SF Label as 578 described in [I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a 579 3-octet (24 bit) field with 4 trailing bits that MUST be set to zero. 581 +--------------------------------------------+ 582 | Type = TBD7 (1 octet) | 583 +--------------------------------------------| 584 | Sub-Type = 0x00 (1 octet) | 585 +--------------------------------------------| 586 | SFC Context Label (3 octets) | 587 +--------------------------------------------| 588 | SF Label (3 octets) | 589 +--------------------------------------------+ 591 Figure 5: The MPLS Mixed Swapping/Stacking Extended Community 593 Note that it is assumed that each SFF has one or more globally unique 594 SFC Context Labels and that the context label space and the SPI 595 address space are disjoint. 597 If an SFF supports SFP Traversal with an MPLS Label Stack it MUST 598 include this extended community with the SFIRs that it advertises. 600 See Section 7.7 for a description of how this extended community is 601 used. 603 3.2. Service Function Path Route (SFPR) 605 Figure 6 shows the Route Type specific NLRI of the SFPR. 607 +-----------------------------------------------+ 608 | Route Distinguisher (RD) (8 octets) | 609 +-----------------------------------------------+ 610 | Service Path Identifier (SPI) (3 octets) | 611 +-----------------------------------------------+ 613 Figure 6: SFPR Route Type Specific NLRI 615 Per [RFC4364] the RD field comprises a two byte Type field and a six 616 byte Value field. All SFPs MUST be associated with different RDs. 617 The association of an SFP with an RD is determined by provisioning. 618 If two SFPRs are originated from different Controllers they MUST have 619 different RDs. Additionally, SFPRs from different VPNs (i.e., in 620 different service function overlay networks) MUST have different RDs, 621 and those RDs MUST be different from any non-VPN SFPRs. 623 The Service Path Identifier is defined in [RFC8300] and is the value 624 to be placed in the Service Path Identifier field of the NSH header 625 of any packet sent on this Service Function Path. It is expected 626 that one or more Controllers will originate these routes in order to 627 configure a service function overlay network. 629 The SFP is described in a new BGP Path attribute, the SFP attribute. 630 Section 3.2.1 shows the format of that attribute. 632 3.2.1. The SFP Attribute 634 [RFC4271] defines the BGP Path attribute. This document introduces a 635 new Optional Transitive Path attribute called the SFP attribute with 636 value TBD3 to be assigned by IANA. The first SFP attribute MUST be 637 processed and subsequent instances MUST be ignored. 639 The common fields of the SFP attribute are set as follows: 641 o Optional bit is set to 1 to indicate that this is an optional 642 attribute. 644 o The Transitive bit is set to 1 to indicate that this is a 645 transitive attribute. 647 o The Extended Length bit is set according to the length of the SFP 648 attribute as defined in [RFC4271]. 650 o The Attribute Type Code is set to TBD3. 652 The content of the SFP attribute is a series of Type-Length-Variable 653 (TLV) constructs. Each TLV may include sub-TLVs. All TLVs and sub- 654 TLVs have a common format that is: 656 o Type: A single octet indicating the type of the SFP attribute TLV. 657 Values are taken from the registry described in Section 10.3. 659 o Length: A two octet field indicating the length of the data 660 following the Length field counted in octets. 662 o Value: The contents of the TLV. 664 The formats of the TLVs defined in this document are shown in the 665 following sections. The presence rules and meanings are as follows. 667 o The SFP attribute contains a sequence of zero or more Association 668 TLVs. That is, the Association TLV is OPTIONAL. Each Association 669 TLV provides an association between this SFPR and another SFPR. 670 Each associated SFPR is indicated using the RD with which it is 671 advertised (we say the SFPR-RD to avoid ambiguity). 673 o The SFP attribute contains a sequence of one or more Hop TLVs. 674 Each Hop TLV contains all of the information about a single hop in 675 the SFP. 677 o Each Hop TLV contains an SI value and a sequence of one or more 678 SFT TLVs. Each SFT TLV contains an SFI reference for each 679 instance of an SF that is allowed at this hop of the SFP for the 680 specific SFT. Each SFI is indicated using the RD with which it is 681 advertised (we say the SFIR-RD to avoid ambiguity). 683 Malformed SFP attributes, or those that in error in some way, MUST be 684 handled as described in Section 6 of [RFC4271]. 686 3.2.1.1. The Association TLV 688 The Association TLV is an optional TLV in the SFP attribute. It MAY 689 be present multiple times. Each occurrence provides an association 690 with another SFP as advertised in another SFPR. The format of the 691 Association TLV is shown in Figure 7 692 +--------------------------------------------+ 693 | Type = 1 (1 octet) | 694 +--------------------------------------------| 695 | Length (2 octets) | 696 +--------------------------------------------| 697 | Association Type (1 octet) | 698 +--------------------------------------------| 699 | Associated SFPR-RD (8 octets) | 700 +--------------------------------------------| 701 | Associated SPI (3 octets) | 702 +--------------------------------------------+ 704 Figure 7: The Format of the Association TLV 706 The fields are as follows: 708 Type is set to 1 to indicate an Association TLV. 710 Length indicates the length in octets of the Association Type and 711 Associated SFPR-RD fields. The value of the Length field is 12. 713 The Association Type field indicate the type of association. The 714 values are tracked in an IANA registry (see Section 10.4). Only 715 one value is defined in this document: type 1 indicates 716 association of two unidirectional SFPs to form a bidirectional 717 SFP. An SFP attribute SHOULD NOT contain more than one 718 Association TLV with Association Type 1: if more than one is 719 present, the first one MUST be processed and subsequent instances 720 MUST be ignored. Note that documents that define new Association 721 Types must also define the presence rules for Association TLVs of 722 the new type. 724 The Associated SFPR-RD contains the RD of the associated SFP as 725 advertised in an SFPR. 727 The Associated SPI contains the SPI of the associated SFP as 728 advertised in an SFPR. 730 Association TLVs with unknown Association Type values SHOULD be 731 ignored. Association TLVs that contain an Associated SFPR-RD value 732 equal to the RD of the SFPR in which they are contained SHOULD be 733 ignored. If the Associated SPI is not equal to the SPI advertised in 734 the SFPR indicated by the Associated SFPR-RD then the Association TLV 735 SHOULD be ignored. 737 Note that when two SFPRs reference each other using the Association 738 TLV, one SFPR advertisement will be received before the other. 740 Therefore, processing of an association MUST NOT be rejected simply 741 because the Associated SFPR-RD is unknown. 743 Further discussion of correlation of SFPRs is provided in 744 Section 7.2. 746 3.2.1.2. The Hop TLV 748 There is one Hop TLV in the SFP attribute for each hop in the SFP. 749 The format of the Hop TLV is shown in Figure 8. At least one Hop TLV 750 MUST be present in an SFP attribute. 752 +--------------------------------------------+ 753 | Type = 2 (1 octet) | 754 +--------------------------------------------| 755 | Length (2 octets) | 756 +--------------------------------------------| 757 | Service Index (1 octet) | 758 +--------------------------------------------| 759 | Hop Details (variable) | 760 +--------------------------------------------+ 762 Figure 8: The Format of the Hop TLV 764 The fields are as follows: 766 Type is set to 2 to indicate a Hop TLV. 768 Length indicates the length in octets of the Service Index and Hop 769 Details fields. 771 The Service Index is defined in [RFC8300] and is the value found 772 in the Service Index field of the NSH header that an SFF will use 773 to lookup to which next SFI a packet should be sent. 775 The Hop Details field consists of a sequence of one or more sub- 776 TLVs. 778 Each hop of the SFP may demand that a specific type of SF is 779 executed, and that type is indicated in sub-TLVs of the Hop TLV. At 780 least one sub-TLV MUST be present. This provides a list of which 781 types of SF are acceptable at a specific hop, and for each type it 782 allows a degree of control to be imposed on the choice of SFIs of 783 that particular type. 785 If no Hop TLV is present in an SFP Attribute, it is a malformed 786 attribute 788 3.2.1.3. The SFT TLV 790 The SFT TLV MAY be included in the list of sub-TLVs of the Hop TLV. 791 The format of the SFT TLV is shown in Figure 9. The TLV contains a 792 list of SFIR-RD values each taken from the advertisement of an SFI. 793 Together they form a list of acceptable SFIs of the indicated type. 795 +--------------------------------------------+ 796 | Type = 3 (1 octet) | 797 +--------------------------------------------| 798 | Length (2 octets) | 799 +--------------------------------------------| 800 | Service Function Type (2 octets) | 801 +--------------------------------------------| 802 | SFIR-RD List (variable) | 803 +--------------------------------------------+ 805 Figure 9: The Format of the SFT TLV 807 The fields are as follows: 809 Type is set to 3 to indicate an SFT TLV. 811 Length indicates the length in octets of the Service Function Type 812 and SFIR-RD List fields. 814 The Service Function Type value indicates the category (type) of 815 SF that is to be executed at this hop. The types are as 816 advertised for the SFs supported by the SFFs SFT values in the 817 range 1-31 are Special Purpose SFT values and have meanings 818 defined by the documents that describe them - the value 'Change 819 Sequence' is defined in Section 6.1 of this document. 821 The hop description is further qualified beyond the specification 822 of the SFTs by listing, for each SFT in each hop, the SFIs that 823 may be used at the hop. The SFIs are identified using the SFIR- 824 RDs from the advertisements of the SFIs in the SFIRs. Note that 825 if the list contains one or more SFI Pool Identifiers, then for 826 each the SFIR-RD list is effectively expanded to include the SFIR- 827 RD of each SFIR advertised with that SFI Pool Identifier. An 828 SFIR-RD of value zero has special meaning as described in 829 Section 5. Each entry in the list is eight octets long, and the 830 number of entries in the list can be deduced from the value of the 831 Length field. 833 3.2.1.4. MPLS Swapping/Stacking TLV 835 The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub- 836 TLV that is optionally present in the Hop TLV and is used when the 837 data representation is MPLS (see Section 7.6). When present it 838 indicates to the Classifier imposing an MPLS label stack that the 839 current hop is to use an {SFC Context Label, SF label} rather than an 840 {SPI, SF} label pair. See Section 7.7 for more details. 842 3.2.1.5. SFP Traversal With MPLS Label Stack TLV 844 The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero 845 length sub-TLV that can be carried in the SFP Attribute and indicates 846 to the Classifier and the SFFs on the SFP that an MPLS labels stack 847 with label swapping/stacking is to be used for packets traversing the 848 SFP. All of the SFF specified at each the SFP's hops MUST have 849 advertised an MPLS Mixed Swapping/Stacking Extended Community (see 850 Section 3.1.2) for the SFP to be considered usable. 852 3.2.2. General Rules For The SFP Attribute 854 It is possible for the same SFI, as described by an SFIR, to be used 855 in multiple SFPRs. 857 When two SFPRs have the same SPI but different SFPR-RDs there can be 858 three cases: 860 o Two or more Controllers are originating SFPRs for the same SFP. 861 In this case the content of the SFPRs is identical and the 862 duplication is to ensure receipt and to provide Controller 863 redundancy. 865 o There is a transition in content of the advertised SFP and the 866 advertisements may originate from one or more Controllers. In 867 this case the content of the SFPRs will be different. 869 o The reuse of an SPI may result from a configuration error. 871 In all cases, there is no way for the receiving SFF to know which 872 SFPR to process, and the SFPRs could be received in any order. At 873 any point in time, when multiple SFPRs have the same SPI but 874 different SFPR-RDs, the SFF MUST use the SFPR with the numerically 875 lowest SFPR-RD. The SFF SHOULD log this occurrence to assist with 876 debugging. 878 Furthermore, a Controller that wants to change the content of an SFP 879 is RECOMMENDED to use a new SPI and so create a new SFP onto which 880 the Classifiers can transition packet flows before the SFPR for the 881 old SFP is withdrawn. This avoids any race conditions with SFPR 882 advertisements. 884 Additionally, a Controller SHOULD NOT re-use an SPI after it has 885 withdrawn the SFPR that used it until at least a configurable amount 886 of time has passed. This timer SHOULD have a default of one hour. 888 4. Mode of Operation 890 This document describes the use of BGP as a control plane to create 891 and manage a service function overlay network. 893 4.1. Route Targets 895 The main feature introduced by this document is the ability to create 896 multiple service function overlay networks through the use of Route 897 Targets (RTs) [RFC4364]. 899 Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. 900 The RT carried by a particular SFIR or SFPR is determined by the 901 provisioning of the route's originator. 903 Every node in a service function overlay network is configured with 904 one or more import RTs. Thus, each SFF will import only the SFPRs 905 with matching RTs allowing the construction of multiple service 906 function overlay networks or the instantiation of Service Function 907 Chains within an L3VPN or EVPN instance (see Section 7.4). An SFF 908 that has a presence in multiple service function overlay networks 909 (i.e., imports more than one RT) may find it helpful to maintain 910 separate forwarding state for each overlay network. 912 4.2. Service Function Instance Routes 914 The SFIR (see Section 3.1) is used to advertise the existence and 915 location of a specific Service Function Instance and consists of: 917 o The RT as just described. 919 o A Service Function Type (SFT) that is the type of service function 920 that is provided (such as "firewall"). 922 o A Route Distinguisher (RD) that is unique to a specific instance 923 of a service function. 925 4.3. Service Function Path Routes 927 The SFPR (see Section 3.2) describes a specific path of a Service 928 Function Chain. The SFPR contains the Service Path Identifier (SPI) 929 used to identify the SFP in the NSH in the data plane. It also 930 contains a sequence of Service Indexes (SIs). Each SI identifies a 931 hop in the SFP, and each hop is a choice between one of more SFIs. 933 As described in this document, each Service Function Path Route is 934 identified in the service function overlay network by an RD and an 935 SPI. The SPI is unique within a single VPN instance supported by the 936 underlay network. 938 The SFPR advertisement comprises: 940 o An RT as described in Section 4.1. 942 o A tuple that identifies the SFPR 944 * An RD that identifies an advertisement of an SFPR. 946 * The SPI that uniquely identifies this path within the VPN 947 instance distinguished by the RD. This SPI also appears in the 948 NSH. 950 o A series of Service Indexes. Each SI is used in the context of a 951 particular SPI and identifies one or more SFs (distinguished by 952 their SFTs) and for each SF a set of SFIs that instantiate the SF. 953 The values of the SI indicate the order in which the SFs are to be 954 executed in the SFP that is represented by the SPI. 956 o The SI is used in the NSH to identify the entries in the SFP. 957 Note that the SI values have meaning only relative to a specific 958 path. They have no semantic other than to indicate the order of 959 Service Functions within the path and are assumed to be 960 monotonically decreasing from the start to the end of the path 961 [RFC8300]. 963 o Each Service Index is associated with a set of one or more Service 964 Function Instances that can be used to provide the indexed Service 965 Function within the path. Each member of the set comprises: 967 * The RD used in an SFIR advertisement of the SFI. 969 * The SFT that indicates the type of function as used in the same 970 SFIR advertisement of the SFI. 972 This may be summarized as follows where the notations "SFPR-RD" and 973 "SFIR-RD" are used to distinguish the two different RDs: 975 RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } } 977 Where: 979 RT: Route Target 981 SFPR-RD: The Route Descriptor of the Service Function Path Route 982 advertisement 984 SPI: Service Path Identifier used in the NSH 986 m: The number of hops in the Service Function Path 988 n: The number of choices of Service Function Type for a specific 989 hop 991 p: The number of choices of Service Function Instance for given 992 Service Function Type in a specific hop 994 SI: Service Index used in the NSH to indicate a specific hop 996 SFT: The Service Function Type used in the same advertisement of 997 the Service Function Instance Route 999 SFIR-RD: The Route Descriptor used in an advertisement of the 1000 Service Function Instance Route 1002 Note that the values of SI are from the set {255, ..., 1} and are 1003 monotonically decreasing within the SFP. SIs MUST appear in order 1004 within the SFPR (i.e., monotonically decreasing) and MUST NOT appear 1005 more than once. Gaps MAY appear in the sequence as described in 1006 Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any 1007 previous instance of the SFPR (same SFPR-RD and SPI) to be discarded. 1009 Note that if the SFIR-RD list in an SFT TLV contains one or more SFI 1010 Pool identifiers, then in the above expression, 'p' is the sum of the 1011 number of individual SFIR-RD values and the sum for each SFI Pool 1012 Identifier of the number of SFIRs advertised with that SFI Pool 1013 Identifier. I.e., the list of SFIR-RD values is effectively expanded 1014 to include the SFIR-RD of each SFIR advertised with each SFI Pool 1015 Identifier in the SFIR-RD list. 1017 The choice of SFI is explained further in Section 5. Note that an 1018 SFIR-RD value of zero has special meaning as described in that 1019 Section. 1021 4.4. Classifier Operation 1023 As shown in Figure 1, the Classifier is a component that is used to 1024 assign packets to an SFP. 1026 The Classifier is responsible for determining to which packet flow a 1027 packet belongs (usually by inspecting the packet header), imposing an 1028 NSH, and initializing the NSH with the SPI of the selected SFP and 1029 the SI of its first hop. 1031 The Classifier may also provide an entropy indicator as described in 1032 Section 7.1. 1034 4.5. Service Function Forwarder Operation 1036 Each packet sent to an SFF is transmitted encapsulated in an NSH. 1037 The NSH includes an SPI and SI: the SPI indicates the SFPR 1038 advertisement that announced the Service Function Path; the tuple 1039 SPI/SI indicates a specific hop in a specific path and maps to the 1040 RD/SFT of a particular SFIR advertisement. 1042 When an SFF gets an SFPR advertisement it will first determine 1043 whether to import the route by examining the RT. If the SFPR is 1044 imported the SFF then determines whether it is on the SFP by looking 1045 for its own SFIR-RDs in the SFPR. For each occurrence in the SFP, 1046 the SFF creates forwarding state for incoming packets and forwarding 1047 state for outgoing packets that have been processed by the specified 1048 SFI. 1050 The SFF creates local forwarding state for packets that it receives 1051 from other SFFs. This state makes the association between the SPI/SI 1052 in the NSH of the received packet and one or more specific local SFIs 1053 as identified by the SFIR-RD/SFT. If there are multiple local SFIs 1054 that match this is because a single advertisement was made for a set 1055 of equivalent SFIs and the SFF may use local policy (such as load 1056 balancing) to determine to which SFI to forward a received packet. 1058 The SFF also creates next hop forwarding state for packets received 1059 back from the local SFI that need to be forwarded to the next hop in 1060 the SFP. There may be a choice of next hops as described in 1061 Section 4.3. The SFF could install forwarding state for all 1062 potential next hops, or it could choose to only install forwarding 1063 state to a subset of the potential next hops. If a choice is made 1064 then it will be as described in Section 5. 1066 The installed forwarding state may change over time reacting to 1067 changes in the underlay network and the availability of particular 1068 SFIs. 1070 Note that SFFs only create and store forwarding state for the SFPs on 1071 which they are included. They do not retain state for all SFPs 1072 advertised. 1074 An SFF may also install forwarding state to support looping, jumping, 1075 and branching. The protocol mechanism for explicit control of 1076 looping, jumping, and branching uses a specific reserved SFT value at 1077 a given hop of an SFPR and is described in Section 6.1. 1079 4.5.1. Processing With 'Gaps' in the SI Sequence 1081 The behavior of an SF as described in [RFC8300] is to decrement the 1082 value of the SI field in the NSH by one before returning a packet to 1083 the local SFF for further processing. This means that there is a 1084 good reason to assume that the SFP is composed of a series of SFs 1085 each indicated by an SI value one less than the previous. 1087 However, there is an advantage to having non-successive SIs in an 1088 SPI. Consider the case where an SPI needs to be modified by the 1089 insertion or removal of an SF. In the latter case this would lead to 1090 a "gap" in the sequence of SIs, and in the former case, this could 1091 only be achieved if a gap already existed into which the new SF with 1092 its new SI value could be inserted. Otherwise, all "downstream" SFs 1093 would need to be renumbered. 1095 Now, of course, such renumbering could be performed, but would lead 1096 to a significant disruption to the SFC as all the SFFs along the SFP 1097 were "reprogrammed". Thus, to achieve dynamic modification of an SFP 1098 (and even, in-service modification) it is desirable to be able to 1099 make these modifications without changing the SIs of the elements 1100 that were present before the modification. This will produce much 1101 more consistent/predictable behavior during the convergence period 1102 where otherwise the change would need to be fully propagated. 1104 Another approach says that any change to an SFP simply creates a new 1105 SFP that can be assigned a new SPI. All that would be needed would 1106 be to give a new instruction to the Classifier and traffic would be 1107 switched to the new SFP that contains the new set of SFs. This 1108 approach is practical, but neglects to consider that the SFP may be 1109 referenced by other SFPs (through "branch" instructions) and used by 1110 many Classifiers. In those cases the corresponding configuration 1111 resulting from a change in SPI may have wide ripples and give scope 1112 for errors that are hard to trace. 1114 Therefore, while this document requires that the SI values in an SFP 1115 are monotonic decreasing, it makes no assumption that the SI values 1116 are sequential. Configuration tools may apply that rule, but they 1117 are not required to. To support this, an SFF SHOULD process as 1118 follows when it receives a packet: 1120 o If the SI indicates a known entry in the SFP, the SFF MUST process 1121 the packet as normal, looking up the SI and determining to which 1122 local SFI to deliver the packet. 1124 o If the SI does not match an entry in the SFP, the SFF MUST reduce 1125 the SI value to the next (smaller) value present in the SFP and 1126 process the packet using that SI. 1128 o If there is no smaller SI (i.e., if the end of the SFP has been 1129 reached) the SFF MUST treat the SI value as invalid as described 1130 in [RFC8300]. 1132 SFF implementations MAY choose to only support contiguous SI values 1133 in an SFP. Such an implementation will not support receiving an SI 1134 value that is not present in the SFP and will discard the packets as 1135 described in [RFC8300]. 1137 5. Selection in Service Function Paths 1139 As described in Section 2 the SPI/SI in the NSH passed back from an 1140 SFI to the SFF may leave the SFF with a choice of next hop SFTs, and 1141 a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, 1142 and the SI indicates an entry in that SFPR. Each entry in an SFPR is 1143 a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of 1144 these, identify the SFF that supports the chosen SFI, and send the 1145 packet to that next hop SFF. 1147 The choice may offered for load balancing across multiple SFIs, or 1148 for discrimination between different actions necessary at a specific 1149 hop in the SFP. Different SFT values may exist at a given hop in an 1150 SFP to support several cases: 1152 o There may be multiple instances of similar service functions that 1153 are distinguished by different SFT values. For example, firewalls 1154 made by vendor A and vendor B may need to be identified by 1155 different SFT values because, while they have similar 1156 functionality, their behavior is not identical. Then, some SFPs 1157 may limit the choice of SF at a given hop by specifying the SFT 1158 for vendor A, but other SFPs might not need to control which 1159 vendor's SF is used and so can indicate that either SFT can be 1160 used. 1162 o There may be an obvious branch needed in an SFP such as the 1163 processing after a firewall where admitted packets continue along 1164 the SFP, but suspect packets are diverted to a "penalty box". In 1165 this case, the next hop in the SFP will be indicated with two 1166 different SFT values. 1168 In the typical case, the SFF chooses a next hop SFF by looking at the 1169 set of all SFFs that support the SFs identified by the SI (that set 1170 having been advertised in individual SFIR advertisements), finding 1171 the one or more that are "nearest" in the underlay network, and 1172 choosing between next hop SFFs using its own load-balancing 1173 algorithm. 1175 An SFI may influence this choice process by passing additional 1176 information back along with the packet and NSH. This information may 1177 influence local policy at the SFF to cause it to favor a next hop SFF 1178 (perhaps selecting one that is not nearest in the underlay), or to 1179 influence the load-balancing algorithm. 1181 This selection applies to the normal case, but also applies in the 1182 case of looping, jumping, and branching (see Section 6). 1184 Suppose an SFF in a particular service overlay network (identified by 1185 a particular import RT, RT-z) needs to forward an NSH-encapsulated 1186 packet whose SPI is SPI-x and whose SI is SI-y. It does the 1187 following: 1189 1. It looks for an installed SFPR that carries RT-z and that has 1190 SPI-x in its NLRI. If there is none, then such packets cannot be 1191 forwarded. 1193 2. From the SFP attribute of that SFPR, it finds the Hop TLV with SI 1194 value set to SI-y. If there is no such Hop TLV, then such 1195 packets cannot be forwarded. 1197 3. It then finds the "relevant" set of SFIRs by going through the 1198 list of SFT TLVs contained in the Hop TLV as follows: 1200 A. An SFIR is relevant if it carries RT-z, the SFT in its NLRI 1201 matches the SFT value in one of the SFT TLVs, and the RD 1202 value in its NLRI matches an entry in the list of SFIR-RDs in 1203 that SFT TLV. 1205 B. If an entry in the SFIR-RD list of an SFT TLV contains the 1206 value zero, then an SFIR is relevant if it carries RT-z and 1207 the SFT in its NLRI matches the SFT value in that SFT TLV. 1208 I.e., any SFIR in the service function overlay network 1209 defined by RT-z and with the correct SFT is relevant. 1211 Each of the relevant SFIRs identifies a single SFI, and contains a 1212 Tunnel Encapsulation attribute that specifies how to send a packet to 1213 that SFI. For a particular packet, the SFF chooses a particular SFI 1214 from the set of relevant SFIRs. This choice is made according to 1215 local policy. 1217 A typical policy might be to figure out the set of SFIs that are 1218 closest, and to load balance among them. But this is not the only 1219 possible policy. 1221 6. Looping, Jumping, and Branching 1223 As described in Section 2 an SFI or an SFF may cause a packet to 1224 "loop back" to a previous SF on a path in order that a sequence of 1225 functions may be re-executed. This is simply achieved by replacing 1226 the SI in the NSH with a higher value instead of decreasing it as 1227 would normally be the case to determine the next hop in the path. 1229 Section 2 also describes how an SFI or an SFF may cause a packets to 1230 "jump forward" to an SF on a path that is not the immediate next SF 1231 in the SFP. This is simply achieved by replacing the SI in the NSH 1232 with a lower value than would be achieved by decreasing it by the 1233 normal amount. 1235 A more complex option to move packets from one SFP to another is 1236 described in [RFC8300] and Section 2 where it is termed "branching". 1237 This mechanism allows an SFI or SFF to make a choice of downstream 1238 treatments for packets based on local policy and output of the local 1239 SF. Branching is achieved by changing the SPI in the NSH to indicate 1240 the new path and setting the SI to indicate the point in the path at 1241 which the packets should enter. 1243 Note that the NSH does not include a marker to indicate whether a 1244 specific packet has been around a loop before. Therefore, the use of 1245 NSH metadata may be required in order to prevent infinite loops. 1247 6.1. Protocol Control of Looping, Jumping, and Branching 1249 If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT 1250 value "Change Sequence" (see Section 10) then this is an indication 1251 that the SFF may make a loop, jump, or branch according to local 1252 policy and information returned by the local SFI. 1254 In this case, the SPI and SI of the next hop is encoded in the eight 1255 bytes of an entry in the SFIR-RD list as follows: 1257 3 bytes SPI 1259 2 bytes SI 1260 3 bytes Reserved (SHOULD be set to zero and ignored) 1262 If the SI in this encoding is not part of the SFPR indicated by the 1263 SPI in this encoding, then this is an explicit error that SHOULD be 1264 detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT 1265 cause any forwarding state to be installed in the SFF and packets 1266 received with the SPI that indicates this SFPR SHOULD be silently 1267 discarded. 1269 If the SPI in this encoding is unknown, the SFF SHOULD NOT install 1270 any forwarding state for this SFPR, but MAY hold the SFPR pending 1271 receipt of another SFPR that does use the encoded SPI. 1273 If the SPI matches the current SPI for the path, this is a loop or 1274 jump. In this case, if the SI is greater than to the current SI it 1275 is a loop. If the SPI matches and the SI is less than the next SI, 1276 it is a jump. 1278 If the SPI indicates anther path, this is a branch and the SI 1279 indicates the point at which to enter that path. 1281 The Change Sequence SFT is just another SFT that may appear in a set 1282 of SFI/SFT tuples within an SI and is selected as described in 1283 Section 5. 1285 Note that Special Purpose SFTs MUST NOT be advertised in SFIRs. 1287 6.2. Implications for Forwarding State 1289 Support for looping and jumping requires that the SFF has forwarding 1290 state established to an SFF that provides access to an instance of 1291 the appropriate SF. This means that the SFF must have seen the 1292 relevant SFIR advertisements and known that it needed to create the 1293 forwarding state. This is a matter of local configuration and 1294 implementation: for example, an implementation could be configured to 1295 install forwarding state for specific looping/jumping. 1297 Support for branching requires that the SFF has forwarding state 1298 established to an SFF that provides access to an instance of the 1299 appropriate entry SF on the other SFP. This means that the SFF must 1300 have seen the relevant SFIR and SFPR advertisements and known that it 1301 needed to create the forwarding state. This is a matter of local 1302 configuration and implementation: for example, an implementation 1303 could be configured to install forwarding state for specific 1304 branching (identified by SPI and SI). 1306 7. Advanced Topics 1308 This section highlights several advanced topics introduced elsewhere 1309 in this document. 1311 7.1. Preserving Entropy 1313 Forwarding decisions in the underlay network in the presence of equal 1314 cost multipath (ECMP) are usually made by inspecting key invariant 1315 fields in a packet header so that all packets from the same packet 1316 flow receive the same forwarding treatment. However, when an NSH is 1317 included in a packet, those key fields may be inaccessible. For 1318 example, the fields may be too far inside the packet for a forwarding 1319 engine to quickly find them and extract their values, or the node 1320 performing the examination may be unaware of the format and meaning 1321 of the NSH and so unable to parse far enough into the packet. 1323 Various mechanisms exist within forwarding technologies to include an 1324 "entropy indicator" within a forwarded packet. For example, in MPLS 1325 there is the entropy label [RFC6790], while for encapsulations in UDP 1326 the source port field is often used to carry an entropy indicator 1327 (such as for MPLS in UDP [RFC7510]). 1329 Implementations of this specification are RECOMMENDED to include an 1330 entropy indicator within the packet's underlay network header, and 1331 SHOULD preserve any entropy indicator from a received packet for use 1332 on the same packet when it is forwarded along the path but MAY choose 1333 to generate a new entropy indicator so long as the method used is 1334 constant for all packets. Note that preserving per packet entropy 1335 may require that the entropy indicator is passed to and returned by 1336 the SFI to prevent the SFF from having to maintain per-packet state. 1338 7.2. Correlating Service Function Path Instances 1340 It is often useful to create bidirectional SFPs to enable packet 1341 flows to traverse the same set of SFs, but in the reverse order. 1342 However, packets on SFPs in the data plane (per [RFC8300]) do not 1343 contain a direction indicator, so each direction must use a different 1344 SPI. 1346 As described in Section 3.2.1.1 an SFPR can contain one or more 1347 correlators encoded in Association TLVs. If the Association Type 1348 indicates "Bidirectional SFP" then the SFP advertised in the SFPR is 1349 one direction of a bidirectional pair of SFPs where the other in the 1350 pair is advertised in the SFPR with RD as carried in the Associated 1351 SFPR-RD field of the Association TLV. The SPI carried in the 1352 Associated SPI field of the Association TLV provides a cross-check 1353 and should match the SPI advertised in the SFPR with RD as carried in 1354 the Associated SFPR-RD field of the Association TLV. 1356 As noted in Section 3.2.1.1 SFPRs reference each other one SFPR 1357 advertisement will be received before the other. Therefore 1358 processing of an association will require that the first SFPR is not 1359 rejected simply because the Associated SFPR-RD it carries is unknown. 1360 However, the SFP defined by the first SFPR is valid and SHOULD be 1361 available for use as a unidirectional SFP even in the absence of an 1362 advertisement of its partner. 1364 Furthermore, in error cases where SFPR-a associates with SFPR-b, but 1365 SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs 1366 cannot be formed, the individual SFPs are still valid and SHOULD be 1367 available for use as unidirectional SFPs. An implementation SHOULD 1368 log this situation because it represents a Controller error. 1370 Usage of a bidirectional SFP may be programmed into the Classifiers 1371 by the Controller. Alternatively, a Classifier may look at incoming 1372 packets on a bidirectional packet flow, extract the SPI from the 1373 received NSH, and look up the SFPR to find the reverse direction SFP 1374 to use when it sends packets. 1376 See Section 8 for an example of how this works. 1378 7.3. Considerations for Stateful Service Functions 1380 Some service functions are stateful. That means that they build and 1381 maintain state derived from configuration or from the packet flows 1382 that they handle. In such cases it can be important or necessary 1383 that all packets from a flow continue to traverse the same instance 1384 of a service function so that the state can be leveraged and does not 1385 need to be regenerated. 1387 In the case of bidirectional SFPs, it may be necessary to traverse 1388 the same instances of a stateful service function in both directions. 1389 A firewall is a good example of such a service function. 1391 This issue becomes a concern where there are multiple parallel 1392 instances of a service function and a determination of which one to 1393 use could normally be left to the SFF as a load-balancing or local 1394 policy choice. 1396 For the forward direction SFP, the concern is that the same choice of 1397 service function is made for all packets of a flow under normal 1398 network conditions. It may be possible to guarantee that the load 1399 balancing functions applied in the SFFs are stable and repeatable, 1400 but a controller that constructs SFPs might not want to trust to 1401 this. The controller can, in these cases, build a number of more 1402 specific SFPs each traversing a specific instance of the stateful 1403 SFs. In this case, the load balancing choice can be left up to the 1404 Classifier. Thus the Classifier selects which instance of a stateful 1405 SF is used by a particular flow by selecting the SFP that the flow 1406 uses. 1408 For bidirectional SFPs where the same instance of a stateful SF must 1409 be traversed in both directions, it is not enough to leave the choice 1410 of service function instance as a local choice even if the load 1411 balancing is stable because coordination would be required between 1412 the decision points in the forward and reverse directions and this 1413 may be hard to achieve in all cases except where it is the same SFF 1414 that makes the choice in both directions. 1416 Note that this approach necessarily increases the amount of SFP state 1417 in the network (i.e., there are more SFPs). It is possible to 1418 mitigate this effect by careful construction of SFPs built from a 1419 concatenation of other SFPs. 1421 Section 8.9 includes some simple examples of SFPs for stateful 1422 service functions. 1424 7.4. VPN Considerations and Private Service Functions 1426 Likely deployments include reserving specific instances of Service 1427 Functions for specific customers or allowing customers to deploy 1428 their own Service Functions within the network. Building Service 1429 Functions in such environments requires that suitable identifiers are 1430 used to ensure that SFFs distinguish which SFIs can be used and which 1431 cannot. 1433 This problem is similar to how VPNs are supported and is solved in a 1434 similar way. The RT field is used to indicate a set of Service 1435 Functions from which all choices must be made. 1437 7.5. Flow Spec for SFC Classifiers 1439 [RFC5575] defines a set of BGP routes that can be used to identify 1440 the packets in a given flow using fields in the header of each 1441 packet, and a set of actions, encoded as extended communities, that 1442 can be used to disposition those packets. This document enables the 1443 use of RFC 5575 mechanisms by SFC Classifiers by defining a new 1444 action extended community called "Flow Spec for SFC classifiers" 1445 identified by the value TBD4. Note that other action extended 1446 communities may also be present. 1448 This extended community is encoded as an 8-octet value, as shown in 1449 Figure 10: 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Type=0x80 | Sub-Type=TBD4 | SPI | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | SPI (cont.) | SI | SFT | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 Figure 10: The Format of the Flow Spec for SFC Classifiers Extended 1459 Community 1461 The extended community contains the Service Path Identifier (SPI), 1462 Service Index (SI), and Service Function Type (SFT) as defined 1463 elsewhere in this document. Thus, each action extended community 1464 defines the entry point (not necessarily the first hop) into a 1465 specific service function path. This allows, for example, different 1466 flows to enter the same service function path at different points. 1468 Note that a given Flow Spec update according to [RFC5575] may include 1469 multiple of these action extended communities, and that if a given 1470 action extended community does not contain an installed SFPR with the 1471 specified {SPI, SI, SFT} it MUST NOT be used for dispositioning the 1472 packets of the specified flow. 1474 The normal case of packet classification for SFC will see a packet 1475 enter the SFP at its first hop. In this case the SI in the extended 1476 community is superfluous and the SFT may also be unnecessary. To 1477 allow these cases to be handled, a special meaning is assigned to a 1478 Service Index of zero (not a valid value) and an SFT of zero (a 1479 reserved value in the registry - see Section 10.5). 1481 o If an SFC Classifiers Extended Community is received with SI = 0 1482 then it means that the first hop of the SFP indicated by the SPI 1483 MUST be used. 1485 o If an SFC Classifiers Extended Community is received with SFT = 0 1486 then there are two sub-cases: 1488 * If there is a choice of SFT in the hop indicated by the value 1489 of the SI (including SI = 0) then SFT = 0 means there is a free 1490 choice according to local policy of which SFT to use). 1492 * If there is no choice of SFT in the hop indicated by the value 1493 of SI, then SFT = 0 means that the value of the SFT at that hop 1494 as indicated in the SPFR for the indicated SPI MUST be used. 1496 Note that each FlowSpec update MUST be tagged with the route target 1497 of the overlay or VPN network for which it is intended. 1499 7.6. Choice of Data Plane SPI/SI Representation 1501 This document ties together the control and data planes of an SFC 1502 overlay network through the use of the SPI/SI which is nominally 1503 carried in the NSH of a given packet. However, in order to handle 1504 situations in which the NSH is not ubiquitously deployed, it is also 1505 possible to use alternative data plane representations of the SPI/SI 1506 by carrying the identical semantics in other protocol fields such as 1507 MPLS labels [I-D.ietf-mpls-sfc]. 1509 This document defines a new sub-TLV for the Tunnel Encapsulation 1510 attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub- 1511 TLV MAY be present in each Tunnel TLV contained in a Tunnel 1512 Encapsulation attribute when the attribute is carried by an SFIR. 1513 The value field of this sub-TLV is a two octet field of flags, each 1514 of which describes how the originating SFF expects to see the SPI/SI 1515 represented in the data plane for packets carried in the tunnels 1516 described by the Tunnel TLV. 1518 The following bits are defined by this document: 1520 Bit 0: If this bit is set the NSH is to be used to carry the SPI/SI 1521 in the data plane. 1523 Bit 1: If this bit is set two labels in an MPLS label stack are to 1524 be used as described in Section 7.6.1. 1526 If a given Tunnel TLV does not contain an SPI/SI Representation sub- 1527 TLV then it MUST be processed as if such a sub-TLV is present with 1528 Bit 0 set and no other bits set. That is, the absence of the sub-TLV 1529 SHALL be interpreted to mean that the NSH is to be used. 1531 If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with 1532 value field that has no flag set then the tunnel indicated by the 1533 Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given 1534 Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit 0 1535 and bit 1 set then the tunnel indicated by the Tunnel TLV MUST NOT be 1536 used for forwarding SFC packets. The meaning and rules for presence 1537 of other bits is to be defined in future documents, but 1538 implementations of this specification MUST set other bits to zero and 1539 ignore them on receipt. 1541 If a given Tunnel TLV contains more than one SPI/SI Representation 1542 sub-TLV then the first one MUST be considered and subsequent 1543 instances MUST be ignored. 1545 Note that the MPLS representation of the logical NSH may be used even 1546 if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be 1547 used to carry other encodings of the logical NSH (specifically, the 1548 NSH itself). It is a requirement that both ends of a tunnel over the 1549 underlay network know that the tunnel is used for SFC and know what 1550 form of NSH representation is used. The signaling mechanism 1551 described here allows coordination of this information. 1553 7.6.1. MPLS Representation of the SPI/SI 1555 If bit 1 is set in the in the SPI/SI Representation sub-TLV then 1556 labels in the MPLS label stack are used to indicate SFC forwarding 1557 and processing instructions to achieve the semantics of a logical 1558 NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc]. 1560 7.7. MPLS Label Swapping/Stacking Operation 1562 When a classifier constructs an MPLS label stack for an SFP it starts 1563 with that SFP' last hop. If the last hop requires an {SPI, SI} label 1564 pair for label swapping, it pushes the SI (set to the SI value of the 1565 last hop) and the SFP's SPI onto the MPLS label stack. If the last 1566 hop requires a {context label, SFI label} label pair for label 1567 stacking it selects a specific SFIR and pushes that SFIR's SFI label 1568 and context label onto the MPLS label stack. 1570 The classifier then moves sequentially back through the SFP one hop 1571 at a time. For each hop, if the hop requires an {SPI, SI]} and there 1572 is an {SPI, SI} at the top of the MPLS label stack, the SI is set to 1573 the SI value of the current hop. If there is not an {SPI, SI} at the 1574 top of the MPLS label stack, it pushes the SI (set to the SI value of 1575 the current hop) and the SFP's SPI onto the MPLS label stack. 1577 If the hop requires a {context label, SFI label}, it selects a 1578 specific SFIR and pushes that SFIR's SFI label and context label onto 1579 the MPLS label stack. 1581 7.8. Support for MPLS-Encapsulated NSH Packets 1583 [I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC 1584 packets using the NSH over an MPLS transport network. Signaling MPLS 1585 encapsulation of SFC packets using the NSH is also supported by this 1586 document by using the "BGP Tunnel Encapsulation Attribute Sub-TLV" 1587 with the codepoint 10 (representing "MPLS Label Stack") from the "BGP 1588 Tunnel Encapsulation Attribute Sub-TLVs" registry defined in 1590 [I-D.ietf-idr-tunnel-encaps], and also using the "SFP Traversal With 1591 MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" with 1592 bit 0 set and bit 1 cleared. 1594 In this case the MPLS label stack constructed by the SFF to forward a 1595 packet to the next SFF on the SFP will consist of the labels needed 1596 to reach that SFF, and if label stacking is used it will also include 1597 the labels advertised in the MPLS Label Stack sub-TLV and the labels 1598 remaining in the stack needed to traverse the remainder of the SFP. 1600 8. Examples 1602 Assume we have a service function overlay network with four SFFs 1603 (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the 1604 underlay network as follows: 1606 SFF1 192.0.2.1 1607 SFF2 192.0.2.2 1608 SFF3 192.0.2.3 1609 SFF4 192.0.2.4 1611 Each SFF provides access to some SFIs from the four Service Function 1612 Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows: 1614 SFF1 SFT=41 and SFT=42 1615 SFF2 SFT=41 and SFT=43 1616 SFF3 SFT=42 and SFT=44 1617 SFF4 SFT=43 and SFT=44 1619 The service function network also contains a Controller with address 1620 198.51.100.1. 1622 This example service function overlay network is shown in Figure 11. 1624 -------------- 1625 | Controller | 1626 | 198.51.100.1 | ------ ------ ------ ------ 1627 -------------- | SFI | | SFI | | SFI | | SFI | 1628 |SFT=41| |SFT=42| |SFT=41| |SFT=43| 1629 ------ ------ ------ ------ 1630 \ / \ / 1631 --------- --------- 1632 ---------- | SFF1 | | SFF2 | 1633 Packet --> | | |192.0.2.1| |192.0.2.2| 1634 Flows --> |Classifier| --------- --------- -->Dest 1635 | | --> 1636 ---------- --------- --------- 1637 | SFF3 | | SFF4 | 1638 |192.0.2.3| |192.0.2.4| 1639 --------- --------- 1640 / \ / \ 1641 ------ ------ ------ ------ 1642 | SFI | | SFI | | SFI | | SFI | 1643 |SFT=42| |SFT=44| |SFT=43| |SFT=44| 1644 ------ ------ ------ ------ 1646 Figure 11: Example Service Function Overlay Network 1648 The SFFs advertise routes to the SFIs they support. So we see the 1649 following SFIRs: 1651 RD = 192.0.2.1,1, SFT = 41 1652 RD = 192.0.2.1,2, SFT = 42 1653 RD = 192.0.2.2,1, SFT = 41 1654 RD = 192.0.2.2,2, SFT = 43 1655 RD = 192.0.2.3,7, SFT = 42 1656 RD = 192.0.2.3,8, SFT = 44 1657 RD = 192.0.2.4,5, SFT = 43 1658 RD = 192.0.2.4,6, SFT = 44 1660 Note that the addressing used for communicating between SFFs is taken 1661 from the Tunnel Encapsulation attribute of the SFIR and not from the 1662 SFIR-RD. 1664 8.1. Example Explicit SFP With No Choices 1666 Consider the following SFPR. 1668 SFP1: RD = 198.51.100.1,101, SPI = 15, 1669 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1670 [SI = 250, SFT = 43, RD = 192.0.2.2,2] 1672 The Service Function Path consists of an SF of type 41 located at 1673 SFF1 followed by an SF of type 43 located at SFF2. This path is 1674 fully explicit and each SFF is offered no choice in forwarding packet 1675 along the path. 1677 SFF1 will receive packets on the path from the Classifier and will 1678 identify the path from the SPI (15). The initial SI will be 255 and 1679 so SFF1 will deliver the packets to the SFI for SFT 41. 1681 When the packets are returned to SFF1 by the SFI the SI will be 1682 decreased to 250 for the next hop. SFF1 has no flexibility in the 1683 choice of SFF to support the next hop SFI and will forward the packet 1684 to SFF2 which will send the packets to the SFI that supports SFT 43 1685 before forwarding the packets to their destinations. 1687 8.2. Example SFP With Choice of SFIs 1689 SFP2: RD = 198.51.100.1,102, SPI = 16, 1690 [SI = 255, SFT = 41, RD = 192.0.2.1,], 1691 [SI = 250, SFT = 43, {RD = 192.0.2.2,2, 1692 RD = 192.0.2.4,5 } ] 1694 In this example the path also consists of an SF of type 41 located at 1695 SFF1 and this is followed by an SF of type 43, but in this case the 1696 SI = 250 contains a choice between the SFI located at SFF2 and the 1697 SFI located at SFF4. 1699 SFF1 will receive packets on the path from the Classifier and will 1700 identify the path from the SPI (16). The initial SI will be 255 and 1701 so SFF1 will deliver the packets to the SFI for SFT 41. 1703 When the packets are returned to SFF1 by the SFI the SI will be 1704 decreased to 250 for the next hop. SFF1 now has a choice of next hop 1705 SFF to execute the next hop in the path. It can either forward 1706 packets to SFF2 or SFF4 to execute a function of type 43. It uses 1707 its local load balancing algorithm to make this choice. The chosen 1708 SFF will send the packets to the SFI that supports SFT 43 before 1709 forwarding the packets to their destinations. 1711 8.3. Example SFP With Open Choice of SFIs 1713 SFP3: RD = 198.51.100.1,103, SPI = 17, 1714 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1715 [SI = 250, SFT = 44, RD = 0] 1717 In this example the path also consists of an SF of type 41 located at 1718 SFF1 and this is followed by an SI with an RD of zero and SF of type 1719 44. This means that a choice can be made between any SFF that 1720 supports an SFI of type 44. 1722 SFF1 will receive packets on the path from the Classifier and will 1723 identify the path from the SPI (17). The initial SI will be 255 and 1724 so SFF1 will deliver the packets to the SFI for SFT 41. 1726 When the packets are returned to SFF1 by the SFI the SI will be 1727 decreased to 250 for the next hop. SFF1 now has a free choice of 1728 next hop SFF to execute the next hop in the path selecting between 1729 all SFFs that support SFs of type 44. Looking at the SFIRs it has 1730 received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. 1731 SFF1 uses its local load balancing algorithm to make this choice. 1732 The chosen SFF will send the packets to the SFI that supports SFT 44 1733 before forwarding the packets to their destinations. 1735 8.4. Example SFP With Choice of SFTs 1737 SFP4: RD = 198.51.100.1,104, SPI = 18, 1738 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1739 [SI = 250, {SFT = 43, RD = 192.0.2.2,2, 1740 SFT = 44, RD = 192.0.2.3,8 } ] 1742 This example provides a choice of SF type in the second hop in the 1743 path. The SI of 250 indicates a choice between SF type 43 located 1744 through SF2 and SF type 44 located at SF3. 1746 SFF1 will receive packets on the path from the Classifier and will 1747 identify the path from the SPI (18). The initial SI will be 255 and 1748 so SFF1 will deliver the packets to the SFI for SFT 41. 1750 When the packets are returned to SFF1 by the SFI the SI will be 1751 decreased to 250 for the next hop. SFF1 now has a free choice of 1752 next hop SFF to execute the next hop in the path selecting between 1753 all SFF2 that support an SF of type 43 and SFF3 that supports an SF 1754 of type 44. These may be completely different functions that are to 1755 be executed dependent on specific conditions, or may be similar 1756 functions identified with different type identifiers (such as 1757 firewalls from different vendors). SFF1 uses its local policy and 1758 load balancing algorithm to make this choice, and may use additional 1759 information passed back from the local SFI to help inform its 1760 selection. The chosen SFF will send the packets to the SFI that 1761 supports the chose SFT before forwarding the packets to their 1762 destinations. 1764 8.5. Example Correlated Bidirectional SFPs 1766 SFP5: RD = 198.51.100.1,105, SPI = 19, 1767 Assoc-Type = 1, Assoc-RD = 198.51.100.1,106, Assoc-SPI = 20, 1768 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1769 [SI = 250, SFT = 43, RD = 192.0.2.2,2] 1771 SFP6: RD = 198.51.100.1,106, SPI = 20, 1772 Assoc-Type = 1, Assoc-RD = 198.51.100.1,105, Assoc-SPI = 19, 1773 [SI = 254, SFT = 43, RD = 192.0.2.2,2], 1774 [SI = 249, SFT = 41, RD = 192.0.2.1,1] 1776 This example demonstrates correlation of two SFPs to form a 1777 bidirectional SFP as described in Section 7.2. 1779 Two SFPRs are advertised by the Controller. They have different SPIs 1780 (19 and 20) so they are known to be separate SFPs, but they both have 1781 Association TLVs with Association Type set to 1 indicating 1782 bidirectional SFPs. Each has an Associated SFPR-RD fields containing 1783 the value of the other SFPR-RD to correlated the two SFPs as a 1784 bidirectional pair. 1786 As can be seen from the SFPRs in this example, the paths are 1787 symmetric: the hops in SFP5 appear in the reverse order in SFP6. 1789 8.6. Example Correlated Asymmetrical Bidirectional SFPs 1790 SFP7: RD = 198.51.100.1,107, SPI = 21, 1791 Assoc-Type = 1, Assoc-RD = 198.51.100.1,108, Assoc-SPI = 22, 1792 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1793 [SI = 250, SFT = 43, RD = 192.0.2.2,2] 1795 SFP8: RD = 198.51.100.1,108, SPI = 22, 1796 Assoc-Type = 1, Assoc-RD = 198.51.100.1,107, Assoc-SPI = 21, 1797 [SI = 254, SFT = 44, RD = 192.0.2.4,6], 1798 [SI = 249, SFT = 41, RD = 192.0.2.1,1] 1800 Asymmetric bidirectional SFPs can also be created. This example 1801 shows a pair of SFPs with distinct SPIs (21 and 22) that are 1802 correlated in the same way as in the example in Section 8.5. 1804 However, unlike in that example, the SFPs are different in each 1805 direction. Both paths include a hop of SF type 41, but SFP7 includes 1806 a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF 1807 type 44 supported at SFF4. 1809 8.7. Example Looping in an SFP 1811 SFP9: RD = 198.51.100.1,109, SPI = 23, 1812 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1813 [SI = 250, SFT = 44, RD = 192.0.2.4,5], 1814 [SI = 245, SFT = 1, RD = {SPI=23, SI=255, Rsv=0}], 1815 [SI = 245, SFT = 42, RD = 192.0.2.3,7] 1817 Looping and jumping are described in Section 6. This example shows 1818 an SFP that contains an explicit loop-back instruction that is 1819 presented as a choice within an SFP hop. 1821 The first two hops in the path (SI = 255 and SI = 250) are normal. 1822 That is, the packets will be delivered to SFF1 and SFF4 in turn for 1823 execution of SFs of type 41 and 44 respectively. 1825 The third hop (SI = 245) presents SFF4 with a choice of next hop. It 1826 can either forward the packets to SFF3 for an SF of type 42 (the 1827 second choice), or it can loop back. 1829 The loop-back entry in the SFPR for SI = 245 is indicated by the 1830 special purpose SFT value 1 ("Change Sequence"). Within this hop, 1831 the RD is interpreted as encoding the SPI and SI of the next hop (see 1832 Section 6.1. In this case the SPI is 23 which indicates that this is 1833 loop or branch: i.e., the next hop is on the same SFP. The SI is set 1834 to 255: this is a higher number than the current SI (245) indicating 1835 a loop. 1837 SFF4 must make a choice between these two next hops. Either the 1838 packets will be forwarded to SFF3 with the NSH SI decreased to 245 or 1839 looped back to SFF1 with the NSH SI reset to 255. This choice will 1840 be made according to local policy, information passed back by the 1841 local SFI, and details in the packets' metadata that are used to 1842 prevent infinite looping. 1844 8.8. Example Branching in an SFP 1846 SFP10: RD = 198.51.100.1,110, SPI = 24, 1847 [SI = 254, SFT = 42, RD = 192.0.2.3,7], 1848 [SI = 249, SFT = 43, RD = 192.0.2.2,2] 1850 SFP11: RD = 198.51.100.1,111, SPI = 25, 1851 [SI = 255, SFT = 41, RD = 192.0.2.1,1], 1852 [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}] 1854 Branching follows a similar procedure to that for looping (and 1855 jumping) as shown in Section 8.7 however there are two SFPs involved. 1857 SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for 1858 execution of service functions of type 42 and 43 respectively. 1860 SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1 1861 processes the next hop in the path and finds a "Change Sequence" 1862 Special Purpose SFT. The SFIR-RD field includes an SPI of 24 which 1863 indicates SFP10, not the current SFP. The SI in the SFIR-RD is 254, 1864 so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and 1865 send the packets to the appropriate SFF as advertised in the SFPR for 1866 SFP10 (that is, SFF3). 1868 8.9. Examples of SFPs with Stateful Service Functions 1870 This section provides some examples to demonstrate establishing SFPs 1871 when there is a choice of service functions at a particular hop, and 1872 where consistency of choice is required in both directions. The 1873 scenarios that give rise to this requirement are discussed in 1874 Section 7.3. 1876 8.9.1. Forward and Reverse Choice Made at the SFF 1878 Consider the topology shown in Figure 12. There are three SFFs 1879 arranged neatly in a line, and the middle one (SFF2) supports three 1880 SFIs all of SFT 42. These three instances can be used by SFF2 to 1881 load balance so that no one instance is swamped. 1883 ------ ------ ------ ------ ------ 1884 | SFI | | SFIa | | SFIb | | SFIc | | SFI | 1885 |SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43| 1886 ------ ------\ ------ /------ ------ 1887 \ \ | / / 1888 --------- --------- --------- 1889 ---------- | SFF1 | | SFF2 | | SFF3 | 1890 --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> 1891 --> |Classifier| --------- --------- --------- 1892 | | 1893 ---------- 1895 Figure 12: Example Where Choice is Made at the SFF 1897 This leads to the following SFIRs being advertised. 1899 RD = 192.0.2.1,11, SFT = 41 1900 RD = 192.0.2.2,11, SFT = 42 (for SFIa) 1901 RD = 192.0.2.2,12, SFT = 42 (for SFIb) 1902 RD = 192.0.2.2,13, SFT = 42 (for SFIc) 1903 RD = 192.0.2.3,11, SFT = 43 1905 The controller can create a single forward SFP giving SFF2 the choice 1906 of which SFI to use to provide function of SFT 42 as follows. The 1907 load-balancing choice between the three available SFIs is assumed to 1908 be within the capabilities of the SFF and if the SFs are stateful it 1909 is assumed that the SFF knows this and arranges load balancing in a 1910 stable, flow-dependent way. 1912 SFP12: RD = 198.51.100.1,112, SPI = 26, 1913 Assoc-Type = 1, Assoc-RD = 198.51.100.1,113, Assoc-SPI = 27, 1914 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1915 [SI = 254, SFT = 42, {RD = 192.0.2.2,11, 1916 192.0.2.2,12, 1917 192.0.2.2,13 }], 1918 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1920 The reverse SFP in this case may also be created as shown below using 1921 association with the forward SFP and giving the load-balancing choice 1922 to SFF2. This is safe, even in the case that the SFs of type 42 are 1923 stateful because SFF2 is doing the load balancing in both directions 1924 and can apply the same algorithm to ensure that packets associated 1925 with the same flow use the same SFI regardless of the direction of 1926 travel. 1928 SFP13: RD = 198.51.100.1,113, SPI = 27, 1929 Assoc-Type = 1, Assoc-RD = 198.51.100.1,112, Assoc-SPI = 26, 1930 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1931 [SI = 254, SFT = 42, {RD = 192.0.2.2,11, 1932 192.0.2.2,12, 1933 192.0.2.2,13 }], 1934 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1936 8.9.2. Parallel End-to-End SFPs with Shared SFF 1938 The mechanism described in Section 8.9.1 might not be desirable 1939 because of the functional assumptions it places on SFF2 to be able to 1940 load balance with suitable flow identification, stability, and 1941 equality in both directions. Instead, it may be desirable to place 1942 the responsibility for flow classification in the Classifier and let 1943 it determine load balancing with the implied choice of SFIs. 1945 Consider the network graph as shown in Figure 12 and with the same 1946 set of SFIRs as listed in Section 8.9.1. In this case the controller 1947 could specify three forward SFPs with their corresponding associated 1948 reverse SFPs. Each bidirectional pair of SFPs uses a different SFI 1949 for the SF of type 42. The controller can instruct the Classifier 1950 how to place traffic on the three bidirectional SFPs, or can treat 1951 them as a group leaving the Classifier responsible for balancing the 1952 load. 1954 SFP14: RD = 198.51.100.1,114, SPI = 28, 1955 Assoc-Type = 1, Assoc-RD = 198.51.100.1,117, Assoc-SPI = 31, 1956 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1957 [SI = 254, SFT = 42, RD = 192.0.2.2,11], 1958 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1960 SFP15: RD = 198.51.100.1,115, SPI = 29, 1961 Assoc-Type = 1, Assoc-RD = 198.51.100.1,118, Assoc-SPI = 32, 1962 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1963 [SI = 254, SFT = 42, RD = 192.0.2.2,12], 1964 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1966 SFP16: RD = 198.51.100.1,116, SPI = 30, 1967 Assoc-Type = 1, Assoc-RD = 198.51.100.1,119, Assoc-SPI = 33, 1968 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 1969 [SI = 254, SFT = 42, RD = 192.0.2.2,13], 1970 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 1972 SFP17: RD = 198.51.100.1,117, SPI = 31, 1973 Assoc-Type = 1, Assoc-RD = 198.51.100.1,114, Assoc-SPI = 28, 1974 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1975 [SI = 254, SFT = 42, RD = 192.0.2.2,11], 1976 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1978 SFP18: RD = 198.51.100.1,118, SPI = 32, 1979 Assoc-Type = 1, Assoc-RD = 198.51.100.1,115, Assoc-SPI = 29, 1980 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1981 [SI = 254, SFT = 42, RD = 192.0.2.2,12], 1982 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1984 SFP19: RD = 198.51.100.1,119, SPI = 33, 1985 Assoc-Type = 1, Assoc-RD = 198.51.100.1,116, Assoc-SPI = 30, 1986 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 1987 [SI = 254, SFT = 42, RD = 192.0.2.2,13], 1988 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 1990 8.9.3. Parallel End-to-End SFPs with Separate SFFs 1992 While the examples in Section 8.9.1 and Section 8.9.2 place the 1993 choice of SFI as subtended from the same SFF, it is also possible 1994 that the SFIs are each subtended from a different SFF as shown in 1995 Figure 13. In this case it is harder to coordinate the choices for 1996 forward and reverse paths without some form of coordination between 1997 SFF1 and SFF3. Therefore it would be normal to consider end-to-end 1998 parallel SFPs as described in Section 8.9.2. 2000 ------ 2001 | SFIa | 2002 |SFT=42| 2003 ------ 2004 ------ | 2005 | SFI | --------- 2006 |SFT=41| | SFF5 | 2007 ------ ..|192.0.2.5|.. 2008 | ..: --------- :.. 2009 ---------.: :.--------- 2010 ---------- | SFF1 | --------- | SFF3 | 2011 --> | |..|192.0.2.1|....| SFF6 |....|192.0.2.3| --> 2012 --> |Classifier| ---------: |192.0.2.6| :--------- 2013 | | : --------- : | 2014 ---------- : | : ------ 2015 : ------ : | SFI | 2016 :.. | SFIb | ..: |SFT=43| 2017 :.. |SFT=42| ..: ------ 2018 : ------ : 2019 :.---------.: 2020 | SFF7 | 2021 |192.0.2.7| 2022 --------- 2023 | 2024 ------ 2025 | SFIc | 2026 |SFT=42| 2027 ------ 2029 Figure 13: Second Example With Parallel End-to-End SFPs 2031 In this case, five SFIRs are advertised as follows: 2033 RD = 192.0.2.1,11, SFT = 41 2034 RD = 192.0.2.5,11, SFT = 42 (for SFIa) 2035 RD = 192.0.2.6,11, SFT = 42 (for SFIb) 2036 RD = 192.0.2.7,11, SFT = 42 (for SFIc) 2037 RD = 192.0.2.3,11, SFT = 43 2039 In this case the controller could specify three forward SFPs with 2040 their corresponding associated reverse SFPs. Each bidirectional pair 2041 of SFPs uses a different SFF and SFI for middle hop (for an SF of 2042 type 42). The controller can instruct the Classifier how to place 2043 traffic on the three bidirectional SFPs, or can treat them as a group 2044 leaving the Classifier responsible for balancing the load. 2046 SFP20: RD = 198.51.100.1,120, SPI = 34, 2047 Assoc-Type = 1, Assoc-RD = 198.51.100.1,123, Assoc-SPI = 37, 2048 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 2049 [SI = 254, SFT = 42, RD = 192.0.2.5,11], 2050 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 2052 SFP21: RD = 198.51.100.1,121, SPI = 35, 2053 Assoc-Type = 1, Assoc-RD = 198.51.100.1,124, Assoc-SPI = 38, 2054 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 2055 [SI = 254, SFT = 42, RD = 192.0.2.6,11], 2056 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 2058 SFP22: RD = 198.51.100.1,122, SPI = 36, 2059 Assoc-Type = 1, Assoc-RD = 198.51.100.1,125, Assoc-SPI = 39, 2060 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 2061 [SI = 254, SFT = 42, RD = 192.0.2.7,11], 2062 [SI = 253, SFT = 43, RD = 192.0.2.3,11] 2064 SFP23: RD = 198.51.100.1,123, SPI = 37, 2065 Assoc-Type = 1, Assoc-RD = 198.51.100.1,120, Assoc-SPI = 34, 2066 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 2067 [SI = 254, SFT = 42, RD = 192.0.2.5,11], 2068 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 2070 SFP24: RD = 198.51.100.1,124, SPI = 38, 2071 Assoc-Type = 1, Assoc-RD = 198.51.100.1,121, Assoc-SPI = 35, 2072 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 2073 [SI = 254, SFT = 42, RD = 192.0.2.6,11], 2074 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 2076 SFP25: RD = 198.51.100.1,125, SPI = 39, 2077 Assoc-Type = 1, Assoc-RD = 198.51.100.1,122, Assoc-SPI = 36, 2078 [SI = 255, SFT = 43, RD = 192.0.2.3,11], 2079 [SI = 254, SFT = 42, RD = 192.0.2.7,11], 2080 [SI = 253, SFT = 41, RD = 192.0.2.1,11] 2082 8.9.4. Parallel SFPs Downstream of the Choice 2084 The mechanism of parallel SFPs demonstrated in Section 8.9.3 is 2085 perfectly functional and may be practical in many environments. 2086 However, there may be scaling concerns because of the large amount of 2087 state (knowledge of SFPs, i.e., SFPR advertisements retained) if 2088 there is a very large amount of choice of SFIs (for example, tens of 2089 instances of the same stateful SF), or if there are multiple choices 2090 of stateful SF along a path. This situation may be mitigated using 2091 SFP fragments that are combined to form the end to end SFPs. 2093 The example presented here is necessarily simplistic, but should 2094 convey the basic principle. The example presented in Figure 14 is 2095 similar to that in Section 8.9.3 but with an additional first hop. 2097 ------ 2098 | SFIa | 2099 |SFT=43| 2100 ------ 2101 ------ ------ | 2102 | SFI | | SFI | --------- 2103 |SFT=41| |SFT=42| | SFF5 | 2104 ------ ------ ..|192.0.2.5|.. 2105 | | ..: --------- :.. 2106 --------- ---------.: :.--------- 2107 ------ | SFF1 | | SFF2 | --------- | SFF3 | 2108 -->|Class-|.|192.0.2.1|.|192.0.2.2|....| SFF6 |....|192.0.2.3|--> 2109 -->| ifier| --------- ---------: |192.0.2.6| :--------- 2110 ------ : --------- : | 2111 : | : ------ 2112 : ------ : | SFI | 2113 :.. | SFIb | ..: |SFT=44| 2114 :.. |SFT=43| ..: ------ 2115 : ------ : 2116 :.---------.: 2117 | SFF7 | 2118 |192.0.2.7| 2119 --------- 2120 | 2121 ------ 2122 | SFIc | 2123 |SFT=43| 2124 ------ 2126 Figure 14: Example With Parallel SFPs Downstream of Choice 2128 The six SFIs are advertised as follows: 2130 RD = 192.0.2.1,11, SFT = 41 2131 RD = 192.0.2.2,11, SFT = 42 2132 RD = 192.0.2.5,11, SFT = 43 (for SFIa) 2133 RD = 192.0.2.6,11, SFT = 43 (for SFIb) 2134 RD = 192.0.2.7,11, SFT = 43 (for SFIc) 2135 RD = 192.0.2.3,11, SFT = 44 2137 SFF2 is the point at which a load balancing choice must be made. So 2138 "tail-end" SFPs are constructed as follows. Each takes in a 2139 different SFF that provides access to an SF of type 43. 2141 SFP26: RD = 198.51.100.1,126, SPI = 40, 2142 Assoc-Type = 1, Assoc-RD = 198.51.100.1,130, Assoc-SPI = 44, 2143 [SI = 255, SFT = 43, RD = 192.0.2.5,11], 2144 [SI = 254, SFT = 44, RD = 192.0.2.3,11] 2146 SFP27: RD = 198.51.100.1,127, SPI = 41, 2147 Assoc-Type = 1, Assoc-RD = 198.51.100.1,131, Assoc-SPI = 45, 2148 [SI = 255, SFT = 43, RD = 192.0.2.6,11], 2149 [SI = 254, SFT = 44, RD = 192.0.2.3,11] 2151 SFP28: RD = 198.51.100.1,128, SPI = 42, 2152 Assoc-Type = 1, Assoc-RD = 198.51.100.1,132, Assoc-SPI = 46, 2153 [SI = 255, SFT = 43, RD = 192.0.2.7,11], 2154 [SI = 254, SFT = 44, RD = 192.0.2.3,11] 2156 Now an end-to-end SFP with load balancing choice can be constructed 2157 as follows. The choice made by SFF2 is expressed in terms of 2158 entering one of the three "tail end" SFPs. 2160 SFP29: RD = 198.51.100.1,129, SPI = 43, 2161 [SI = 255, SFT = 41, RD = 192.0.2.1,11], 2162 [SI = 254, SFT = 42, RD = 192.0.2.2,11], 2163 [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0}, 2164 RD = {SPI=41, SI=255, Rsv=0}, 2165 RD = {SPI=42, SI=255, Rsv=0} } ] 2167 Now, despite the load balancing choice being made other than at the 2168 initial classifier, it is possible for the reverse SFPs to be well- 2169 constructed without any ambiguity. The three reverse paths appear as 2170 follows. 2172 SFP30: RD = 198.51.100.1,130, SPI = 44, 2173 Assoc-Type = 1, Assoc-RD = 198.51.100.1,126, Assoc-SPI = 40, 2174 [SI = 255, SFT = 44, RD = 192.0.2.4,11], 2175 [SI = 254, SFT = 43, RD = 192.0.2.5,11], 2176 [SI = 253, SFT = 42, RD = 192.0.2.2,11], 2177 [SI = 252, SFT = 41, RD = 192.0.2.1,11] 2179 SFP31: RD = 198.51.100.1,131, SPI = 45, 2180 Assoc-Type = 1, Assoc-RD = 198.51.100.1,127, Assoc-SPI = 41, 2181 [SI = 255, SFT = 44, RD = 192.0.2.4,11], 2182 [SI = 254, SFT = 43, RD = 192.0.2.6,11], 2183 [SI = 253, SFT = 42, RD = 192.0.2.2,11], 2184 [SI = 252, SFT = 41, RD = 192.0.2.1,11] 2186 SFP32: RD = 198.51.100.1,132, SPI = 46, 2187 Assoc-Type = 1, Assoc-RD = 198.51.100.1,128, Assoc-SPI = 42, 2188 [SI = 255, SFT = 44, RD = 192.0.2.4,11], 2189 [SI = 254, SFT = 43, RD = 192.0.2.7,11], 2190 [SI = 253, SFT = 42, RD = 192.0.2.2,11], 2191 [SI = 252, SFT = 41, RD = 192.0.2.1,11] 2193 9. Security Considerations 2195 This document inherits all the security considerations discussed in 2196 the documents that specify BGP, the documents that specify BGP 2197 Multiprotocol Extensions, and the documents that define the 2198 attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. For 2199 more information look in [RFC4271], [RFC4760], and 2200 [I-D.ietf-idr-tunnel-encaps]. 2202 Service Function Chaining provides a significant attack opportunity: 2203 packets can be diverted from their normal paths through the network, 2204 can be made to execute unexpected functions, and the functions that 2205 are instantiated in software can be subverted. However, this 2206 specification does not change the existence of Service Function 2207 Chaining and security issues specific to Service Function Chaining 2208 are covered in [RFC7665] and [RFC8300]. 2210 This document defines a control plane for Service Function Chaining. 2211 Clearly, this provides an attack vector for a Service Function 2212 Chaining system as an attack on this control plane could be used to 2213 make the system misbehave. Thus, the security of the BGP system is 2214 critically important to the security of the whole Service Function 2215 Chaining system. 2217 10. IANA Considerations 2219 10.1. New BGP AF/SAFI 2221 IANA maintains a registry of "Address Family Numbers". IANA is 2222 requested to assign a new Address Family Number from the "Standards 2223 Action" range called "BGP SFC" (TBD1 in this document) with this 2224 document as a reference. 2226 IANA maintains a registry of "Subsequent Address Family Identifiers 2227 (SAFI) Parameters". IANA is requested to assign a new SAFI value 2228 from the "Standards Action" range called "BGP SFC" (TBD2 in this 2229 document) with this document as a reference. 2231 10.2. New BGP Path Attribute 2233 IANA maintains a registry of "Border Gateway Protocol (BGP) 2234 Parameters" with a subregistry of "BGP Path Attributes". IANA is 2235 requested to assign a new Path attribute called "SFP attribute" (TBD3 2236 in this document) with this document as a reference. 2238 10.3. New SFP Attribute TLVs Type Registry 2240 IANA maintains a registry of "Border Gateway Protocol (BGP) 2241 Parameters". IANA is request to create a new subregistry called the 2242 "SFP Attribute TLVs" registry. 2244 Valid values are in the range 0 to 65535. 2246 o Values 0 and 65535 are to be marked "Reserved, not to be 2247 allocated". 2249 o Values 1 through 65524 are to be assigned according to the "First 2250 Come First Served" policy [RFC8126]. 2252 This document should be given as a reference for this registry. 2254 The new registry should track: 2256 o Type 2258 o Name 2260 o Reference Document or Contact 2262 o Registration Date 2264 The registry should initially be populated as follows: 2266 Type | Name | Reference | Date 2267 ------+-------------------------+---------------+--------------- 2268 1 | Association TLV | [This.I-D] | Date-to-be-set 2269 2 | Hop TLV | [This.I-D] | Date-to-be-set 2270 3 | SFT TLV | [This.I-D] | Date-to-be-set 2271 4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set 2272 5 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set 2274 10.4. New SFP Association Type Registry 2276 IANA maintains a registry of "Border Gateway Protocol (BGP) 2277 Parameters". IANA is request to create a new subregistry called the 2278 "SFP Association Type" registry. 2280 Valid values are in the range 0 to 65535. 2282 o Values 0 and 65535 are to be marked "Reserved, not to be 2283 allocated". 2285 o Values 1 through 65524 are to be assigned according to the "First 2286 Come First Served" policy [RFC8126]. 2288 This document should be given as a reference for this registry. 2290 The new registry should track: 2292 o Association Type 2294 o Name 2296 o Reference Document or Contact 2298 o Registration Date 2300 The registry should initially be populated as follows: 2302 Association Type | Name | Reference | Date 2303 -----------------+--------------------+------------+--------------- 2304 1 | Bidirectional SFP | [This.I-D] | Date-to-be-set 2306 10.5. New Service Function Type Registry 2308 IANA is request to create a new top-level registry called "Service 2309 Function Chaining Service Function Types". 2311 Valid values are in the range 0 to 65535. 2313 o Values 0 and 65535 are to be marked "Reserved, not to be 2314 allocated". 2316 o Values 1 through 31 are to be assigned by "Standards Action" 2317 [RFC8126] and are referred to as the Special Purpose SFT values. 2319 o Other values (32 through 65534) are to be assigned according to 2320 the "First Come First Served" policy [RFC8126]. 2322 This document should be given as a reference for this registry. 2324 The new registry should track: 2326 o Value 2328 o Name 2330 o Reference Document or Contact 2332 o Registration Date 2334 The registry should initially be populated as follows: 2336 Value | Name | Reference | Date 2337 ------+-----------------------+---------------+--------------- 2338 1 | Change Sequence | [This.I-D] | Date-to-be-set 2340 10.6. New Generic Transitive Experimental Use Extended Community Sub- 2341 Types 2343 IANA maintains a registry of "Border Gateway Protocol (BGP) 2344 Parameters" with a subregistry of "Generic Transitive Experimental 2345 Use Extended Community Sub-Type". IANA is requested to assign a new 2346 sub-type as follows: 2348 "Flow Spec for SFC Classifiers" (TBD4 in this document) with this 2349 document as the reference. 2351 10.7. New BGP Transitive Extended Community Types 2353 IANA maintains a registry of "Border Gateway Protocol (BGP) 2354 Parameters" with a subregistry of "BGP Transitive Extended Community 2355 Types". IANA is requested to assign new types as follows: 2357 "SFI Pool Identifier" (TBD6 in this document) with this document 2358 as the reference. 2360 "MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this 2361 document) with this document as the reference. 2363 10.8. SPI/SI Representation 2365 IANA is requested to assign a codepoint from the "BGP Tunnel 2366 Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI 2367 Representation Sub-TLV" (TBD5 in this document) with this document 2368 being the reference. 2370 11. Contributors 2372 Stuart Mackie 2373 Juniper Networks 2375 Email: wsmackie@juinper.net 2377 Keyur Patel 2378 Arrcus, Inc. 2380 Email: keyur@arrcus.com 2382 Avinash Lingala 2383 AT&T 2385 Email: ar977m@att.com 2387 12. Acknowledgements 2389 Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful 2390 comments, and to Joel Halpern for discussions that improved this 2391 document. Yuanlong Jiang provided a useful review and caught some 2392 important issues. Stephane Litkowski did an exceptionally good and 2393 detailed document shepherd review. 2395 Andy Malis contributed text that formed the basis of Section 7.8. 2397 13. References 2398 13.1. Normative References 2400 [I-D.ietf-idr-tunnel-encaps] 2401 Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel 2402 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11 2403 (work in progress), February 2019. 2405 [I-D.ietf-mpls-sfc] 2406 Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 2407 Forwarding Plane for Service Function Chaining", draft- 2408 ietf-mpls-sfc-05 (work in progress), February 2019. 2410 [I-D.ietf-mpls-sfc-encapsulation] 2411 Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 2412 "MPLS Transport Encapsulation For The SFC NSH", draft- 2413 ietf-mpls-sfc-encapsulation-03 (work in progress), March 2414 2019. 2416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2417 Requirement Levels", BCP 14, RFC 2119, 2418 DOI 10.17487/RFC2119, March 1997, 2419 . 2421 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2422 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2423 DOI 10.17487/RFC4271, January 2006, 2424 . 2426 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2427 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2428 2006, . 2430 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2431 "Multiprotocol Extensions for BGP-4", RFC 4760, 2432 DOI 10.17487/RFC4760, January 2007, 2433 . 2435 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 2436 and D. McPherson, "Dissemination of Flow Specification 2437 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 2438 . 2440 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 2441 Chaining (SFC) Architecture", RFC 7665, 2442 DOI 10.17487/RFC7665, October 2015, 2443 . 2445 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2446 Writing an IANA Considerations Section in RFCs", BCP 26, 2447 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2448 . 2450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2452 May 2017, . 2454 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 2455 "Network Service Header (NSH)", RFC 8300, 2456 DOI 10.17487/RFC8300, January 2018, 2457 . 2459 13.2. Informative References 2461 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 2462 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 2463 RFC 6790, DOI 10.17487/RFC6790, November 2012, 2464 . 2466 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 2467 Service Function Chaining", RFC 7498, 2468 DOI 10.17487/RFC7498, April 2015, 2469 . 2471 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 2472 "Encapsulating MPLS in UDP", RFC 7510, 2473 DOI 10.17487/RFC7510, April 2015, 2474 . 2476 Authors' Addresses 2478 Adrian Farrel 2479 Old Dog Consulting 2481 Email: adrian@olddog.co.uk 2483 John Drake 2484 Juniper Networks 2486 Email: jdrake@juniper.net 2487 Eric Rosen 2488 Juniper Networks 2490 Email: erosen52@gmail.com 2492 Jim Uttaro 2493 AT&T 2495 Email: ju1738@att.com 2497 Luay Jalil 2498 Verizon 2500 Email: luay.jalil@verizon.com