idnits 2.17.1 draft-ietf-bess-nsh-bgp-control-plane-13.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 (December 13, 2019) is 1596 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 571, but not defined == Missing Reference: 'SI' is mentioned on line 571, but not defined == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-18 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-15 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Informational RFC: RFC 8596 Summary: 3 errors (**), 0 flaws (~~), 5 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: June 15, 2020 E. Rosen 6 Juniper Networks 7 J. Uttaro 8 AT&T 9 L. Jalil 10 Verizon 11 December 13, 2019 13 BGP Control Plane for NSH SFC 14 draft-ietf-bess-nsh-bgp-control-plane-13 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 June 15, 2020. 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 . . . . . . . . . . . . . . . . . . 5 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1. Overview of Service Function Chaining . . . . . . . . . . 6 72 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8 73 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 12 75 3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 13 76 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 14 77 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 14 78 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 15 79 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 21 80 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 22 81 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 22 82 4.2. Service Function Instance Routes . . . . . . . . . . . . 22 83 4.3. Service Function Path Routes . . . . . . . . . . . . . . 22 84 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 24 85 4.5. Service Function Forwarder Operation . . . . . . . . . . 25 86 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 26 87 5. Selection within Service Function Paths . . . . . . . . . . . 27 88 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 29 89 6.1. Protocol Control of Looping, Jumping, and Branching . . . 30 90 6.2. Implications for Forwarding State . . . . . . . . . . . . 30 91 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 31 92 7.1. Correlating Service Function Path Instances . . . . . . . 31 93 7.2. Considerations for Stateful Service Functions . . . . . . 32 94 7.3. VPN Considerations and Private Service Functions . . . . 33 95 7.4. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 33 96 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 34 97 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 36 99 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 36 100 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 36 101 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37 102 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 38 103 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 39 104 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 40 105 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 40 106 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 41 107 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 41 108 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 42 109 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 43 110 8.9. Examples of SFPs with Stateful Service Functions . . . . 43 111 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 44 112 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 45 113 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 47 114 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 49 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 117 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 53 118 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 53 119 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 53 120 10.4. New SFP Association Type Registry . . . . . . . . . . . 54 121 10.5. New Service Function Type Registry . . . . . . . . . . . 55 122 10.6. New Generic Transitive Experimental Use Extended 123 Community Sub-Types . . . . . . . . . . . . . . . . . . 56 124 10.7. New BGP Transitive Extended Community Types . . . . . . 56 125 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 56 126 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56 127 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 129 13.1. Normative References . . . . . . . . . . . . . . . . . . 57 130 13.2. Informative References . . . . . . . . . . . . . . . . . 59 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 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 (a centralized network component responsible for planning 184 and coordinating Service Function Chaining within the network) to 185 advertise the paths of "chains" of service functions, and to give a 186 unique designator to each such path so that they can be used in 187 conjunction with the Network Service Header [RFC8300]. 189 This document adopts the SFC architecture described in [RFC7665]. 191 1.1. Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 1.2. Terminology 201 This document uses the following terms from [RFC7665]: 203 o Bidirectional Service Function Chain 205 o Classifier 207 o Service Function (SF) 209 o Service Function Chain (SFC) 211 o Service Function Forwarder (SFF) 213 o Service Function Instance (SFI) 215 o Service Function Path (SFP) 217 o SFC branching 219 Additionally, this document uses the following terms from [RFC8300]: 221 o Network Service Header (NSH) 223 o Service Index (SI) 225 o Service Path Identifier (SPI) 227 This document introduces the following terms: 229 o Service Function Instance Route (SFIR). A new BGP Route Type 230 advertised by the node that hosts an SFI to describe the SFI and 231 to announce the way to forward a packet to the node through the 232 underlay network. 234 o Service Function Overlay Network. The logical network comprised 235 of Classifiers, SFFs, and SFIs that are connected by paths or 236 tunnels through underlay transport networks. 238 o Service Function Path Route (SFPR). A new BGP Route Type 239 originated by Controllers to advertise the details of each SFP. 241 o Service Function Type (SFT). An indication of the function and 242 features of an SFI. 244 2. Overview 246 2.1. Overview of Service Function Chaining 248 In [RFC8300] a Service Function Chain (SFC) is an ordered list of 249 Service Functions (SFs). A Service Function Path (SFP) is an 250 indication of which instances of SFs are acceptable to be traversed 251 in an instantiation of an SFC in a service function overlay network. 252 The Service Path Identifier (SPI) is a 24-bit number that identifies 253 a specific SFP, and a Service Index (SI) is an 8-bit number that 254 identifies a specific point in that path. In the context of a 255 particular SFP (identified by an SPI), an SI represents a particular 256 Service Function, and indicates the order of that SF in the SFP. 258 In fact, each SI is mapped to one or more SFs that are implemented by 259 one or more Service Function Instances (SFIs) that support those 260 specified SFs. Thus an SI may represent a choice of SFIs of one or 261 more Service Function Types. By deploying multiple SFIs for a single 262 SF, one can provide load balancing and redundancy. 264 A special functional element, called a Classifier, is located at each 265 ingress point to a service function overlay network. It assigns the 266 packets of a given packet flow to a specific Service Function Path. 267 This may be done by comparing specific fields in a packet's header 268 with local policy, which may be customer/network/service specific. 269 The classifier picks an SFP and sets the SPI accordingly, it then 270 sets the SI to the value of the SI for the first hop in the SFP, and 271 then prepends a Network Services Header (NSH) [RFC8300] containing 272 the assigned SPI/SI to that packet. Note that the Classifier and the 273 node that hosts the first Service Function in a Service Function Path 274 need not be located at the same point in the service function overlay 275 network. 277 Note that the presence of the NSH can make it difficult for nodes in 278 the underlay network to locate the fields in the original packet that 279 would normally be used to constrain equal cost multipath (ECMP) 280 forwarding. Therefore, it is recommended that the node prepending 281 the NSH also provide some form of entropy indicator that can be used 282 in the underlay network. How this indicator is generated and 283 supplied, and how an SFF generates a new entropy indicator when it 284 forwards a packet to the next SFF are out of scope of this document. 286 The Service Function Forwarder (SFF) receives a packet from the 287 previous node in a Service Function Path, removes the packet's link 288 layer or tunnel encapsulation and hands the packet and the NSH to the 289 Service Function Instance for processing. The SFI has no knowledge 290 of the SFP. 292 When the SFF receives the packet and the NSH back from the SFI it 293 must select the next SFI along the path using the SPI and SI in the 294 NSH and potentially choosing between multiple SFIs (possibly of 295 different Service Function Types) as described in Section 5. In the 296 normal case the SPI remains unchanged and the SI will have been 297 decremented to indicate the next SF along the path. But other 298 possibilities exist if the SF makes other changes to the NSH through 299 a process of re-classification: 301 o The SI in the NSH may indicate: 303 * A previous SF in the path: known as "looping" (see Section 6). 305 * An SF further down the path: known as "jumping" (see also 306 Section 6). 308 o The SPI and the SI may point to an SF on a different SFP: known as 309 "branching" (see also Section 6). 311 Such modifications are limited to within the same service function 312 overlay network. That is, an SPI is known within the scope of 313 service function overlay network. Furthermore, the new SI value is 314 interpreted in the context of the SFP identified by the SPI. 316 As described in [RFC8300], an unknown or invalid SPI is treated as an 317 error and the SFF drops the packet: such errors should be logged, and 318 such logs are subject to rate limits. 320 Also, as described in [RFC8300], an SFF receiving an SI that is 321 unknown in the context of the SPI can reduce the value to the next 322 meaningful SI value in the SFP indicated by the SPI. If no such 323 value exists or if the SFF does not support this function, the SFF 324 drops the packet and should log the event: such logs are also subject 325 to rate limits. 327 The SFF then selects an SFI that provides the SF denoted by the SPI/ 328 SI, and forwards the packet to the SFF that supports that SFI. 330 [RFC8300] makes it clear that the intended scope is for use within a 331 single provider's operational domain. 333 This document adopts the SFC architecture described in [RFC7665] and 334 adds a control plane to support the functions as described in 335 Section 2.2. An essential component of this solution is the 336 Controller. This is a network component responsible for planning 337 SFPs within the network. It gathers information about the 338 availability of SFIs and SFFs, instructs the control plane about the 339 SFPs to be programmed, and instructs the Classifiers how to assign 340 traffic flows to individual SFPs. 342 2.2. Control Plane Overview 344 To accomplish the function described in Section 2.1, this document 345 introduces the Service Function Type (SFT) that is the category of SF 346 that is supported by an SFF (such as "firewall"). An IANA registry 347 of Service Function Types is introduced in Section 10. An SFF may 348 support SFs of multiple different SFTs, and may support multiple SFIs 349 of each SF. 351 This document also introduces a new BGP AFI/SAFI (values to be 352 assigned by IANA) for "SFC Routes". Two SFC Route Types are defined 353 by this document: the Service Function Instance Route (SFIR), and the 354 Service Function Path Route (SFPR). As detailed in Section 3, the 355 route type is indicated by a sub-field in the NLRI. 357 o The SFIR is advertised by the node hosting the service function 358 instance. The SFIR describes a particular instance of a 359 particular Service Function (i.e., an SFI) and the way to forward 360 a packet to it through the underlay network, i.e., IP address and 361 encapsulation information. 363 o The SFPRs are originated by Controllers. One SFPR is originated 364 for each Service Function Path. The SFPR specifies: 366 A. the SPI of the path 368 B. the sequence of SFTs and/or SFIs of which the path consists 370 C. for each such SFT or SFI, the SI that represents it in the 371 identified path. 373 This approach assumes that there is an underlay network that provides 374 connectivity between SFFs and Controllers, and that the SFFs are 375 grouped to form one or more service function overlay networks through 376 which SFPs are built. We assume BGP connectivity between the 377 Controllers and all SFFs within each service function overlay 378 network. 380 When choosing the next SFI in a path, the SFF uses the SPI and SI as 381 well as the SFT to choose among the SFIs, applying, for example, a 382 load balancing algorithm or direct knowledge of the underlay network 383 topology as described in Section 4. 385 The SFF then encapsulates the packet using the encapsulation 386 specified by the SFIR of the selected SFI and forwards the packet. 387 See Figure 1. 389 Thus the SFF can be seen as a portal in the underlay network through 390 which a particular SFI is reached. 392 Figure 1 shows a reference model for the SFC architecture. There are 393 four SFFs (SFF-1 through SFF-4) connected by tunnels across the 394 underlay network. Packets arrive at a Classifier and are channelled 395 along SFPs to destinations reachable through SFF-4. 397 SFF-1 and SFF-4 each have one instance of one SF attached (SFa and 398 SFe). SFF-2 has two types of SF attached: there is one instance of 399 one (SFc), and three instances of the other (SFb). SFF-3 has just 400 one instance of an SF (SFd), but it in this case the type of SFd is 401 the same type as SFb (SFTx). 403 This figure demonstrates how load balancing can be achieved by 404 creating several SFPs that satisfy the same SFC. Suppose an SFC 405 needs to include SFa, an SF of type SFTx, and SFc. A number of SFPs 406 can be constructed using any instance of SFb or using SFd. Load 407 balancing may be applied at two places: 409 o The Classifier may distribute different flows onto different SFPs 410 to share the load in the network and across SFIs. 412 o SFF-2 may distribute different flows (on the same SFP) to 413 different instances of SFb to share the processing load. 415 Note that, for convenience and clarity, Figure 1 shows only a few 416 tunnels between SFFs. There could be a full mesh of such tunnels, or 417 more likely, a selection of tunnels connecting key SFFs to enable the 418 construction of SFPs and to balance load and traffic in the network. 420 Packets 421 | | | 422 ------------ 423 | | 424 | Classifier | 425 | | 426 ------+----- 427 | 428 ---+--- --------- ------- 429 | | Tunnel | | | | 430 | SFF-1 |===============| SFF-2 |=========| SFF-4 | 431 | | | | | | 432 | | -+-----+- | | 433 | | ,,,,,,,,,,,,,,/,, \ | | 434 | | ' .........../. ' ..\...... | | 435 | | ' : SFb / : ' : \ SFc : | | 436 | | ' : ---+- : ' : --+-- : | | 437 | | ' : -| SFI | : ' : | SFI | : | | 438 | | ' : -| ----- : ' : ----- : | | 439 | | ' : | ----- : ' ......... | | 440 | | ' : ----- : ' | | 441 | | ' ............. ' | |--- Dests 442 | | ' ' | |--- Dests 443 | | ' ......... ' | | 444 | | ' : ----- : ' | | 445 | | ' : | SFI | : ' | | 446 | | ' : --+-- : ' | | 447 | | ' :SFd | : ' | | 448 | | ' ....|.... ' | | 449 | | ' | ' | | 450 | | ' SFTx | ' | | 451 | | ',,,,,,,,|,,,,,,,,' | | 452 | | | | | 453 | | ---+--- | | 454 | | | | | | 455 | |======| SFF-3 |====================| | 456 ---+--- | | ---+--- 457 | ------- | 458 ....|.... ....|.... 459 : | SFa: : | SFe: 460 : --+-- : : --+-- : 461 : | SFI | : : | SFI | : 462 : ----- : : ----- : 463 ......... ......... 465 Figure 1: The SFC Architecture Reference Model 467 As previously noted, [RFC8300] makes it clear that the mechanisms it 468 defines are intended for use within a single provider's operational 469 domain. This reduces the requirements on the control plane function. 471 3. BGP SFC Routes 473 This document defines a new AFI/SAFI for BGP, known as "SFC", with an 474 NLRI that is described in this section. 476 The format of the SFC NLRI is shown in Figure 2. 478 +---------------------------------------+ 479 | Route Type (2 octets) | 480 +---------------------------------------+ 481 | Length (2 octets) | 482 +---------------------------------------+ 483 | Route Type specific (variable) | 484 +---------------------------------------+ 486 Figure 2: The Format of the SFC NLRI 488 The Route Type field determines the encoding of the rest of the route 489 type specific SFC NLRI. 491 The Length field indicates the length in octets of the route type 492 specific field of the SFC NLRI. 494 This document defines the following Route Types: 496 1. Service Function Instance Route (SFIR) 498 2. Service Function Path Route (SFPR) 500 A Service Function Instance Route (SFIR) is used to identify an SFI. 501 A Service Function Path Route (SFPR) defines a sequence of Service 502 Functions (each of which has at least one instance advertised in an 503 SFIR) that form an SFP. 505 The detailed encoding and procedures for these Route Types are 506 described in subsequent sections. 508 The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol 509 Extensions [RFC4760] with an Address Family Identifier (AFI) of TBD1 510 and a Subsequent Address Family Identifier (SAFI) of TBD2. The NLRI 511 field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC 512 NLRI, encoded as specified above. 514 In order for two BGP speakers to exchange SFC NLRIs, they MUST use 515 BGP Capabilities Advertisements to ensure that they both are capable 516 of properly processing such NLRIs. This is done as specified in 517 [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI 518 of TBD1 and a SAFI of TBD2. 520 The nexthop field of the MP_REACH_NLRI attribute of the SFC NLRI MUST 521 be set to loopback address of the advertising SFF. 523 3.1. Service Function Instance Route (SFIR) 525 Figure 3 shows the Route Type specific NLRI of the SFIR. 527 +--------------------------------------------+ 528 | Route Distinguisher (RD) (8 octets) | 529 +--------------------------------------------+ 530 | Service Function Type (2 octets) | 531 +--------------------------------------------+ 533 Figure 3: SFIR Route Type specific NLRI 535 Per [RFC4364] the RD field comprises a two byte Type field and a six 536 byte Value field. If two SFIRs are originated from different 537 administrative domains, they MUST have different RDs. In particular, 538 SFIRs from different VPNs (for different service function overlay 539 networks) MUST have different RDs, and those RDs MUST be different 540 from any non-VPN SFIRs. 542 The Service Function Type identifies the functions/features of 543 service function can offer, e.g., classifier, firewall, load 544 balancer, etc. There may be several SFIs that can perform a given 545 Service Function. Each node hosting an SFI MUST originate an SFIR 546 for each type of SF that it hosts, and it may advertise an SFIR for 547 each instance of each type of SF. The minimal advertisement allows 548 construction of valid SFPs and leaves the selection of SFIs to the 549 local SFF; the detailed advertisement may have scaling concerns, but 550 allows a Controller that constructs an SFP to make an explicit choice 551 of SFI. 553 Note that a node may advertise all SFIs of one SFT in one shot using 554 normal BGP Update packing. That is, all of the SFIRs in an Update 555 share a common Tunnel Encapsulation and RT attribute. See also 556 Section 3.2.1. 558 The SFIR representing a given SFI will contain an NLRI with RD field 559 set to an RD as specified above, and with SFT field set to identify 560 that SFI's Service Function Type. The values for the SFT field are 561 taken from a registry administered by IANA (see Section 10). A BGP 562 Update containing one or more SFIRs MUST also include a Tunnel 563 Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data 564 packet needs to be sent to an SFI identified in one of the SFIRs, it 565 will be encapsulated as specified by the Tunnel Encapsulation 566 attribute, and then transmitted through the underlay network. 568 Note that the Tunnel Encapsulation attribute MUST contain sufficient 569 information to allow the advertising SFF to identify the overlay or 570 VPN network which a received packet is transiting. This is because 571 the [SPI, SI] in a received packet is specific to a particular 572 overlay or VPN network. 574 3.1.1. SFIR Pool Identifier Extended Community 576 This document defines a new transitive extended community of type 577 TBD6 with Sub-Type 0x00 called the SFIR Pool Identifier extended 578 community. It MAY be included in SFIR advertisements, and is used to 579 indicate the identity of a pool of SFIRs to which an SFIR belongs. 580 Since an SFIR may be a member of multiple pools, multiple of these 581 extended communities may be present on a single SFIR advertisement. 583 SFIR pools allow SFIRs to be grouped for any purpose. Possible uses 584 include control plane scalability and stability. A pool identifier 585 may be included in an SFPR to indicate a set of SFIs that are 586 acceptable at a specific point on an SFP (see Section 3.2.1.3 and 587 Section 4.3). 589 The SFIR Pool Identifier extended community is encoded in 8 octets as 590 shown in Figure 4. 592 +--------------------------------------------+ 593 | Type = TBD6 (1 octet) | 594 +--------------------------------------------+ 595 | Sub-Type = 0x00 (1 octet) | 596 +--------------------------------------------+ 597 | SFIR Pool Identifier Value (6 octets) | 598 +--------------------------------------------+ 600 Figure 4: The SFIR Pool Identifier Extended Community 602 The SFIR Pool Identifier Value is encoded in a 6 octet field in 603 network byte order, and is a globally unique value. This means that 604 pool identifiers need to be centrally managed, which is consistent 605 with the assignment of SFIs to pools. 607 3.1.2. MPLS Mixed Swapping/Stacking Extended Community 609 This document defines a new transitive extended community of type 610 TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking 611 Labels. The community is encoded as shown in Figure 5. It contains 612 a pair of MPLS labels: an SFC Context Label and an SF Label as 613 described in [RFC8595]. Each label is 20 bits encoded in a 3-octet 614 (24 bit) field with 4 trailing bits that MUST be set to zero. 616 +--------------------------------------------+ 617 | Type = TBD7 (1 octet) | 618 +--------------------------------------------| 619 | Sub-Type = 0x00 (1 octet) | 620 +--------------------------------------------| 621 | SFC Context Label (3 octets) | 622 +--------------------------------------------| 623 | SF Label (3 octets) | 624 +--------------------------------------------+ 626 Figure 5: The MPLS Mixed Swapping/Stacking Extended Community 628 Note that it is assumed that each SFF has one or more globally unique 629 SFC Context Labels and that the context label space and the SPI 630 address space are disjoint. 632 If an SFF supports SFP Traversal with an MPLS Label Stack it MUST 633 include this extended community with the SFIRs that it advertises. 635 See Section 7.6 for a description of how this extended community is 636 used. 638 3.2. Service Function Path Route (SFPR) 640 Figure 6 shows the Route Type specific NLRI of the SFPR. 642 +-----------------------------------------------+ 643 | Route Distinguisher (RD) (8 octets) | 644 +-----------------------------------------------+ 645 | Service Path Identifier (SPI) (3 octets) | 646 +-----------------------------------------------+ 648 Figure 6: SFPR Route Type Specific NLRI 650 Per [RFC4364] the RD field comprises a two byte Type field and a six 651 byte Value field. All SFPs MUST be associated with different RDs. 652 The association of an SFP with an RD is determined by provisioning. 653 If two SFPRs are originated from different Controllers they MUST have 654 different RDs. Additionally, SFPRs from different VPNs (i.e., in 655 different service function overlay networks) MUST have different RDs, 656 and those RDs MUST be different from any non-VPN SFPRs. 658 The Service Path Identifier is defined in [RFC8300] and is the value 659 to be placed in the Service Path Identifier field of the NSH header 660 of any packet sent on this Service Function Path. It is expected 661 that one or more Controllers will originate these routes in order to 662 configure a service function overlay network. 664 The SFP is described in a new BGP Path attribute, the SFP attribute. 665 Section 3.2.1 shows the format of that attribute. 667 3.2.1. The SFP Attribute 669 [RFC4271] defines the BGP Path attribute. This document introduces a 670 new Optional Transitive Path attribute called the SFP attribute with 671 value TBD3 to be assigned by IANA. The first SFP attribute MUST be 672 processed and subsequent instances MUST be ignored. 674 The common fields of the SFP attribute are set as follows: 676 o Optional bit is set to 1 to indicate that this is an optional 677 attribute. 679 o The Transitive bit is set to 1 to indicate that this is a 680 transitive attribute. 682 o The Extended Length bit is set according to the length of the SFP 683 attribute as defined in [RFC4271]. 685 o The Attribute Type Code is set to TBD3. 687 The content of the SFP attribute is a series of Type-Length-Value 688 (TLV) constructs. Each TLV may include sub-TLVs. All TLVs and sub- 689 TLVs have a common format that is: 691 o Type: A single octet indicating the type of the SFP attribute TLV. 692 Values are taken from the registry described in Section 10.3. 694 o Length: A two octet field indicating the length of the data 695 following the Length field counted in octets. 697 o Value: The contents of the TLV. 699 The formats of the TLVs defined in this document are shown in the 700 following sections. The presence rules and meanings are as follows. 702 o The SFP attribute contains a sequence of zero or more Association 703 TLVs. That is, the Association TLV is OPTIONAL. Each Association 704 TLV provides an association between this SFPR and another SFPR. 705 Each associated SFPR is indicated using the RD with which it is 706 advertised (we say the SFPR-RD to avoid ambiguity). 708 o The SFP attribute contains a sequence of one or more Hop TLVs. 709 Each Hop TLV contains all of the information about a single hop in 710 the SFP. 712 o Each Hop TLV contains an SI value and a sequence of one or more 713 SFT TLVs. Each SFT TLV contains an SFI reference for each 714 instance of an SF that is allowed at this hop of the SFP for the 715 specific SFT. Each SFI is indicated using the RD with which it is 716 advertised (we say the SFIR-RD to avoid ambiguity). 718 Section 6 of [RFC4271] describes the handling of malformed BGP 719 attributes, or those that are in error in some way. [RFC7606] 720 revises BGP error handling specifically for the for UPDATE message, 721 provides guidelines for the authors of documents defining new 722 attributes, and revises the error handling procedures for a number of 723 existing attributes. This document introduces the SFP attribute and 724 so defines error handling as follows: 726 o When parsing a message, an unknown Attribute Type code or a length 727 that suggests that the attribute is longer than the remaining 728 message is treated as a malformed message and the "treat-as- 729 withdraw" approach used as per [RFC7606]. 731 o When parsing a message that contains an SFP attribute, the 732 following cases constitute errors: 734 1. Optional bit is set to 0 in SFP attribute. 736 2. Transitive bit is set to 0 in SFP attribute. 738 3. Unknown TLV type field found in SFP attribute. 740 4. TLV length that suggests the TLV extends beyond the end of the 741 SFP attribute. 743 5. Association TLV contains an unknown SFPR-RD. 745 6. No Hop TLV found in the SFP attribute. 747 7. No sub-TLV found in a Hop TLV. 749 8. Unknown SFIR-RD found in a Hop TLV. 751 o The errors listed above are treated as follows: 753 1., 2., 6., 7.: The attribute MUST be treated as malformed and 754 the "treat-as-withdraw" approach used as per [RFC7606]. 756 3.: Unknown TLVs SHOULD be ignored, and message processing SHOULD 757 continue. 759 4.: Treated as a malformed message and the "treat-as-withdraw" 760 approach used as per [RFC7606] 762 5., 8.: The absence of an RD with which to correlate is nothing 763 more than a soft error. The receiver SHOULD store the 764 information from the SFP attribute until a corresponding 765 advertisement is received. 767 3.2.1.1. The Association TLV 769 The Association TLV is an optional TLV in the SFP attribute. It MAY 770 be present multiple times. Each occurrence provides an association 771 with another SFP as advertised in another SFPR. The format of the 772 Association TLV is shown in Figure 7 774 +--------------------------------------------+ 775 | Type = 1 (1 octet) | 776 +--------------------------------------------| 777 | Length (2 octets) | 778 +--------------------------------------------| 779 | Association Type (1 octet) | 780 +--------------------------------------------| 781 | Associated SFPR-RD (8 octets) | 782 +--------------------------------------------| 783 | Associated SPI (3 octets) | 784 +--------------------------------------------+ 786 Figure 7: The Format of the Association TLV 788 The fields are as follows: 790 Type is set to 1 to indicate an Association TLV. 792 Length indicates the length in octets of the Association Type and 793 Associated SFPR-RD fields. The value of the Length field is 12. 795 The Association Type field indicate the type of association. The 796 values are tracked in an IANA registry (see Section 10.4). Only 797 one value is defined in this document: type 1 indicates 798 association of two unidirectional SFPs to form a bidirectional 799 SFP. An SFP attribute SHOULD NOT contain more than one 800 Association TLV with Association Type 1: if more than one is 801 present, the first one MUST be processed and subsequent instances 802 MUST be ignored. Note that documents that define new Association 803 Types must also define the presence rules for Association TLVs of 804 the new type. 806 The Associated SFPR-RD contains the RD of the associated SFP as 807 advertised in an SFPR. 809 The Associated SPI contains the SPI of the associated SFP as 810 advertised in an SFPR. 812 Association TLVs with unknown Association Type values SHOULD be 813 ignored. Association TLVs that contain an Associated SFPR-RD value 814 equal to the RD of the SFPR in which they are contained SHOULD be 815 ignored. If the Associated SPI is not equal to the SPI advertised in 816 the SFPR indicated by the Associated SFPR-RD then the Association TLV 817 SHOULD be ignored. 819 Note that when two SFPRs reference each other using the Association 820 TLV, one SFPR advertisement will be received before the other. 821 Therefore, processing of an association MUST NOT be rejected simply 822 because the Associated SFPR-RD is unknown. 824 Further discussion of correlation of SFPRs is provided in 825 Section 7.1. 827 3.2.1.2. The Hop TLV 829 There is one Hop TLV in the SFP attribute for each hop in the SFP. 830 The format of the Hop TLV is shown in Figure 8. At least one Hop TLV 831 MUST be present in an SFP attribute. 833 +--------------------------------------------+ 834 | Type = 2 (1 octet) | 835 +--------------------------------------------| 836 | Length (2 octets) | 837 +--------------------------------------------| 838 | Service Index (1 octet) | 839 +--------------------------------------------| 840 | Hop Details (variable) | 841 +--------------------------------------------+ 843 Figure 8: The Format of the Hop TLV 845 The fields are as follows: 847 Type is set to 2 to indicate a Hop TLV. 849 Length indicates the length in octets of the Service Index and Hop 850 Details fields. 852 The Service Index is defined in [RFC8300] and is the value found 853 in the Service Index field of the NSH header that an SFF will use 854 to lookup to which next SFI a packet is to be sent. 856 The Hop Details field consists of a sequence of one or more sub- 857 TLVs. 859 Each hop of the SFP may demand that a specific type of SF is 860 executed, and that type is indicated in sub-TLVs of the Hop TLV. At 861 least one sub-TLV MUST be present. This provides a list of which 862 types of SF are acceptable at a specific hop, and for each type it 863 allows a degree of control to be imposed on the choice of SFIs of 864 that particular type. 866 If no Hop TLV is present in an SFP Attribute, it is a malformed 867 attribute 869 3.2.1.3. The SFT TLV 871 The SFT TLV MAY be included in the list of sub-TLVs of the Hop TLV. 872 The format of the SFT TLV is shown in Figure 9. The TLV contains a 873 list of SFIR-RD values each taken from the advertisement of an SFI. 874 Together they form a list of acceptable SFIs of the indicated type. 876 +--------------------------------------------+ 877 | Type = 3 (1 octet) | 878 +--------------------------------------------| 879 | Length (2 octets) | 880 +--------------------------------------------| 881 | Service Function Type (2 octets) | 882 +--------------------------------------------| 883 | SFIR-RD List (variable) | 884 +--------------------------------------------+ 886 Figure 9: The Format of the SFT TLV 888 The fields are as follows: 890 Type is set to 3 to indicate an SFT TLV. 892 Length indicates the length in octets of the Service Function Type 893 and SFIR-RD List fields. 895 The Service Function Type value indicates the category (type) of 896 SF that is to be executed at this hop. The types are as 897 advertised for the SFs supported by the SFFs. SFT values in the 898 range 1-31 are Special Purpose SFT values and have meanings 899 defined by the documents that describe them - the value 'Change 900 Sequence' is defined in Section 6.1 of this document. 902 The hop description is further qualified beyond the specification 903 of the SFTs by listing, for each SFT in each hop, the SFIs that 904 may be used at the hop. The SFIs are identified using the SFIR- 905 RDs from the advertisements of the SFIs in the SFIRs. Note that 906 if the list contains one or more SFIR Pool Identifiers, then for 907 each the SFIR-RD list is effectively expanded to include the SFIR- 908 RD of each SFIR advertised with that SFIR Pool Identifier. An 909 SFIR-RD of value zero has special meaning as described in 910 Section 5. Each entry in the list is eight octets long, and the 911 number of entries in the list can be deduced from the value of the 912 Length field. 914 3.2.1.4. MPLS Swapping/Stacking TLV 916 The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub- 917 TLV that is OPTIONAL in the Hop TLV and is used when the data 918 representation is MPLS (see Section 7.5). When present it indicates 919 to the Classifier imposing an MPLS label stack that the current hop 920 is to use an {SFC Context Label, SF label} rather than an {SPI, SF} 921 label pair. See Section 7.6 for more details. 923 3.2.1.5. SFP Traversal With MPLS Label Stack TLV 925 The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero 926 length sub-TLV that can be carried in the SFP Attribute and indicates 927 to the Classifier and the SFFs on the SFP that an MPLS label stack 928 with label swapping/stacking is to be used for packets traversing the 929 SFP. All of the SFF specified at each the SFP's hops MUST have 930 advertised an MPLS Mixed Swapping/Stacking Extended Community (see 931 Section 3.1.2) for the SFP to be considered usable. 933 3.2.2. General Rules For The SFP Attribute 935 It is possible for the same SFI, as described by an SFIR, to be used 936 in multiple SFPRs. 938 When two SFPRs have the same SPI but different SFPR-RDs there can be 939 three cases: 941 o Two or more Controllers are originating SFPRs for the same SFP. 942 In this case the content of the SFPRs is identical and the 943 duplication is to ensure receipt and to provide Controller 944 redundancy. 946 o There is a transition in content of the advertised SFP and the 947 advertisements may originate from one or more Controllers. In 948 this case the content of the SFPRs will be different. 950 o The reuse of an SPI may result from a configuration error. 952 In all cases, there is no way for the receiving SFF to know which 953 SFPR to process, and the SFPRs could be received in any order. At 954 any point in time, when multiple SFPRs have the same SPI but 955 different SFPR-RDs, the SFF MUST use the SFPR with the numerically 956 lowest SFPR-RD. The SFF SHOULD log this occurrence to assist with 957 debugging. 959 Furthermore, a Controller that wants to change the content of an SFP 960 is RECOMMENDED to use a new SPI and so create a new SFP onto which 961 the Classifiers can transition packet flows before the SFPR for the 962 old SFP is withdrawn. This avoids any race conditions with SFPR 963 advertisements. 965 Additionally, a Controller SHOULD NOT re-use an SPI after it has 966 withdrawn the SFPR that used it until at least a configurable amount 967 of time has passed. This timer SHOULD have a default of one hour. 969 4. Mode of Operation 971 This document describes the use of BGP as a control plane to create 972 and manage a service function overlay network. 974 4.1. Route Targets 976 The main feature introduced by this document is the ability to create 977 multiple service function overlay networks through the use of Route 978 Targets (RTs) [RFC4364]. 980 Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. 981 The RT carried by a particular SFIR or SFPR is determined by the 982 provisioning of the route's originator. 984 Every node in a service function overlay network is configured with 985 one or more import RTs. Thus, each SFF will import only the SFPRs 986 with matching RTs allowing the construction of multiple service 987 function overlay networks or the instantiation of Service Function 988 Chains within an L3VPN or EVPN instance (see Section 7.3). An SFF 989 that has a presence in multiple service function overlay networks 990 (i.e., imports more than one RT) will usually maintain separate 991 forwarding state for each overlay network. 993 4.2. Service Function Instance Routes 995 The SFIR (see Section 3.1) is used to advertise the existence and 996 location of a specific Service Function Instance and consists of: 998 o The RT as just described. 1000 o A Service Function Type (SFT) that is the type of service function 1001 that is provided (such as "firewall"). 1003 o A Route Distinguisher (RD) that is unique to a specific instance 1004 of a service function. 1006 4.3. Service Function Path Routes 1008 The SFPR (see Section 3.2) describes a specific path of a Service 1009 Function Chain. The SFPR contains the Service Path Identifier (SPI) 1010 used to identify the SFP in the NSH in the data plane. It also 1011 contains a sequence of Service Indexes (SIs). Each SI identifies a 1012 hop in the SFP, and each hop is a choice between one of more SFIs. 1014 As described in this document, each Service Function Path Route is 1015 identified in the service function overlay network by an RD and an 1016 SPI. The SPI is unique within a single VPN instance supported by the 1017 underlay network. 1019 The SFPR advertisement comprises: 1021 o An RT as described in Section 4.1. 1023 o A tuple that identifies the SFPR 1025 * An RD that identifies an advertisement of an SFPR. 1027 * The SPI that uniquely identifies this path within the VPN 1028 instance distinguished by the RD. This SPI also appears in the 1029 NSH. 1031 o A series of Service Indexes. Each SI is used in the context of a 1032 particular SPI and identifies one or more SFs (distinguished by 1033 their SFTs) and for each SF a set of SFIs that instantiate the SF. 1034 The values of the SI indicate the order in which the SFs are to be 1035 executed in the SFP that is represented by the SPI. 1037 o The SI is used in the NSH to identify the entries in the SFP. 1038 Note that the SI values have meaning only relative to a specific 1039 path. They have no semantic other than to indicate the order of 1040 Service Functions within the path and are assumed to be 1041 monotonically decreasing from the start to the end of the path 1042 [RFC8300]. 1044 o Each Service Index is associated with a set of one or more Service 1045 Function Instances that can be used to provide the indexed Service 1046 Function within the path. Each member of the set comprises: 1048 * The RD used in an SFIR advertisement of the SFI. 1050 * The SFT that indicates the type of function as used in the same 1051 SFIR advertisement of the SFI. 1053 This may be summarized as follows where the notations "SFPR-RD" and 1054 "SFIR-RD" are used to distinguish the two different RDs: 1056 RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } } 1058 Where: 1060 RT: Route Target 1062 SFPR-RD: The Route Descriptor of the Service Function Path Route 1063 advertisement 1064 SPI: Service Path Identifier used in the NSH 1066 m: The number of hops in the Service Function Path 1068 n: The number of choices of Service Function Type for a specific 1069 hop 1071 p: The number of choices of Service Function Instance for given 1072 Service Function Type in a specific hop 1074 SI: Service Index used in the NSH to indicate a specific hop 1076 SFT: The Service Function Type used in the same advertisement of 1077 the Service Function Instance Route 1079 SFIR-RD: The Route Descriptor used in an advertisement of the 1080 Service Function Instance Route 1082 That is, there can be multiple SFTs at a given hop as described in 1083 Section 5. 1085 Note that the values of SI are from the set {255, ..., 1} and are 1086 monotonically decreasing within the SFP. SIs MUST appear in order 1087 within the SFPR (i.e., monotonically decreasing) and MUST NOT appear 1088 more than once. Gaps MAY appear in the sequence as described in 1089 Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any 1090 previous instance of the SFPR (same SFPR-RD and SPI) to be discarded. 1092 Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR 1093 Pool identifiers, then in the above expression, 'p' is the sum of the 1094 number of individual SFIR-RD values and the sum for each SFIR Pool 1095 Identifier of the number of SFIRs advertised with that SFIR Pool 1096 Identifier. I.e., the list of SFIR-RD values is effectively expanded 1097 to include the SFIR-RD of each SFIR advertised with each SFIR Pool 1098 Identifier in the SFIR-RD list. 1100 The choice of SFI is explained further in Section 5. Note that an 1101 SFIR-RD value of zero has special meaning as described in that 1102 Section. 1104 4.4. Classifier Operation 1106 As shown in Figure 1, the Classifier is a component that is used to 1107 assign packets to an SFP. 1109 The Classifier is responsible for determining to which packet flow a 1110 packet belongs. The mechanism it uses to achieve that classification 1111 is out of scope of this document, but might include inspection of the 1112 packet header. The Classifier has been instructed (by the Controller 1113 or through some other configuration mechanism) which flows are to be 1114 assigned to which SFPs, and so it can impose an NSH on each packet 1115 and initialize the NSH with the SPI of the selected SFP and the SI of 1116 its first hop. 1118 4.5. Service Function Forwarder Operation 1120 Each packet sent to an SFF is transmitted encapsulated in an NSH. 1121 The NSH includes an SPI and SI: the SPI indicates the SFPR 1122 advertisement that announced the Service Function Path; the tuple 1123 SPI/SI indicates a specific hop in a specific path and maps to the 1124 RD/SFT of a particular SFIR advertisement. 1126 When an SFF gets an SFPR advertisement it will first determine 1127 whether to import the route by examining the RT. If the SFPR is 1128 imported the SFF then determines whether it is on the SFP by looking 1129 for its own SFIR-RDs in the SFPR. For each occurrence in the SFP, 1130 the SFF creates forwarding state for incoming packets and forwarding 1131 state for outgoing packets that have been processed by the specified 1132 SFI. 1134 The SFF creates local forwarding state for packets that it receives 1135 from other SFFs. This state makes the association between the SPI/SI 1136 in the NSH of the received packet and one or more specific local SFIs 1137 as identified by the SFIR-RD/SFT. If there are multiple local SFIs 1138 that match this is because a single advertisement was made for a set 1139 of equivalent SFIs and the SFF may use local policy (such as load 1140 balancing) to determine to which SFI to forward a received packet. 1142 The SFF also creates next hop forwarding state for packets received 1143 back from the local SFI that need to be forwarded to the next hop in 1144 the SFP. There may be a choice of next hops as described in 1145 Section 4.3. The SFF could install forwarding state for all 1146 potential next hops, or it could choose to only install forwarding 1147 state to a subset of the potential next hops. If a choice is made 1148 then it will be as described in Section 5. 1150 The installed forwarding state may change over time reacting to 1151 changes in the underlay network and the availability of particular 1152 SFIs. Note that the forwarding state describes how one SFF send 1153 packets to another SFF, but not how those packets are routed through 1154 the underlay network. SFFs may be connected by tunnels across the 1155 underlay, or packets may be sent addressed to the next SFF and routed 1156 through the underlay. In any case, transmission across the underlay 1157 requires encapsulation of packets with a header for transport in the 1158 underlay network. 1160 Note that SFFs only create and store forwarding state for the SFPs on 1161 which they are included. They do not retain state for all SFPs 1162 advertised. 1164 An SFF may also install forwarding state to support looping, jumping, 1165 and branching. The protocol mechanism for explicit control of 1166 looping, jumping, and branching uses a specific reserved SFT value at 1167 a given hop of an SFPR and is described in Section 6.1. 1169 4.5.1. Processing With 'Gaps' in the SI Sequence 1171 The behavior of an SF as described in [RFC8300] is to decrement the 1172 value of the SI field in the NSH by one before returning a packet to 1173 the local SFF for further processing. This means that there is a 1174 good reason to assume that the SFP is composed of a series of SFs 1175 each indicated by an SI value one less than the previous. 1177 However, there is an advantage to having non-successive SIs in an 1178 SPI. Consider the case where an SPI needs to be modified by the 1179 insertion or removal of an SF. In the latter case this would lead to 1180 a "gap" in the sequence of SIs, and in the former case, this could 1181 only be achieved if a gap already existed into which the new SF with 1182 its new SI value could be inserted. Otherwise, all "downstream" SFs 1183 would need to be renumbered. 1185 Now, of course, such renumbering could be performed, but would lead 1186 to a significant disruption to the SFC as all the SFFs along the SFP 1187 were "reprogrammed". Thus, to achieve dynamic modification of an SFP 1188 (and even, in-service modification) it is desirable to be able to 1189 make these modifications without changing the SIs of the elements 1190 that were present before the modification. This will produce much 1191 more consistent/predictable behavior during the convergence period 1192 where otherwise the change would need to be fully propagated. 1194 Another approach says that any change to an SFP simply creates a new 1195 SFP that can be assigned a new SPI. All that would be needed would 1196 be to give a new instruction to the Classifier and traffic would be 1197 switched to the new SFP that contains the new set of SFs. This 1198 approach is practical, but neglects to consider that the SFP may be 1199 referenced by other SFPs (through "branch" instructions) and used by 1200 many Classifiers. In those cases the corresponding configuration 1201 resulting from a change in SPI may have wide ripples and give scope 1202 for errors that are hard to trace. 1204 Therefore, while this document requires that the SI values in an SFP 1205 are monotonic decreasing, it makes no assumption that the SI values 1206 are sequential. Configuration tools may apply that rule, but they 1207 are not required to. To support this, an SFF SHOULD process as 1208 follows when it receives a packet: 1210 o If the SI indicates a known entry in the SFP, the SFF MUST process 1211 the packet as normal, looking up the SI and determining to which 1212 local SFI to deliver the packet. 1214 o If the SI does not match an entry in the SFP, the SFF MUST reduce 1215 the SI value to the next (smaller) value present in the SFP and 1216 process the packet using that SI. 1218 o If there is no smaller SI (i.e., if the end of the SFP has been 1219 reached) the SFF MUST treat the SI value as invalid as described 1220 in [RFC8300]. 1222 This makes the bevahior described in this document a superset of the 1223 function in [RFC8300]. That is, an implementation that strictly 1224 follows RFC 8300 in performing SI decrements in units of one, is 1225 perfectly in line with the mechanisms defined in this document. 1227 SFF implementations MAY choose to only support contiguous SI values 1228 in an SFP. Such an implementation will not support receiving an SI 1229 value that is not present in the SFP and will discard the packets as 1230 described in [RFC8300]. 1232 5. Selection within Service Function Paths 1234 As described in Section 2 the SPI/SI in the NSH passed back from an 1235 SFI to the SFF may leave the SFF with a choice of next hop SFTs, and 1236 a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, 1237 and the SI indicates an entry in that SFPR. Each entry in an SFPR is 1238 a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of 1239 these, identify the SFF that supports the chosen SFI, and send the 1240 packet to that next hop SFF. 1242 The choice be may offered for load balancing across multiple SFIs, or 1243 for discrimination between different actions necessary at a specific 1244 hop in the SFP. Different SFT values may exist at a given hop in an 1245 SFP to support several cases: 1247 o There may be multiple instances of similar service functions that 1248 are distinguished by different SFT values. For example, firewalls 1249 made by vendor A and vendor B may need to be identified by 1250 different SFT values because, while they have similar 1251 functionality, their behavior is not identical. Then, some SFPs 1252 may limit the choice of SF at a given hop by specifying the SFT 1253 for vendor A, but other SFPs might not need to control which 1254 vendor's SF is used and so can indicate that either SFT can be 1255 used. 1257 o There may be an obvious branch needed in an SFP such as the 1258 processing after a firewall where admitted packets continue along 1259 the SFP, but suspect packets are diverted to a "penalty box". In 1260 this case, the next hop in the SFP will be indicated with two 1261 different SFT values. 1263 In the typical case, the SFF chooses a next hop SFF by looking at the 1264 set of all SFFs that support the SFs identified by the SI (that set 1265 having been advertised in individual SFIR advertisements), finding 1266 the one or more that are "nearest" in the underlay network, and 1267 choosing between next hop SFFs using its own load-balancing 1268 algorithm. 1270 An SFI may influence this choice process by passing additional 1271 information back along with the packet and NSH. This information may 1272 influence local policy at the SFF to cause it to favor a next hop SFF 1273 (perhaps selecting one that is not nearest in the underlay), or to 1274 influence the load-balancing algorithm. 1276 This selection applies to the normal case, but also applies in the 1277 case of looping, jumping, and branching (see Section 6). 1279 Suppose an SFF in a particular service overlay network (identified by 1280 a particular import RT, RT-z) needs to forward an NSH-encapsulated 1281 packet whose SPI is SPI-x and whose SI is SI-y. It does the 1282 following: 1284 1. It looks for an installed SFPR that carries RT-z and that has 1285 SPI-x in its NLRI. If there is none, then such packets cannot be 1286 forwarded. 1288 2. From the SFP attribute of that SFPR, it finds the Hop TLV with SI 1289 value set to SI-y. If there is no such Hop TLV, then such 1290 packets cannot be forwarded. 1292 3. It then finds the "relevant" set of SFIRs by going through the 1293 list of SFT TLVs contained in the Hop TLV as follows: 1295 A. An SFIR is relevant if it carries RT-z, the SFT in its NLRI 1296 matches the SFT value in one of the SFT TLVs, and the RD 1297 value in its NLRI matches an entry in the list of SFIR-RDs in 1298 that SFT TLV. 1300 B. If an entry in the SFIR-RD list of an SFT TLV contains the 1301 value zero, then an SFIR is relevant if it carries RT-z and 1302 the SFT in its NLRI matches the SFT value in that SFT TLV. 1303 I.e., any SFIR in the service function overlay network 1304 defined by RT-z and with the correct SFT is relevant. 1306 Each of the relevant SFIRs identifies a single SFI, and contains a 1307 Tunnel Encapsulation attribute that specifies how to send a packet to 1308 that SFI. For a particular packet, the SFF chooses a particular SFI 1309 from the set of relevant SFIRs. This choice is made according to 1310 local policy. 1312 A typical policy might be to figure out the set of SFIs that are 1313 closest, and to load balance among them. But this is not the only 1314 possible policy. 1316 Thus, at any point in time when an SFF selects its next hop, it 1317 chooses from the intersection of the set of next hop RDs contained in 1318 the SFPR and the RDs contained in its local set of SFIRs. If the 1319 intersection is null, the SFPR is unusable. Similarly, when this 1320 condition obtains the originator of the SFPR SHOULD either withdraw 1321 the SFPR or re-advertise it with a new set of RDs for the affected 1322 hop. 1324 6. Looping, Jumping, and Branching 1326 As described in Section 2 an SFI or an SFF may cause a packet to 1327 "loop back" to a previous SF on a path in order that a sequence of 1328 functions may be re-executed. This is simply achieved by replacing 1329 the SI in the NSH with a higher value instead of decreasing it as 1330 would normally be the case to determine the next hop in the path. 1332 Section 2 also describes how an SFI or an SFF may cause a packets to 1333 "jump forward" to an SF on a path that is not the immediate next SF 1334 in the SFP. This is simply achieved by replacing the SI in the NSH 1335 with a lower value than would be achieved by decreasing it by the 1336 normal amount. 1338 A more complex option to move packets from one SFP to another is 1339 described in [RFC8300] and Section 2 where it is termed "branching". 1340 This mechanism allows an SFI or SFF to make a choice of downstream 1341 treatments for packets based on local policy and output of the local 1342 SF. Branching is achieved by changing the SPI in the NSH to indicate 1343 the new path and setting the SI to indicate the point in the path at 1344 which the packets enter. 1346 Note that the NSH does not include a marker to indicate whether a 1347 specific packet has been around a loop before. Therefore, the use of 1348 NSH metadata may be required in order to prevent infinite loops. 1350 6.1. Protocol Control of Looping, Jumping, and Branching 1352 If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT 1353 value "Change Sequence" (see Section 10) then this is an indication 1354 that the SFF may make a loop, jump, or branch according to local 1355 policy and information returned by the local SFI. 1357 In this case, the SPI and SI of the next hop is encoded in the eight 1358 bytes of an entry in the SFIR-RD list as follows: 1360 3 bytes SPI 1362 2 bytes SI 1364 3 bytes Reserved (SHOULD be set to zero and ignored) 1366 If the SI in this encoding is not part of the SFPR indicated by the 1367 SPI in this encoding, then this is an explicit error that SHOULD be 1368 detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT 1369 cause any forwarding state to be installed in the SFF and packets 1370 received with the SPI that indicates this SFPR SHOULD be silently 1371 discarded. 1373 If the SPI in this encoding is unknown, the SFF SHOULD NOT install 1374 any forwarding state for this SFPR, but MAY hold the SFPR pending 1375 receipt of another SFPR that does use the encoded SPI. 1377 If the SPI matches the current SPI for the path, this is a loop or 1378 jump. In this case, if the SI is greater than to the current SI it 1379 is a loop. If the SPI matches and the SI is less than the next SI, 1380 it is a jump. 1382 If the SPI indicates anther path, this is a branch and the SI 1383 indicates the point at which to enter that path. 1385 The Change Sequence SFT is just another SFT that may appear in a set 1386 of SFI/SFT tuples within an SI and is selected as described in 1387 Section 5. 1389 Note that Special Purpose SFTs MUST NOT be advertised in SFIRs. 1391 6.2. Implications for Forwarding State 1393 Support for looping and jumping requires that the SFF has forwarding 1394 state established to an SFF that provides access to an instance of 1395 the appropriate SF. This means that the SFF must have seen the 1396 relevant SFIR advertisements and known that it needed to create the 1397 forwarding state. This is a matter of local configuration and 1398 implementation: for example, an implementation could be configured to 1399 install forwarding state for specific looping/jumping. 1401 Support for branching requires that the SFF has forwarding state 1402 established to an SFF that provides access to an instance of the 1403 appropriate entry SF on the other SFP. This means that the SFF must 1404 have seen the relevant SFIR and SFPR advertisements and known that it 1405 needed to create the forwarding state. This is a matter of local 1406 configuration and implementation: for example, an implementation 1407 could be configured to install forwarding state for specific 1408 branching (identified by SPI and SI). 1410 7. Advanced Topics 1412 This section highlights several advanced topics introduced elsewhere 1413 in this document. 1415 7.1. Correlating Service Function Path Instances 1417 It is often useful to create bidirectional SFPs to enable packet 1418 flows to traverse the same set of SFs, but in the reverse order. 1419 However, packets on SFPs in the data plane (per [RFC8300]) do not 1420 contain a direction indicator, so each direction must use a different 1421 SPI. 1423 As described in Section 3.2.1.1 an SFPR can contain one or more 1424 correlators encoded in Association TLVs. If the Association Type 1425 indicates "Bidirectional SFP" then the SFP advertised in the SFPR is 1426 one direction of a bidirectional pair of SFPs where the other in the 1427 pair is advertised in the SFPR with RD as carried in the Associated 1428 SFPR-RD field of the Association TLV. The SPI carried in the 1429 Associated SPI field of the Association TLV provides a cross-check 1430 against the SPI advertised in the SFPR with RD as carried in the 1431 Associated SFPR-RD field of the Association TLV. 1433 As noted in Section 3.2.1.1 SFPRs reference each other one SFPR 1434 advertisement will be received before the other. Therefore 1435 processing of an association will require that the first SFPR is not 1436 rejected simply because the Associated SFPR-RD it carries is unknown. 1437 However, the SFP defined by the first SFPR is valid and SHOULD be 1438 available for use as a unidirectional SFP even in the absence of an 1439 advertisement of its partner. 1441 Furthermore, in error cases where SFPR-a associates with SFPR-b, but 1442 SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs 1443 cannot be formed, the individual SFPs are still valid and SHOULD be 1444 available for use as unidirectional SFPs. An implementation SHOULD 1445 log this situation because it represents a Controller error. 1447 Usage of a bidirectional SFP may be programmed into the Classifiers 1448 by the Controller. Alternatively, a Classifier may look at incoming 1449 packets on a bidirectional packet flow, extract the SPI from the 1450 received NSH, and look up the SFPR to find the reverse direction SFP 1451 to use when it sends packets. 1453 See Section 8 for an example of how this works. 1455 7.2. Considerations for Stateful Service Functions 1457 Some service functions are stateful. That means that they build and 1458 maintain state derived from configuration or from the packet flows 1459 that they handle. In such cases it can be important or necessary 1460 that all packets from a flow continue to traverse the same instance 1461 of a service function so that the state can be leveraged and does not 1462 need to be regenerated. 1464 In the case of bidirectional SFPs, it may be necessary to traverse 1465 the same instances of a stateful service function in both directions. 1466 A firewall is a good example of such a service function. 1468 This issue becomes a concern where there are multiple parallel 1469 instances of a service function and a determination of which one to 1470 use could normally be left to the SFF as a load-balancing or local 1471 policy choice. 1473 For the forward direction SFP, the concern is that the same choice of 1474 service function is made for all packets of a flow under normal 1475 network conditions. It may be possible to guarantee that the load 1476 balancing functions applied in the SFFs are stable and repeatable, 1477 but a controller that constructs SFPs might not want to trust to 1478 this. The controller can, in these cases, build a number of more 1479 specific SFPs each traversing a specific instance of the stateful 1480 SFs. In this case, the load balancing choice can be left up to the 1481 Classifier. Thus the Classifier selects which instance of a stateful 1482 SF is used by a particular flow by selecting the SFP that the flow 1483 uses. 1485 For bidirectional SFPs where the same instance of a stateful SF must 1486 be traversed in both directions, it is not enough to leave the choice 1487 of service function instance as a local choice even if the load 1488 balancing is stable because coordination would be required between 1489 the decision points in the forward and reverse directions and this 1490 may be hard to achieve in all cases except where it is the same SFF 1491 that makes the choice in both directions. 1493 Note that this approach necessarily increases the amount of SFP state 1494 in the network (i.e., there are more SFPs). It is possible to 1495 mitigate this effect by careful construction of SFPs built from a 1496 concatenation of other SFPs. 1498 Section 8.9 includes some simple examples of SFPs for stateful 1499 service functions. 1501 7.3. VPN Considerations and Private Service Functions 1503 Likely deployments include reserving specific instances of Service 1504 Functions for specific customers or allowing customers to deploy 1505 their own Service Functions within the network. Building Service 1506 Functions in such environments requires that suitable identifiers are 1507 used to ensure that SFFs distinguish which SFIs can be used and which 1508 cannot. 1510 This problem is similar to how VPNs are supported and is solved in a 1511 similar way. The RT field is used to indicate a set of Service 1512 Functions from which all choices must be made. 1514 7.4. Flow Spec for SFC Classifiers 1516 [RFC5575] and [I-D.ietf-idr-rfc5575bis] define a set of BGP routes 1517 that can be used to identify the packets in a given flow using fields 1518 in the header of each packet, and a set of actions, encoded as 1519 extended communities, that can be used to disposition those packets. 1520 This document enables the use of these mechanisms by SFC Classifiers 1521 by defining a new action extended community called "Flow Spec for SFC 1522 Classifiers" identified by the value TBD4. Note that other action 1523 extended communities MUST NOT be present at the same time: the 1524 inclusion of the "Flow Spec for SFC Classifiers" action extended 1525 community along with any other action MUST be treated as an error 1526 which SHOULD result in the Flow Specification UPDATE message being 1527 handled as Treat-as-withdraw according to [RFC7606] Section 2. 1529 This extended community is encoded as an 8-octet value, as shown in 1530 Figure 10. 1532 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 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Type=0x80 | Sub-Type=TBD4 | SPI | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | SPI (cont.) | SI | SFT | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 Figure 10: The Format of the Flow Spec for SFC Classifiers Extended 1540 Community 1542 The extended community contains the Service Path Identifier (SPI), 1543 Service Index (SI), and Service Function Type (SFT) as defined 1544 elsewhere in this document. Thus, each action extended community 1545 defines the entry point (not necessarily the first hop) into a 1546 specific service function path. This allows, for example, different 1547 flows to enter the same service function path at different points. 1549 Note that a given Flow Spec update according to [RFC5575] and 1550 [I-D.ietf-idr-rfc5575bis] may include multiple of these action 1551 extended communities, and that if a given action extended community 1552 does not contain an installed SFPR with the specified {SPI, SI, SFT} 1553 it MUST NOT be used for dispositioning the packets of the specified 1554 flow. 1556 The normal case of packet classification for SFC will see a packet 1557 enter the SFP at its first hop. In this case the SI in the extended 1558 community is superfluous and the SFT may also be unnecessary. To 1559 allow these cases to be handled, a special meaning is assigned to a 1560 Service Index of zero (not a valid value) and an SFT of zero (a 1561 reserved value in the registry - see Section 10.5). 1563 o If an SFC Classifiers Extended Community is received with SI = 0 1564 then it means that the first hop of the SFP indicated by the SPI 1565 MUST be used. 1567 o If an SFC Classifiers Extended Community is received with SFT = 0 1568 then there are two sub-cases: 1570 * If there is a choice of SFT in the hop indicated by the value 1571 of the SI (including SI = 0) then SFT = 0 means there is a free 1572 choice according to local policy of which SFT to use). 1574 * If there is no choice of SFT in the hop indicated by the value 1575 of SI, then SFT = 0 means that the value of the SFT at that hop 1576 as indicated in the SFPR for the indicated SPI MUST be used. 1578 One of the filters that the Flow Spec may describe is the VPN to 1579 which the traffic belongs. Additionally, note that to put the 1580 indicated SPI into context when multiple SFC overlays are present in 1581 one network, each FlowSpec update MUST be tagged with the route 1582 target of the overlay or VPN network for which it is intended. 1584 7.5. Choice of Data Plane SPI/SI Representation 1586 This document ties together the control and data planes of an SFC 1587 overlay network through the use of the SPI/SI which is nominally 1588 carried in the NSH of a given packet. However, in order to handle 1589 situations in which the NSH is not ubiquitously deployed, it is also 1590 possible to use alternative data plane representations of the SPI/SI 1591 by carrying the identical semantics in other protocol fields such as 1592 MPLS labels [RFC8595]. 1594 This document defines a new sub-TLV for the Tunnel Encapsulation 1595 attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub- 1596 TLV MAY be present in each Tunnel TLV contained in a Tunnel 1597 Encapsulation attribute when the attribute is carried by an SFIR. 1598 The value field of this sub-TLV is a two octet field of flags, each 1599 of which describes how the originating SFF expects to see the SPI/SI 1600 represented in the data plane for packets carried in the tunnels 1601 described by the Tunnel TLV. 1603 The following bits are defined by this document: 1605 Bit 0: If this bit is set the NSH is to be used to carry the SPI/SI 1606 in the data plane. 1608 Bit 1: If this bit is set two labels in an MPLS label stack are to 1609 be used as described in Section 7.5.1. 1611 If a given Tunnel TLV does not contain an SPI/SI Representation sub- 1612 TLV then it MUST be processed as if such a sub-TLV is present with 1613 Bit 0 set and no other bits set. That is, the absence of the sub-TLV 1614 SHALL be interpreted to mean that the NSH is to be used. 1616 If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with 1617 value field that has no flag set then the tunnel indicated by the 1618 Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given 1619 Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit 0 1620 and bit 1 set then the tunnel indicated by the Tunnel TLV MUST NOT be 1621 used for forwarding SFC packets. The meaning and rules for presence 1622 of other bits is to be defined in future documents, but 1623 implementations of this specification MUST set other bits to zero and 1624 ignore them on receipt. 1626 If a given Tunnel TLV contains more than one SPI/SI Representation 1627 sub-TLV then the first one MUST be considered and subsequent 1628 instances MUST be ignored. 1630 Note that the MPLS representation of the logical NSH may be used even 1631 if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be 1632 used to carry other encodings of the logical NSH (specifically, the 1633 NSH itself). It is a requirement that both ends of a tunnel over the 1634 underlay network know that the tunnel is used for SFC and know what 1635 form of NSH representation is used. The signaling mechanism 1636 described here allows coordination of this information. 1638 7.5.1. MPLS Representation of the SPI/SI 1640 If bit 1 is set in the in the SPI/SI Representation sub-TLV then 1641 labels in the MPLS label stack are used to indicate SFC forwarding 1642 and processing instructions to achieve the semantics of a logical 1643 NSH. The label stack is encoded as shown in [RFC8595]. 1645 7.6. MPLS Label Swapping/Stacking Operation 1647 When a classifier constructs an MPLS label stack for an SFP it starts 1648 with that SFP' last hop. If the last hop requires an {SPI, SI} label 1649 pair for label swapping, it pushes the SI (set to the SI value of the 1650 last hop) and the SFP's SPI onto the MPLS label stack. If the last 1651 hop requires a {context label, SFI label} label pair for label 1652 stacking it selects a specific SFIR and pushes that SFIR's SFI label 1653 and context label onto the MPLS label stack. 1655 The classifier then moves sequentially back through the SFP one hop 1656 at a time. For each hop, if the hop requires an {SPI, SI]} and there 1657 is an {SPI, SI} at the top of the MPLS label stack, the SI is set to 1658 the SI value of the current hop. If there is not an {SPI, SI} at the 1659 top of the MPLS label stack, it pushes the SI (set to the SI value of 1660 the current hop) and the SFP's SPI onto the MPLS label stack. 1662 If the hop requires a {context label, SFI label}, it selects a 1663 specific SFIR and pushes that SFIR's SFI label and context label onto 1664 the MPLS label stack. 1666 7.7. Support for MPLS-Encapsulated NSH Packets 1668 [RFC8596] describes how to transport SFC packets using the NSH over 1669 an MPLS transport network. Signaling MPLS encapsulation of SFC 1670 packets using the NSH is also supported by this document by using the 1671 "BGP Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10 1672 (representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation 1673 Attribute Sub-TLVs" registry defined in [I-D.ietf-idr-tunnel-encaps], 1674 and also using the "SFP Traversal With MPLS Label Stack TLV" and the 1675 "SPI/SI Representation sub-TLV" with bit 0 set and bit 1 cleared. 1677 In this case the MPLS label stack constructed by the SFF to forward a 1678 packet to the next SFF on the SFP will consist of the labels needed 1679 to reach that SFF, and if label stacking is used it will also include 1680 the labels advertised in the MPLS Label Stack sub-TLV and the labels 1681 remaining in the stack needed to traverse the remainder of the SFP. 1683 8. Examples 1685 Assume we have a service function overlay network with four SFFs 1686 (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the 1687 underlay network as follows: 1689 SFF1 192.0.2.1 1690 SFF2 192.0.2.2 1691 SFF3 192.0.2.3 1692 SFF4 192.0.2.4 1694 Each SFF provides access to some SFIs from the four Service Function 1695 Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows: 1697 SFF1 SFT=41 and SFT=42 1698 SFF2 SFT=41 and SFT=43 1699 SFF3 SFT=42 and SFT=44 1700 SFF4 SFT=43 and SFT=44 1702 The service function network also contains a Controller with address 1703 198.51.100.1. 1705 This example service function overlay network is shown in Figure 11. 1707 -------------- 1708 | Controller | 1709 | 198.51.100.1 | ------ ------ ------ ------ 1710 -------------- | SFI | | SFI | | SFI | | SFI | 1711 |SFT=41| |SFT=42| |SFT=41| |SFT=43| 1712 ------ ------ ------ ------ 1713 \ / \ / 1714 --------- --------- 1715 ---------- | SFF1 | | SFF2 | 1716 Packet --> | | |192.0.2.1| |192.0.2.2| 1717 Flows --> |Classifier| --------- --------- -->Dest 1718 | | --> 1719 ---------- --------- --------- 1720 | SFF3 | | SFF4 | 1721 |192.0.2.3| |192.0.2.4| 1722 --------- --------- 1723 / \ / \ 1724 ------ ------ ------ ------ 1725 | SFI | | SFI | | SFI | | SFI | 1726 |SFT=42| |SFT=44| |SFT=43| |SFT=44| 1727 ------ ------ ------ ------ 1729 Figure 11: Example Service Function Overlay Network 1731 The SFFs advertise routes to the SFIs they support. So we see the 1732 following SFIRs: 1734 RD = 192.0.2.1:1, SFT = 41 1735 RD = 192.0.2.1:2, SFT = 42 1736 RD = 192.0.2.2:1, SFT = 41 1737 RD = 192.0.2.2:2, SFT = 43 1738 RD = 192.0.2.3:7, SFT = 42 1739 RD = 192.0.2.3:8, SFT = 44 1740 RD = 192.0.2.4:5, SFT = 43 1741 RD = 192.0.2.4:6, SFT = 44 1743 Note that the addressing used for communicating between SFFs is taken 1744 from the Tunnel Encapsulation attribute of the SFIR and not from the 1745 SFIR-RD. 1747 8.1. Example Explicit SFP With No Choices 1749 Consider the following SFPR. 1751 SFP1: RD = 198.51.100.1:101, SPI = 15, 1752 [SI = 255, SFT = 41, RD = 192.0.2.1:1], 1753 [SI = 250, SFT = 43, RD = 192.0.2.2:2] 1755 The Service Function Path consists of an SF of type 41 located at 1756 SFF1 followed by an SF of type 43 located at SFF2. This path is 1757 fully explicit and each SFF is offered no choice in forwarding packet 1758 along the path. 1760 SFF1 will receive packets on the path from the Classifier and will 1761 identify the path from the SPI (15). The initial SI will be 255 and 1762 so SFF1 will deliver the packets to the SFI for SFT 41. 1764 When the packets are returned to SFF1 by the SFI the SI will be 1765 decreased to 250 for the next hop. SFF1 has no flexibility in the 1766 choice of SFF to support the next hop SFI and will forward the packet 1767 to SFF2 which will send the packets to the SFI that supports SFT 43 1768 before forwarding the packets to their destinations. 1770 8.2. Example SFP With Choice of SFIs 1772 SFP2: RD = 198.51.100.1:102, SPI = 16, 1773 [SI = 255, SFT = 41, RD = 192.0.2.1:1], 1774 [SI = 250, SFT = 43, {RD = 192.0.2.2:2, 1775 RD = 192.0.2.4:5 } ] 1777 In this example the path also consists of an SF of type 41 located at 1778 SFF1 and this is followed by an SF of type 43, but in this case the 1779 SI = 250 contains a choice between the SFI located at SFF2 and the 1780 SFI located at SFF4. 1782 SFF1 will receive packets on the path from the Classifier and will 1783 identify the path from the SPI (16). The initial SI will be 255 and 1784 so SFF1 will deliver the packets to the SFI for SFT 41. 1786 When the packets are returned to SFF1 by the SFI the SI will be 1787 decreased to 250 for the next hop. SFF1 now has a choice of next hop 1788 SFF to execute the next hop in the path. It can either forward 1789 packets to SFF2 or SFF4 to execute a function of type 43. It uses 1790 its local load balancing algorithm to make this choice. The chosen 1791 SFF will send the packets to the SFI that supports SFT 43 before 1792 forwarding the packets to their destinations. 1794 8.3. Example SFP With Open Choice of SFIs 1796 SFP3: RD = 198.51.100.1:103, SPI = 17, 1797 [SI = 255, SFT = 41, RD = 192.0.2.1:1], 1798 [SI = 250, SFT = 44, RD = 0] 1800 In this example the path also consists of an SF of type 41 located at 1801 SFF1 and this is followed by an SI with an RD of zero and SF of type 1802 44. This means that a choice can be made between any SFF that 1803 supports an SFI of type 44. 1805 SFF1 will receive packets on the path from the Classifier and will 1806 identify the path from the SPI (17). The initial SI will be 255 and 1807 so SFF1 will deliver the packets to the SFI for SFT 41. 1809 When the packets are returned to SFF1 by the SFI the SI will be 1810 decreased to 250 for the next hop. SFF1 now has a free choice of 1811 next hop SFF to execute the next hop in the path selecting between 1812 all SFFs that support SFs of type 44. Looking at the SFIRs it has 1813 received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. 1814 SFF1 uses its local load balancing algorithm to make this choice. 1815 The chosen SFF will send the packets to the SFI that supports SFT 44 1816 before forwarding the packets to their destinations. 1818 8.4. Example SFP With Choice of SFTs 1820 SFP4: RD = 198.51.100.1:104, SPI = 18, 1821 [SI = 255, SFT = 41, RD = 192.0.2.1:1], 1822 [SI = 250, {SFT = 43, RD = 192.0.2.2:2, 1823 SFT = 44, RD = 192.0.2.3:8 } ] 1825 This example provides a choice of SF type in the second hop in the 1826 path. The SI of 250 indicates a choice between SF type 43 located 1827 through SF2 and SF type 44 located at SF3. 1829 SFF1 will receive packets on the path from the Classifier and will 1830 identify the path from the SPI (18). The initial SI will be 255 and 1831 so SFF1 will deliver the packets to the SFI for SFT 41. 1833 When the packets are returned to SFF1 by the SFI the SI will be 1834 decreased to 250 for the next hop. SFF1 now has a free choice of 1835 next hop SFF to execute the next hop in the path selecting between 1836 all SFF2 that support an SF of type 43 and SFF3 that supports an SF 1837 of type 44. These may be completely different functions that are to 1838 be executed dependent on specific conditions, or may be similar 1839 functions identified with different type identifiers (such as 1840 firewalls from different vendors). SFF1 uses its local policy and 1841 load balancing algorithm to make this choice, and may use additional 1842 information passed back from the local SFI to help inform its 1843 selection. The chosen SFF will send the packets to the SFI that 1844 supports the chose SFT before forwarding the packets to their 1845 destinations. 1847 8.5. Example Correlated Bidirectional SFPs 1849 SFP5: RD = 198.51.100.1:105, SPI = 19, 1850 Assoc-Type = 1, Assoc-RD = 198.51.100.1:106, Assoc-SPI = 20, 1851 [SI = 255, SFT = 41, RD = 192.0.2.1:1], 1852 [SI = 250, SFT = 43, RD = 192.0.2.2:2] 1854 SFP6: RD = 198.51.100.1:106, SPI = 20, 1855 Assoc-Type = 1, Assoc-RD = 198.51.100.1:105, Assoc-SPI = 19, 1856 [SI = 254, SFT = 43, RD = 192.0.2.2:2], 1857 [SI = 249, SFT = 41, RD = 192.0.2.1:1] 1859 This example demonstrates correlation of two SFPs to form a 1860 bidirectional SFP as described in Section 7.1. 1862 Two SFPRs are advertised by the Controller. They have different SPIs 1863 (19 and 20) so they are known to be separate SFPs, but they both have 1864 Association TLVs with Association Type set to 1 indicating 1865 bidirectional SFPs. Each has an Associated SFPR-RD fields containing 1866 the value of the other SFPR-RD to correlated the two SFPs as a 1867 bidirectional pair. 1869 As can be seen from the SFPRs in this example, the paths are 1870 symmetric: the hops in SFP5 appear in the reverse order in SFP6. 1872 8.6. Example Correlated Asymmetrical Bidirectional SFPs 1873 SFP7: RD = 198.51.100.1:107, SPI = 21, 1874 Assoc-Type = 1, Assoc-RD = 198.51.100.1:108, Assoc-SPI = 22, 1875 [SI = 255, SFT = 41, RD = 192.0.2.1:1], 1876 [SI = 250, SFT = 43, RD = 192.0.2.2:2] 1878 SFP8: RD = 198.51.100.1:108, SPI = 22, 1879 Assoc-Type = 1, Assoc-RD = 198.51.100.1:107, Assoc-SPI = 21, 1880 [SI = 254, SFT = 44, RD = 192.0.2.4:6], 1881 [SI = 249, SFT = 41, RD = 192.0.2.1:1] 1883 Asymmetric bidirectional SFPs can also be created. This example 1884 shows a pair of SFPs with distinct SPIs (21 and 22) that are 1885 correlated in the same way as in the example in Section 8.5. 1887 However, unlike in that example, the SFPs are different in each 1888 direction. Both paths include a hop of SF type 41, but SFP7 includes 1889 a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF 1890 type 44 supported at SFF4. 1892 8.7. Example Looping in an SFP 1894 SFP9: RD = 198.51.100.1:109: SPI = 23, 1895 [SI = 255, SFT = 41, RD = 192.0.2.1:1], 1896 [SI = 250, SFT = 44, RD = 192.0.2.4:5], 1897 [SI = 245, SFT = 1, RD = {SPI=23, SI=255, Rsv=0}], 1898 [SI = 245, SFT = 42, RD = 192.0.2.3:7] 1900 Looping and jumping are described in Section 6. This example shows 1901 an SFP that contains an explicit loop-back instruction that is 1902 presented as a choice within an SFP hop. 1904 The first two hops in the path (SI = 255 and SI = 250) are normal. 1905 That is, the packets will be delivered to SFF1 and SFF4 in turn for 1906 execution of SFs of type 41 and 44 respectively. 1908 The third hop (SI = 245) presents SFF4 with a choice of next hop. It 1909 can either forward the packets to SFF3 for an SF of type 42 (the 1910 second choice), or it can loop back. 1912 The loop-back entry in the SFPR for SI = 245 is indicated by the 1913 special purpose SFT value 1 ("Change Sequence"). Within this hop, 1914 the RD is interpreted as encoding the SPI and SI of the next hop (see 1915 Section 6.1. In this case the SPI is 23 which indicates that this is 1916 loop or branch: i.e., the next hop is on the same SFP. The SI is set 1917 to 255: this is a higher number than the current SI (245) indicating 1918 a loop. 1920 SFF4 must make a choice between these two next hops. Either the 1921 packets will be forwarded to SFF3 with the NSH SI decreased to 245 or 1922 looped back to SFF1 with the NSH SI reset to 255. This choice will 1923 be made according to local policy, information passed back by the 1924 local SFI, and details in the packets' metadata that are used to 1925 prevent infinite looping. 1927 8.8. Example Branching in an SFP 1929 SFP10: RD = 198.51.100.1:110, SPI = 24, 1930 [SI = 254, SFT = 42, RD = 192.0.2.3:7], 1931 [SI = 249, SFT = 43, RD = 192.0.2.2:2] 1933 SFP11: RD = 198.51.100.1:111, SPI = 25, 1934 [SI = 255, SFT = 41, RD = 192.0.2.1:1], 1935 [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}] 1937 Branching follows a similar procedure to that for looping (and 1938 jumping) as shown in Section 8.7 however there are two SFPs involved. 1940 SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for 1941 execution of service functions of type 42 and 43 respectively. 1943 SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1 1944 processes the next hop in the path and finds a "Change Sequence" 1945 Special Purpose SFT. The SFIR-RD field includes an SPI of 24 which 1946 indicates SFP10, not the current SFP. The SI in the SFIR-RD is 254, 1947 so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and 1948 send the packets to the appropriate SFF as advertised in the SFPR for 1949 SFP10 (that is, SFF3). 1951 8.9. Examples of SFPs with Stateful Service Functions 1953 This section provides some examples to demonstrate establishing SFPs 1954 when there is a choice of service functions at a particular hop, and 1955 where consistency of choice is required in both directions. The 1956 scenarios that give rise to this requirement are discussed in 1957 Section 7.2. 1959 8.9.1. Forward and Reverse Choice Made at the SFF 1961 Consider the topology shown in Figure 12. There are three SFFs 1962 arranged neatly in a line, and the middle one (SFF2) supports three 1963 SFIs all of SFT 42. These three instances can be used by SFF2 to 1964 load balance so that no one instance is swamped. 1966 ------ ------ ------ ------ ------ 1967 | SFI | | SFIa | | SFIb | | SFIc | | SFI | 1968 |SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43| 1969 ------ ------\ ------ /------ ------ 1970 \ \ | / / 1971 --------- --------- --------- 1972 ---------- | SFF1 | | SFF2 | | SFF3 | 1973 --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> 1974 --> |Classifier| --------- --------- --------- 1975 | | 1976 ---------- 1978 Figure 12: Example Where Choice is Made at the SFF 1980 This leads to the following SFIRs being advertised. 1982 RD = 192.0.2.1:11, SFT = 41 1983 RD = 192.0.2.2:11, SFT = 42 (for SFIa) 1984 RD = 192.0.2.2:12, SFT = 42 (for SFIb) 1985 RD = 192.0.2.2:13, SFT = 42 (for SFIc) 1986 RD = 192.0.2.3:11, SFT = 43 1988 The controller can create a single forward SFP giving SFF2 the choice 1989 of which SFI to use to provide function of SFT 42 as follows. The 1990 load-balancing choice between the three available SFIs is assumed to 1991 be within the capabilities of the SFF and if the SFs are stateful it 1992 is assumed that the SFF knows this and arranges load balancing in a 1993 stable, flow-dependent way. 1995 SFP12: RD = 198.51.100.1:112, SPI = 26, 1996 Assoc-Type = 1, Assoc-RD = 198.51.100.1:113, Assoc-SPI = 27, 1997 [SI = 255, SFT = 41, RD = 192.0.2.1:11], 1998 [SI = 254, SFT = 42, {RD = 192.0.2.2:11, 1999 192.0.2.2:12, 2000 192.0.2.2:13 }], 2001 [SI = 253, SFT = 43, RD = 192.0.2.3:11] 2003 The reverse SFP in this case may also be created as shown below using 2004 association with the forward SFP and giving the load-balancing choice 2005 to SFF2. This is safe, even in the case that the SFs of type 42 are 2006 stateful because SFF2 is doing the load balancing in both directions 2007 and can apply the same algorithm to ensure that packets associated 2008 with the same flow use the same SFI regardless of the direction of 2009 travel. 2011 How an SFF knows that an attached SFI is stateful is is out of scope 2012 of this document. It is assumed that this will form part of the 2013 process by which SFIs are registered as local to SFFs. Section 7.2 2014 provides additional observations about the coordination of the use of 2015 stateful SFIs in the case of bidirectional SFPs. 2017 In general, the problems of load balancing and the selection of the 2018 same SFIs in both directions of a bidirectional SFP can be addressed 2019 by using sufficiently precisely specified SFPs (specifying the exact 2020 SFIs to use) and suitable programming of the Classifiers at each end 2021 of the SFPs to make sure that the matching pair of SFPs are used. 2023 SFP13: RD = 198.51.100.1:113, SPI = 27, 2024 Assoc-Type = 1, Assoc-RD = 198.51.100.1:112, Assoc-SPI = 26, 2025 [SI = 255, SFT = 43, RD = 192.0.2.3:11], 2026 [SI = 254, SFT = 42, {RD = 192.0.2.2:11, 2027 192.0.2.2:12, 2028 192.0.2.2:13 }], 2029 [SI = 253, SFT = 41, RD = 192.0.2.1:11] 2031 8.9.2. Parallel End-to-End SFPs with Shared SFF 2033 The mechanism described in Section 8.9.1 might not be desirable 2034 because of the functional assumptions it places on SFF2 to be able to 2035 load balance with suitable flow identification, stability, and 2036 equality in both directions. Instead, it may be desirable to place 2037 the responsibility for flow classification in the Classifier and let 2038 it determine load balancing with the implied choice of SFIs. 2040 Consider the network graph as shown in Figure 12 and with the same 2041 set of SFIRs as listed in Section 8.9.1. In this case the controller 2042 could specify three forward SFPs with their corresponding associated 2043 reverse SFPs. Each bidirectional pair of SFPs uses a different SFI 2044 for the SF of type 42. The controller can instruct the Classifier 2045 how to place traffic on the three bidirectional SFPs, or can treat 2046 them as a group leaving the Classifier responsible for balancing the 2047 load. 2049 SFP14: RD = 198.51.100.1:114, SPI = 28, 2050 Assoc-Type = 1, Assoc-RD = 198.51.100.1:117, Assoc-SPI = 31, 2051 [SI = 255, SFT = 41, RD = 192.0.2.1:11], 2052 [SI = 254, SFT = 42, RD = 192.0.2.2:11], 2053 [SI = 253, SFT = 43, RD = 192.0.2.3:11] 2055 SFP15: RD = 198.51.100.1:115, SPI = 29, 2056 Assoc-Type = 1, Assoc-RD = 198.51.100.1:118, Assoc-SPI = 32, 2057 [SI = 255, SFT = 41, RD = 192.0.2.1:11], 2058 [SI = 254, SFT = 42, RD = 192.0.2.2:12], 2059 [SI = 253, SFT = 43, RD = 192.0.2.3:11] 2061 SFP16: RD = 198.51.100.1:116, SPI = 30, 2062 Assoc-Type = 1, Assoc-RD = 198.51.100.1:119, Assoc-SPI = 33, 2063 [SI = 255, SFT = 41, RD = 192.0.2.1:11], 2064 [SI = 254, SFT = 42, RD = 192.0.2.2:13], 2065 [SI = 253, SFT = 43, RD = 192.0.2.3:11] 2067 SFP17: RD = 198.51.100.1:117, SPI = 31, 2068 Assoc-Type = 1, Assoc-RD = 198.51.100.1:114, Assoc-SPI = 28, 2069 [SI = 255, SFT = 43, RD = 192.0.2.3:11], 2070 [SI = 254, SFT = 42, RD = 192.0.2.2:11], 2071 [SI = 253, SFT = 41, RD = 192.0.2.1:11] 2073 SFP18: RD = 198.51.100.1:118, SPI = 32, 2074 Assoc-Type = 1, Assoc-RD = 198.51.100.1:115, Assoc-SPI = 29, 2075 [SI = 255, SFT = 43, RD = 192.0.2.3:11], 2076 [SI = 254, SFT = 42, RD = 192.0.2.2:12], 2077 [SI = 253, SFT = 41, RD = 192.0.2.1:11] 2079 SFP19: RD = 198.51.100.1:119, SPI = 33, 2080 Assoc-Type = 1, Assoc-RD = 198.51.100.1:116, Assoc-SPI = 30, 2081 [SI = 255, SFT = 43, RD = 192.0.2.3:11], 2082 [SI = 254, SFT = 42, RD = 192.0.2.2:13], 2083 [SI = 253, SFT = 41, RD = 192.0.2.1:11] 2085 8.9.3. Parallel End-to-End SFPs with Separate SFFs 2087 While the examples in Section 8.9.1 and Section 8.9.2 place the 2088 choice of SFI as subtended from the same SFF, it is also possible 2089 that the SFIs are each subtended from a different SFF as shown in 2090 Figure 13. In this case it is harder to coordinate the choices for 2091 forward and reverse paths without some form of coordination between 2092 SFF1 and SFF3. Therefore it would be normal to consider end-to-end 2093 parallel SFPs as described in Section 8.9.2. 2095 ------ 2096 | SFIa | 2097 |SFT=42| 2098 ------ 2099 ------ | 2100 | SFI | --------- 2101 |SFT=41| | SFF5 | 2102 ------ ..|192.0.2.5|.. 2103 | ..: --------- :.. 2104 ---------.: :.--------- 2105 ---------- | SFF1 | --------- | SFF3 | 2106 --> | |..|192.0.2.1|....| SFF6 |....|192.0.2.3| --> 2107 --> |Classifier| ---------: |192.0.2.6| :--------- 2108 | | : --------- : | 2109 ---------- : | : ------ 2110 : ------ : | SFI | 2111 :.. | SFIb | ..: |SFT=43| 2112 :.. |SFT=42| ..: ------ 2113 : ------ : 2114 :.---------.: 2115 | SFF7 | 2116 |192.0.2.7| 2117 --------- 2118 | 2119 ------ 2120 | SFIc | 2121 |SFT=42| 2122 ------ 2124 Figure 13: Second Example With Parallel End-to-End SFPs 2126 In this case, five SFIRs are advertised as follows: 2128 RD = 192.0.2.1:11, SFT = 41 2129 RD = 192.0.2.5:11, SFT = 42 (for SFIa) 2130 RD = 192.0.2.6:11, SFT = 42 (for SFIb) 2131 RD = 192.0.2.7:11, SFT = 42 (for SFIc) 2132 RD = 192.0.2.3:11, SFT = 43 2134 In this case the controller could specify three forward SFPs with 2135 their corresponding associated reverse SFPs. Each bidirectional pair 2136 of SFPs uses a different SFF and SFI for middle hop (for an SF of 2137 type 42). The controller can instruct the Classifier how to place 2138 traffic on the three bidirectional SFPs, or can treat them as a group 2139 leaving the Classifier responsible for balancing the load. 2141 SFP20: RD = 198.51.100.1:120, SPI = 34, 2142 Assoc-Type = 1, Assoc-RD = 198.51.100.1:123, Assoc-SPI = 37, 2143 [SI = 255, SFT = 41, RD = 192.0.2.1:11], 2144 [SI = 254, SFT = 42, RD = 192.0.2.5:11], 2145 [SI = 253, SFT = 43, RD = 192.0.2.3:11] 2147 SFP21: RD = 198.51.100.1:121, SPI = 35, 2148 Assoc-Type = 1, Assoc-RD = 198.51.100.1:124, Assoc-SPI = 38, 2149 [SI = 255, SFT = 41, RD = 192.0.2.1:11], 2150 [SI = 254, SFT = 42, RD = 192.0.2.6:11], 2151 [SI = 253, SFT = 43, RD = 192.0.2.3:11] 2153 SFP22: RD = 198.51.100.1:122, SPI = 36, 2154 Assoc-Type = 1, Assoc-RD = 198.51.100.1:125, Assoc-SPI = 39, 2155 [SI = 255, SFT = 41, RD = 192.0.2.1:11], 2156 [SI = 254, SFT = 42, RD = 192.0.2.7:11], 2157 [SI = 253, SFT = 43, RD = 192.0.2.3:11] 2159 SFP23: RD = 198.51.100.1:123, SPI = 37, 2160 Assoc-Type = 1, Assoc-RD = 198.51.100.1:120, Assoc-SPI = 34, 2161 [SI = 255, SFT = 43, RD = 192.0.2.3:11], 2162 [SI = 254, SFT = 42, RD = 192.0.2.5:11], 2163 [SI = 253, SFT = 41, RD = 192.0.2.1:11] 2165 SFP24: RD = 198.51.100.1:124, SPI = 38, 2166 Assoc-Type = 1, Assoc-RD = 198.51.100.1:121, Assoc-SPI = 35, 2167 [SI = 255, SFT = 43, RD = 192.0.2.3:11], 2168 [SI = 254, SFT = 42, RD = 192.0.2.6:11], 2169 [SI = 253, SFT = 41, RD = 192.0.2.1:11] 2171 SFP25: RD = 198.51.100.1:125, SPI = 39, 2172 Assoc-Type = 1, Assoc-RD = 198.51.100.1:122, Assoc-SPI = 36, 2173 [SI = 255, SFT = 43, RD = 192.0.2.3:11], 2174 [SI = 254, SFT = 42, RD = 192.0.2.7:11], 2175 [SI = 253, SFT = 41, RD = 192.0.2.1:11] 2177 8.9.4. Parallel SFPs Downstream of the Choice 2179 The mechanism of parallel SFPs demonstrated in Section 8.9.3 is 2180 perfectly functional and may be practical in many environments. 2181 However, there may be scaling concerns because of the large amount of 2182 state (knowledge of SFPs, i.e., SFPR advertisements retained) if 2183 there is a very large amount of choice of SFIs (for example, tens of 2184 instances of the same stateful SF), or if there are multiple choices 2185 of stateful SF along a path. This situation may be mitigated using 2186 SFP fragments that are combined to form the end to end SFPs. 2188 The example presented here is necessarily simplistic, but should 2189 convey the basic principle. The example presented in Figure 14 is 2190 similar to that in Section 8.9.3 but with an additional first hop. 2192 ------ 2193 | SFIa | 2194 |SFT=43| 2195 ------ 2196 ------ ------ | 2197 | SFI | | SFI | --------- 2198 |SFT=41| |SFT=42| | SFF5 | 2199 ------ ------ ..|192.0.2.5|.. 2200 | | ..: --------- :.. 2201 --------- ---------.: :.--------- 2202 ------ | SFF1 | | SFF2 | --------- | SFF3 | 2203 -->|Class-|.|192.0.2.1|.|192.0.2.2|....| SFF6 |....|192.0.2.3|--> 2204 -->| ifier| --------- ---------: |192.0.2.6| :--------- 2205 ------ : --------- : | 2206 : | : ------ 2207 : ------ : | SFI | 2208 :.. | SFIb | ..: |SFT=44| 2209 :.. |SFT=43| ..: ------ 2210 : ------ : 2211 :.---------.: 2212 | SFF7 | 2213 |192.0.2.7| 2214 --------- 2215 | 2216 ------ 2217 | SFIc | 2218 |SFT=43| 2219 ------ 2221 Figure 14: Example With Parallel SFPs Downstream of Choice 2223 The six SFIs are advertised as follows: 2225 RD = 192.0.2.1:11, SFT = 41 2226 RD = 192.0.2.2:11, SFT = 42 2227 RD = 192.0.2.5:11, SFT = 43 (for SFIa) 2228 RD = 192.0.2.6:11, SFT = 43 (for SFIb) 2229 RD = 192.0.2.7:11, SFT = 43 (for SFIc) 2230 RD = 192.0.2.3:11, SFT = 44 2232 SFF2 is the point at which a load balancing choice must be made. So 2233 "tail-end" SFPs are constructed as follows. Each takes in a 2234 different SFF that provides access to an SF of type 43. 2236 SFP26: RD = 198.51.100.1:126, SPI = 40, 2237 Assoc-Type = 1, Assoc-RD = 198.51.100.1:130, Assoc-SPI = 44, 2238 [SI = 255, SFT = 43, RD = 192.0.2.5:11], 2239 [SI = 254, SFT = 44, RD = 192.0.2.3:11] 2241 SFP27: RD = 198.51.100.1:127, SPI = 41, 2242 Assoc-Type = 1, Assoc-RD = 198.51.100.1:131, Assoc-SPI = 45, 2243 [SI = 255, SFT = 43, RD = 192.0.2.6:11], 2244 [SI = 254, SFT = 44, RD = 192.0.2.3:11] 2246 SFP28: RD = 198.51.100.1:128, SPI = 42, 2247 Assoc-Type = 1, Assoc-RD = 198.51.100.1:132, Assoc-SPI = 46, 2248 [SI = 255, SFT = 43, RD = 192.0.2.7:11], 2249 [SI = 254, SFT = 44, RD = 192.0.2.3:11] 2251 Now an end-to-end SFP with load balancing choice can be constructed 2252 as follows. The choice made by SFF2 is expressed in terms of 2253 entering one of the three "tail end" SFPs. 2255 SFP29: RD = 198.51.100.1:129, SPI = 43, 2256 [SI = 255, SFT = 41, RD = 192.0.2.1:11], 2257 [SI = 254, SFT = 42, RD = 192.0.2.2:11], 2258 [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0}, 2259 RD = {SPI=41, SI=255, Rsv=0}, 2260 RD = {SPI=42, SI=255, Rsv=0} } ] 2262 Now, despite the load balancing choice being made other than at the 2263 initial classifier, it is possible for the reverse SFPs to be well- 2264 constructed without any ambiguity. The three reverse paths appear as 2265 follows. 2267 SFP30: RD = 198.51.100.1:130, SPI = 44, 2268 Assoc-Type = 1, Assoc-RD = 198.51.100.1:126, Assoc-SPI = 40, 2269 [SI = 255, SFT = 44, RD = 192.0.2.4:11], 2270 [SI = 254, SFT = 43, RD = 192.0.2.5:11], 2271 [SI = 253, SFT = 42, RD = 192.0.2.2:11], 2272 [SI = 252, SFT = 41, RD = 192.0.2.1:11] 2274 SFP31: RD = 198.51.100.1:131, SPI = 45, 2275 Assoc-Type = 1, Assoc-RD = 198.51.100.1:127, Assoc-SPI = 41, 2276 [SI = 255, SFT = 44, RD = 192.0.2.4:11], 2277 [SI = 254, SFT = 43, RD = 192.0.2.6:11], 2278 [SI = 253, SFT = 42, RD = 192.0.2.2:11], 2279 [SI = 252, SFT = 41, RD = 192.0.2.1:11] 2281 SFP32: RD = 198.51.100.1:132, SPI = 46, 2282 Assoc-Type = 1, Assoc-RD = 198.51.100.1:128, Assoc-SPI = 42, 2283 [SI = 255, SFT = 44, RD = 192.0.2.4:11], 2284 [SI = 254, SFT = 43, RD = 192.0.2.7:11], 2285 [SI = 253, SFT = 42, RD = 192.0.2.2:11], 2286 [SI = 252, SFT = 41, RD = 192.0.2.1:11] 2288 9. Security Considerations 2290 This document inherits all the security considerations discussed in 2291 the documents that specify BGP, the documents that specify BGP 2292 Multiprotocol Extensions, and the documents that define the 2293 attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. For 2294 more information look in [RFC4271], [RFC4760], and 2295 [I-D.ietf-idr-tunnel-encaps]. 2297 Service Function Chaining provides a significant attack opportunity: 2298 packets can be diverted from their normal paths through the network, 2299 can be made to execute unexpected functions, and the functions that 2300 are instantiated in software can be subverted. However, this 2301 specification does not change the existence of Service Function 2302 Chaining and security issues specific to Service Function Chaining 2303 are covered in [RFC7665] and [RFC8300]. 2305 This document defines a control plane for Service Function Chaining. 2306 Clearly, this provides an attack vector for a Service Function 2307 Chaining system as an attack on this control plane could be used to 2308 make the system misbehave. Thus, the security of the BGP system is 2309 critically important to the security of the whole Service Function 2310 Chaining system. The control plane mechanisms are very similar to 2311 those used for BGP/MPLS IP VPNs as described in [RFC4364], and so the 2312 security considerations in that document (Section 23) provide good 2313 guidance for securing SFC systems reliant on this specification. 2314 Section 19 of [RFC7432] also provides useful guidance on the use of 2315 BGP in a similar environment. 2317 Note that a component of an SFC system that uses the procedures 2318 described in this document also requires communications between a 2319 controller and the SFC network elements. This communication covers 2320 instructing the Classifiers using BGP mechanisms (see Section 7.4) 2321 which is covered by BGP security. But it also covers other 2322 mechanisms for programming the Classifier and instructing the SFFs 2323 and SFs (for example, to bind SFs to an SFF, and to cause the 2324 establishment of tunnels between SFFs). This document does not cover 2325 these latter mechanisms and so their security is out of scope, but it 2326 should be noted that these communications provide an attack vector on 2327 the SFC system and so attention must be paid to ensuring that they 2328 are secure. 2330 10. IANA Considerations 2332 10.1. New BGP AF/SAFI 2334 IANA maintains a registry of "Address Family Numbers". IANA is 2335 requested to assign a new Address Family Number from the "Standards 2336 Action" range called "BGP SFC" (TBD1 in this document) with this 2337 document as a reference. 2339 IANA maintains a registry of "Subsequent Address Family Identifiers 2340 (SAFI) Parameters". IANA is requested to assign a new SAFI value 2341 from the "Standards Action" range called "BGP SFC" (TBD2 in this 2342 document) with this document as a reference. 2344 10.2. New BGP Path Attribute 2346 IANA maintains a registry of "Border Gateway Protocol (BGP) 2347 Parameters" with a subregistry of "BGP Path Attributes". IANA is 2348 requested to assign a new Path attribute called "SFP attribute" (TBD3 2349 in this document) with this document as a reference. 2351 10.3. New SFP Attribute TLVs Type Registry 2353 IANA maintains a registry of "Border Gateway Protocol (BGP) 2354 Parameters". IANA is request to create a new subregistry called the 2355 "SFP Attribute TLVs" registry. 2357 Valid values are in the range 0 to 65535. 2359 o Values 0 and 65535 are to be marked "Reserved, not to be 2360 allocated". 2362 o Values 1 through 65534 are to be assigned according to the "First 2363 Come First Served" policy [RFC8126]. 2365 This document should be given as a reference for this registry. 2367 The new registry should track: 2369 o Type 2371 o Name 2373 o Reference Document or Contact 2375 o Registration Date 2377 The registry should initially be populated as follows: 2379 Type | Name | Reference | Date 2380 ------+-------------------------+---------------+--------------- 2381 1 | Association TLV | [This.I-D] | Date-to-be-set 2382 2 | Hop TLV | [This.I-D] | Date-to-be-set 2383 3 | SFT TLV | [This.I-D] | Date-to-be-set 2384 4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set 2385 5 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set 2387 10.4. New SFP Association Type Registry 2389 IANA maintains a registry of "Border Gateway Protocol (BGP) 2390 Parameters". IANA is request to create a new subregistry called the 2391 "SFP Association Type" registry. 2393 Valid values are in the range 0 to 65535. 2395 o Values 0 and 65535 are to be marked "Reserved, not to be 2396 allocated". 2398 o Values 1 through 65534 are to be assigned according to the "First 2399 Come First Served" policy [RFC8126]. 2401 This document should be given as a reference for this registry. 2403 The new registry should track: 2405 o Association Type 2407 o Name 2408 o Reference Document or Contact 2410 o Registration Date 2412 The registry should initially be populated as follows: 2414 Association Type | Name | Reference | Date 2415 -----------------+--------------------+------------+--------------- 2416 1 | Bidirectional SFP | [This.I-D] | Date-to-be-set 2418 10.5. New Service Function Type Registry 2420 IANA is request to create a new top-level registry called "Service 2421 Function Chaining Service Function Types". 2423 Valid values are in the range 0 to 65535. 2425 o Values 0 and 65535 are to be marked "Reserved, not to be 2426 allocated". 2428 o Values 1 through 31 are to be assigned by "Standards Action" 2429 [RFC8126] and are referred to as the Special Purpose SFT values. 2431 o Other values (32 through 65534) are to be assigned according to 2432 the "First Come First Served" policy [RFC8126]. 2434 This document should be given as a reference for this registry. 2436 The new registry should track: 2438 o Value 2440 o Name 2442 o Reference Document or Contact 2444 o Registration Date 2446 The registry should initially be populated as follows: 2448 Value | Name | Reference | Date 2449 ------+-----------------------+---------------+--------------- 2450 1 | Change Sequence | [This.I-D] | Date-to-be-set 2452 10.6. New Generic Transitive Experimental Use Extended Community Sub- 2453 Types 2455 IANA maintains a registry of "Border Gateway Protocol (BGP) 2456 Parameters" with a subregistry of "Generic Transitive Experimental 2457 Use Extended Community Sub-Type". IANA is requested to assign a new 2458 sub-type as follows: 2460 "Flow Spec for SFC Classifiers" (TBD4 in this document) with this 2461 document as the reference. 2463 10.7. New BGP Transitive Extended Community Types 2465 IANA maintains a registry of "Border Gateway Protocol (BGP) 2466 Parameters" with a subregistry of "BGP Transitive Extended Community 2467 Types". IANA is requested to assign new types as follows: 2469 "SFIR Pool Identifier" (TBD6 in this document) with this document 2470 as the reference. 2472 "MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this 2473 document) with this document as the reference. 2475 10.8. SPI/SI Representation 2477 IANA is requested to assign a codepoint from the "BGP Tunnel 2478 Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI 2479 Representation Sub-TLV" (TBD5 in this document) with this document 2480 being the reference. 2482 11. Contributors 2484 Stuart Mackie 2485 Juniper Networks 2487 Email: wsmackie@juinper.net 2489 Keyur Patel 2490 Arrcus, Inc. 2492 Email: keyur@arrcus.com 2494 Avinash Lingala 2495 AT&T 2497 Email: ar977m@att.com 2499 12. Acknowledgements 2501 Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful 2502 comments, and to Joel Halpern for discussions that improved this 2503 document. Yuanlong Jiang provided a useful review and caught some 2504 important issues. Stephane Litkowski did an exceptionally good and 2505 detailed document shepherd review. 2507 Andy Malis contributed text that formed the basis of Section 7.7. 2509 Brian Carpenter and Martin Vigoureux provided useful reviews during 2510 IETF last call. 2512 13. References 2514 13.1. Normative References 2516 [I-D.ietf-idr-rfc5575bis] 2517 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 2518 Bacher, "Dissemination of Flow Specification Rules", 2519 draft-ietf-idr-rfc5575bis-18 (work in progress), November 2520 2019. 2522 [I-D.ietf-idr-tunnel-encaps] 2523 Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel 2524 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 2525 (work in progress), December 2019. 2527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2528 Requirement Levels", BCP 14, RFC 2119, 2529 DOI 10.17487/RFC2119, March 1997, 2530 . 2532 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2533 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2534 DOI 10.17487/RFC4271, January 2006, 2535 . 2537 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2538 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2539 2006, . 2541 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2542 "Multiprotocol Extensions for BGP-4", RFC 4760, 2543 DOI 10.17487/RFC4760, January 2007, 2544 . 2546 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 2547 and D. McPherson, "Dissemination of Flow Specification 2548 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 2549 . 2551 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 2552 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 2553 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2554 2015, . 2556 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2557 Patel, "Revised Error Handling for BGP UPDATE Messages", 2558 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2559 . 2561 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 2562 Chaining (SFC) Architecture", RFC 7665, 2563 DOI 10.17487/RFC7665, October 2015, 2564 . 2566 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2567 Writing an IANA Considerations Section in RFCs", BCP 26, 2568 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2569 . 2571 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2572 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2573 May 2017, . 2575 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 2576 "Network Service Header (NSH)", RFC 8300, 2577 DOI 10.17487/RFC8300, January 2018, 2578 . 2580 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 2581 Forwarding Plane for Service Function Chaining", RFC 8595, 2582 DOI 10.17487/RFC8595, June 2019, 2583 . 2585 [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 2586 "MPLS Transport Encapsulation for the Service Function 2587 Chaining (SFC) Network Service Header (NSH)", RFC 8596, 2588 DOI 10.17487/RFC8596, June 2019, 2589 . 2591 13.2. Informative References 2593 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 2594 Service Function Chaining", RFC 7498, 2595 DOI 10.17487/RFC7498, April 2015, 2596 . 2598 Authors' Addresses 2600 Adrian Farrel 2601 Old Dog Consulting 2603 Email: adrian@olddog.co.uk 2605 John Drake 2606 Juniper Networks 2608 Email: jdrake@juniper.net 2610 Eric Rosen 2611 Juniper Networks 2613 Email: erosen52@gmail.com 2615 Jim Uttaro 2616 AT&T 2618 Email: ju1738@att.com 2620 Luay Jalil 2621 Verizon 2623 Email: luay.jalil@verizon.com