idnits 2.17.1 draft-ietf-bess-nsh-bgp-control-plane-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 21, 2020) is 1337 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 635, but not defined == Missing Reference: 'SI' is mentioned on line 635, but not defined == Missing Reference: 'I-D.darwa' is mentioned on line 2854, but not defined == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-26 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-17 ** Downref: Normative reference to an Informational RFC: RFC 7665 ** Downref: Normative reference to an Informational RFC: RFC 8596 == Outdated reference: A later version (-06) exists of draft-dawra-idr-bgp-ls-sr-service-segments-04 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: February 22, 2021 E. Rosen 6 Juniper Networks 7 J. Uttaro 8 AT&T 9 L. Jalil 10 Verizon 11 August 21, 2020 13 BGP Control Plane for the Network Service Header in Service Function 14 Chaining 15 draft-ietf-bess-nsh-bgp-control-plane-18 17 Abstract 19 This document describes the use of BGP as a control plane for 20 networks that support Service Function Chaining (SFC). The document 21 introduces a new BGP address family called the SFC Address Family 22 Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with 23 two route types. One route type is originated by a node to advertise 24 that it hosts a particular instance of a specified service function. 25 This route type also provides "instructions" on how to send a packet 26 to the hosting node in a way that indicates that the service function 27 has to be applied to the packet. The other route type is used by a 28 Controller to advertise the paths of "chains" of service functions, 29 and to give a unique designator to each such path so that they can be 30 used in conjunction with the Network Service Header defined in RFC 31 8300. 33 This document adopts the SFC architecture described in RFC 7665. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on February 22, 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.1. Overview of Service Function Chaining . . . . . . . . . . 6 73 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8 74 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 12 75 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 13 76 3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 14 77 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 15 78 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 16 79 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 17 80 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 23 81 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 24 82 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 24 83 4.2. Service Function Instance Routes . . . . . . . . . . . . 24 84 4.3. Service Function Path Routes . . . . . . . . . . . . . . 25 85 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 27 86 4.5. Service Function Forwarder Operation . . . . . . . . . . 27 87 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 28 88 5. Selection within Service Function Paths . . . . . . . . . . . 30 89 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 32 90 6.1. Protocol Control of Looping, Jumping, and Branching . . . 32 91 6.2. Implications for Forwarding State . . . . . . . . . . . . 33 92 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 33 93 7.1. Correlating Service Function Path Instances . . . . . . . 34 94 7.2. Considerations for Stateful Service Functions . . . . . . 34 95 7.3. VPN Considerations and Private Service Functions . . . . 35 96 7.4. Flow Specification for SFC Classifiers . . . . . . . . . 36 97 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 38 98 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 39 99 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 39 100 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 39 101 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 102 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 42 103 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 42 104 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 43 105 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 43 106 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 44 107 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 45 108 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 45 109 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 46 110 8.9. Examples of SFPs with Stateful Service Functions . . . . 46 111 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 47 112 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 48 113 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 50 114 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 52 115 8.10. Examples Using IPv6 Addressing . . . . . . . . . . . . . 55 116 8.10.1. Example Explicit SFP With No Choices . . . . . . . . 57 117 8.10.2. Example SFP With Choice of SFIs . . . . . . . . . . 58 118 8.10.3. Example SFP With Open Choice of SFIs . . . . . . . . 58 119 8.10.4. Example SFP With Choice of SFTs . . . . . . . . . . 59 120 9. Security Considerations . . . . . . . . . . . . . . . . . . . 60 121 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 122 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 62 123 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 62 124 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 62 125 10.4. New SFP Association Type Registry . . . . . . . . . . . 63 126 10.5. New Service Function Type Registry . . . . . . . . . . . 64 127 10.6. New Generic Transitive Experimental Use Extended 128 Community Sub-Types . . . . . . . . . . . . . . . . . . 66 129 10.7. New BGP Transitive Extended Community Type . . . . . . . 66 130 10.8. New SFC Extended Community Sub-Types Registry . . . . . 66 131 10.9. SPI/SI Representation . . . . . . . . . . . . . . . . . 67 132 10.10. SFC SPI/SI Representation Flags Registry . . . . . . . . 67 133 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 67 134 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 68 135 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 68 136 13.1. Normative References . . . . . . . . . . . . . . . . . . 68 137 13.2. Informative References . . . . . . . . . . . . . . . . . 70 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 71 140 1. Introduction 142 As described in [RFC7498], the delivery of end-to-end services can 143 require a packet to pass through a series of Service Functions (SFs) 144 (e.g., WAN and application accelerators, Deep Packet Inspection (DPI) 145 engines, firewalls, TCP optimizers, and server load balancers) in a 146 specified order: this is termed "Service Function Chaining" (SFC). 147 There are a number of issues associated with deploying and 148 maintaining service function chaining in production networks, which 149 are described below. 151 Historically, if a packet needed to travel through a particular 152 service chain, the nodes hosting the service functions of that chain 153 were placed in the network topology in such a way that the packet 154 could not reach its ultimate destination without first passing 155 through all the service functions in the proper order. This need to 156 place the service functions at particular topological locations 157 limited the ability to adapt a service function chain to changes in 158 network topology (e.g., link or node failures), network utilization, 159 or offered service load. These topological restrictions on where the 160 service functions can be placed raised the following issues: 162 1. The process of configuring or modifying a service function chain 163 is operationally complex and may require changes to the network 164 topology. 166 2. Alternate or redundant service functions may need to be co- 167 located with the primary service functions. 169 3. When there is more than one path between source and destination, 170 forwarding may be asymmetric and it may be difficult to support 171 bidirectional service function chains using simple routing 172 methodologies and protocols without adding mechanisms for traffic 173 steering or traffic engineering. 175 In order to address these issues, the SFC architecture describes 176 Service Function Chains that are built in their own overlay network 177 (the service function overlay network), coexisting with other overlay 178 networks, over a common underlay network [RFC7665]. A Service 179 Function Chain is a sequence of Service Functions through which 180 packet flows that satisfy specified criteria will pass. 182 This document describes the use of BGP as a control plane for 183 networks that support Service Function Chaining (SFC). The document 184 introduces a new BGP address family called the SFC Address Family 185 Identifier / Subsequent Address Family Identifier (AFI/SAFI) with two 186 route types. One route type is originated by a node to advertise 187 that it hosts a particular instance of a specified service function. 188 This route type also provides "instructions" on how to send a packet 189 to the hosting node in a way that indicates that the service function 190 has to be applied to the packet. The other route type is used by a 191 Controller (a centralized network component responsible for planning 192 and coordinating Service Function Chaining within the network) to 193 advertise the paths of "chains" of service functions, and to give a 194 unique designator to each such path so that they can be used in 195 conjunction with the Network Service Header [RFC8300]. 197 This document adopts the SFC architecture described in [RFC7665]. 199 1.1. Requirements Language 201 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 202 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 203 "OPTIONAL" in this document are to be interpreted as described in BCP 204 14 [RFC2119] [RFC8174] when, and only when, they appear in all 205 capitals, as shown here. 207 1.2. Terminology 209 This document uses the following terms from [RFC7665]: 211 o Bidirectional Service Function Chain 213 o Classifier 215 o Service Function (SF) 217 o Service Function Chain (SFC) 219 o Service Function Forwarder (SFF) 221 o Service Function Instance (SFI) 223 o Service Function Path (SFP) 225 o SFC branching 227 Additionally, this document uses the following terms from [RFC8300]: 229 o Network Service Header (NSH) 231 o Service Index (SI) 233 o Service Path Identifier (SPI) 235 This document introduces the following terms: 237 o Service Function Instance Route (SFIR). A new BGP Route Type 238 advertised by the node that hosts an SFI to describe the SFI and 239 to announce the way to forward a packet to the node through the 240 underlay network. 242 o Service Function Overlay Network. The logical network comprised 243 of Classifiers, SFFs, and SFIs that are connected by paths or 244 tunnels through underlay transport networks. 246 o Service Function Path Route (SFPR). A new BGP Route Type 247 originated by Controllers to advertise the details of each SFP. 249 o Service Function Type (SFT). An indication of the function and 250 features of an SFI. 252 2. Overview 254 This section provides an overview of Service Function Chaining in 255 general, and the control plane defined in this document. After 256 reading this section, readers may find it helpful to look through 257 Section 8 for some simple worked examples. 259 2.1. Overview of Service Function Chaining 261 In [RFC8300] a Service Function Chain (SFC) is an ordered list of 262 Service Functions (SFs). A Service Function Path (SFP) is an 263 indication of which instances of SFs are acceptable to be traversed 264 in an instantiation of an SFC in a service function overlay network. 265 The Service Path Identifier (SPI) is a 24-bit number that identifies 266 a specific SFP, and a Service Index (SI) is an 8-bit number that 267 identifies a specific point in that path. In the context of a 268 particular SFP (identified by an SPI), an SI represents a particular 269 Service Function, and indicates the order of that SF in the SFP. 271 Within the context of a specific SFP, an SI references a set of one 272 or more SFs. Each of those SFs may be supported by one or more 273 Service Function Instances (SFIs). Thus an SI may represent a choice 274 of SFIs of one or more Service Function Types. By deploying multiple 275 SFIs for a single SF, one can provide load balancing and redundancy. 277 A special functional element, called a Classifier, is located at each 278 ingress point to a service function overlay network. It assigns the 279 packets of a given packet flow to a specific Service Function Path. 280 This may be done by comparing specific fields in a packet's header 281 with local policy, which may be customer/network/service specific. 282 The Classifier picks an SFP and sets the SPI accordingly, it then 283 sets the SI to the value of the SI for the first hop in the SFP, and 284 then prepends a Network Services Header (NSH) [RFC8300] containing 285 the assigned SPI/SI to that packet. Note that the Classifier and the 286 node that hosts the first Service Function in a Service Function Path 287 need not be located at the same point in the service function overlay 288 network. 290 Note that the presence of the NSH can make it difficult for nodes in 291 the underlay network to locate the fields in the original packet that 292 would normally be used to constrain equal cost multipath (ECMP) 293 forwarding. Therefore, it is recommended that the node prepending 294 the NSH also provide some form of entropy indicator that can be used 295 in the underlay network. How this indicator is generated and 296 supplied, and how an SFF generates a new entropy indicator when it 297 forwards a packet to the next SFF, are out of scope of this document. 299 The Service Function Forwarder (SFF) receives a packet from the 300 previous node in a Service Function Path, removes the packet's link 301 layer or tunnel encapsulation and hands the packet and the NSH to the 302 Service Function Instance for processing. The SFI has no knowledge 303 of the SFP. 305 When the SFF receives the packet and the NSH back from the SFI it 306 must select the next SFI along the path using the SPI and SI in the 307 NSH and potentially choosing between multiple SFIs (possibly of 308 different Service Function Types) as described in Section 5. In the 309 normal case the SPI remains unchanged and the SI will have been 310 decremented to indicate the next SF along the path. But other 311 possibilities exist if the SF makes other changes to the NSH through 312 a process of re-classification: 314 o The SI in the NSH may indicate: 316 * A previous SF in the path: known as "looping" (see Section 6). 318 * An SF further down the path: known as "jumping" (see also 319 Section 6). 321 o The SPI and the SI may point to an SF on a different SFP: known as 322 "branching" (see also Section 6). 324 Such modifications are limited to within the same service function 325 overlay network. That is, an SPI is known within the scope of 326 service function overlay network. Furthermore, the new SI value is 327 interpreted in the context of the SFP identified by the SPI. 329 As described in [RFC8300], an unknown or invalid SPI is treated as an 330 error and the SFF drops the packet: such errors should be logged, and 331 such logs are subject to rate limits. 333 Also, as described in [RFC8300], an SFF receiving an SI that is 334 unknown in the context of the SPI can reduce the value to the next 335 meaningful SI value in the SFP indicated by the SPI. If no such 336 value exists or if the SFF does not support reducing the SI, the SFF 337 drops the packet and should log the event: such logs are also subject 338 to rate limits. 340 The SFF then selects an SFI that provides the SF denoted by the SPI/ 341 SI, and forwards the packet to the SFF that supports that SFI. 343 [RFC8300] makes it clear that the intended scope is for use within a 344 single provider's operational domain. 346 This document adopts the SFC architecture described in [RFC7665] and 347 adds a control plane to support the functions as described in 348 Section 2.2. An essential component of this solution is the 349 Controller. This is a network component responsible for planning 350 SFPs within the network. It gathers information about the 351 availability of SFIs and SFFs, instructs the control plane about the 352 SFPs to be programmed, and instructs the Classifiers how to assign 353 traffic flows to individual SFPs. 355 2.2. Control Plane Overview 357 To accomplish the function described in Section 2.1, this document 358 introduces the Service Function Type (SFT) that is the category of SF 359 that is supported by an SFF (such as "firewall"). An IANA registry 360 of Service Function Types is introduced in Section 10.5 and is 361 consistent with types used in other work such as 362 [I-D.dawra-idr-bgp-ls-sr-service-segments]. An SFF may support SFs 363 of multiple different SFTs, and may support multiple SFIs of each SF. 365 The registry of SFT values (see Section 10.5) is split into three 366 ranges with assignment policies per [RFC8126]: 368 o The Special Purpose SFT values range is assigned through Standards 369 Action. Values in that range are used for special SFC operations 370 and do not apply to the types of SF that may form part of the SFP. 372 o The First Come First Served range tracks assignments of STF values 373 made by any party that defines an SF type. Reference through an 374 Internet-Draft is desirable, but not required. 376 o The Private Use range is not tracked by IANA and is primarily 377 intended for use in private networks where the meaning of the SFT 378 values is locally tracked and under the control of a local 379 administrator. 381 It is envisaged that the majority of SFT values used will be assigned 382 from the First Come First Served space in the registry. This will 383 ensure interoperability especially in situations where software and 384 hardware from different vendors is deployed in the same networks, or 385 when networks are merged. However, operators of private networks may 386 choose to develop their own SFs and manage the configuration and 387 operation of their network through their own list of SFT values. 389 This document also introduces a new BGP AFI/SAFI (values to be 390 assigned by IANA) for "SFC Routes". Two SFC Route Types are defined 391 by this document: the Service Function Instance Route (SFIR), and the 392 Service Function Path Route (SFPR). As detailed in Section 3, the 393 route type is indicated by a sub-field in the Network Layer 394 Reachability Information (NLRI). 396 o The SFIR is advertised by the node that provides access to the 397 service function instance (i.e., the SFF). The SFIR describes a 398 particular instance of a particular Service Function (i.e., an 399 SFI) and the way to forward a packet to it through the underlay 400 network, i.e., IP address and encapsulation information. 402 o The SFPRs are originated by Controllers. One SFPR is originated 403 for each Service Function Path. The SFPR specifies: 405 A. the SPI of the path 407 B. the sequence of SFTs and/or SFIs of which the path consists 409 C. for each such SFT or SFI, the SI that represents it in the 410 identified path. 412 This approach assumes that there is an underlay network that provides 413 connectivity between SFFs and Controllers, and that the SFFs are 414 grouped to form one or more service function overlay networks through 415 which SFPs are built. We assume that the Controllers have BGP 416 connectivity to all SFFs and all Classifiers within each service 417 function overlay network. 419 When choosing the next SFI in a path, the SFF uses the SPI and SI as 420 well as the SFT to choose among the SFIs, applying, for example, a 421 load balancing algorithm or direct knowledge of the underlay network 422 topology as described in Section 4. 424 The SFF then encapsulates the packet using the encapsulation 425 specified by the SFIR of the selected SFI and forwards the packet. 426 See Figure 1. 428 Thus the SFF can be seen as a portal in the underlay network through 429 which a particular SFI is reached. 431 Figure 1 shows a reference model for the SFC architecture. There are 432 four SFFs (SFF-1 through SFF-4) connected by tunnels across the 433 underlay network. Packets arrive at a Classifier and are channeled 434 along SFPs to destinations reachable through SFF-4. 436 SFF-1 and SFF-4 each have one instance of one SF attached (SFa and 437 SFe). SFF-2 has two types of SF attached: there is one instance of 438 one (SFc), and three instances of the other (SFb). SFF-3 has just 439 one instance of an SF (SFd), but it in this case the type of SFd is 440 the same type as SFb (SFTx). 442 This figure demonstrates how load balancing can be achieved by 443 creating several SFPs that satisfy the same SFC. Suppose an SFC 444 needs to include SFa, an SF of type SFTx, and SFc. A number of SFPs 445 can be constructed using any instance of SFb or using SFd. Load 446 balancing may be applied at two places: 448 o The Classifier may distribute different flows onto different SFPs 449 to share the load in the network and across SFIs. 451 o SFF-2 may distribute different flows (on the same SFP) to 452 different instances of SFb to share the processing load. 454 Note that, for convenience and clarity, Figure 1 shows only a few 455 tunnels between SFFs. There could be a full mesh of such tunnels, or 456 more likely, a selection of tunnels connecting key SFFs to enable the 457 construction of SFPs and to balance load and traffic in the network. 458 Further, the figure does not show any controllers: these would each 459 have BGP connectivity to the Classifier and all of the SFFs. 461 Packets 462 | | | 463 ------------ 464 | | 465 | Classifier | 466 | | 467 ------+----- 468 | 469 ---+--- --------- ------- 470 | | Tunnel | | | | 471 | SFF-1 |===============| SFF-2 |=========| SFF-4 | 472 | | | | | | 473 | | -+-----+- | | 474 | | ,,,,,,,,,,,,,,/,, \ | | 475 | | ' .........../. ' ..\...... | | 476 | | ' : SFb / : ' : \ SFc : | | 477 | | ' : ---+- : ' : --+-- : | | 478 | | ' : -| SFI | : ' : | SFI | : | | 479 | | ' : -| ----- : ' : ----- : | | 480 | | ' : | ----- : ' ......... | | 481 | | ' : ----- : ' | | 482 | | ' ............. ' | |--- Dests 483 | | ' ' | |--- Dests 484 | | ' ......... ' | | 485 | | ' : ----- : ' | | 486 | | ' : | SFI | : ' | | 487 | | ' : --+-- : ' | | 488 | | ' :SFd | : ' | | 489 | | ' ....|.... ' | | 490 | | ' | ' | | 491 | | ' SFTx | ' | | 492 | | ',,,,,,,,|,,,,,,,,' | | 493 | | | | | 494 | | ---+--- | | 495 | | | | | | 496 | |======| SFF-3 |====================| | 497 ---+--- | | ---+--- 498 | ------- | 499 ....|.... ....|.... 500 : | SFa: : | SFe: 501 : --+-- : : --+-- : 502 : | SFI | : : | SFI | : 503 : ----- : : ----- : 504 ......... ......... 506 Figure 1: The SFC Architecture Reference Model 508 As previously noted, [RFC8300] makes it clear that the mechanisms it 509 defines are intended for use within a single provider's operational 510 domain. This reduces the requirements on the control plane function. 512 [RFC7665] sets out the functions provided by a control plane for an 513 SFC network in Section 5.2. The functions are broken down into six 514 items the first four of which are completely covered by the 515 mechanisms described in this document: 517 1. Visibility of all SFs and the SFFs through which they are 518 reached. 520 2. Computation of SFPs and programming into the network. 522 3. Selection of SFIs explicitly in the SFP or dynamically within the 523 network. 525 4. Programming of SFFs with forwarding path information. 527 The fifth and six items in the list in RFC 7665 concern the use of 528 metadata. These are more peripheral to the control plane mechanisms 529 defined in this document, but are discussed in Section 4.4. 531 3. BGP SFC Routes 533 This document defines a new AFI/SAFI for BGP, known as "SFC", with an 534 NLRI that is described in this section. 536 The format of the SFC NLRI is shown in Figure 2. 538 +---------------------------------------+ 539 | Route Type (2 octets) | 540 +---------------------------------------+ 541 | Length (2 octets) | 542 +---------------------------------------+ 543 | Route Type specific (variable) | 544 +---------------------------------------+ 546 Figure 2: The Format of the SFC NLRI 548 The Route Type field determines the encoding of the rest of the route 549 type specific SFC NLRI. 551 The Length field indicates the length in octets of the route type 552 specific field of the SFC NLRI. 554 This document defines the following Route Types: 556 1. Service Function Instance Route (SFIR) 558 2. Service Function Path Route (SFPR) 560 A Service Function Instance Route (SFIR) is used to identify an SFI. 561 A Service Function Path Route (SFPR) defines a sequence of Service 562 Functions (each of which has at least one instance advertised in an 563 SFIR) that form an SFP. 565 The detailed encoding and procedures for these Route Types are 566 described in subsequent sections. 568 The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol 569 Extensions [RFC4760] with an Address Family Identifier (AFI) of TBD1 570 and a Subsequent Address Family Identifier (SAFI) of TBD2. The NLRI 571 field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC 572 NLRI, encoded as specified above. 574 In order for two BGP speakers to exchange SFC NLRIs, they MUST use 575 BGP Capabilities Advertisements to ensure that they both are capable 576 of properly processing such NLRIs. This is done as specified in 577 [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI 578 of TBD1 and a SAFI of TBD2. 580 The nexthop field of the MP_REACH_NLRI attribute of the SFC NLRI MUST 581 be set to a loopback address of the advertising SFF. 583 3.1. Service Function Instance Route (SFIR) 585 Figure 3 shows the Route Type specific NLRI of the SFIR. 587 +--------------------------------------------+ 588 | Route Distinguisher (RD) (8 octets) | 589 +--------------------------------------------+ 590 | Service Function Type (2 octets) | 591 +--------------------------------------------+ 593 Figure 3: SFIR Route Type specific NLRI 595 [RFC4364] defines a Route Distinguisher (RD) to consist of a two byte 596 Type field and a six byte Value field and it defines RD types 0, 1, 597 and 2. In this specification, the RD (used for the SFIR) MUST be of 598 type 0, 1, or 2. 600 If two SFIRs are originated from different administrative domains 601 (within the same provier's operational domain), they MUST have 602 different RDs. In particular, SFIRs from different VPNs (for 603 different service function overlay networks) MUST have different RDs, 604 and those RDs MUST be different from any non-VPN SFIRs. 606 The Service Function Type identifies the functions/features a service 607 function can offer, e.g., Classifier, firewall, load balancer. There 608 may be several SFIs that can perform a given Service Function. Each 609 node hosting an SFI MUST originate an SFIR for each type of SF that 610 it hosts (as indicated by the SFT value), and it MAY advertise an 611 SFIR for each instance of each type of SF. The minimal advertisement 612 allows construction of valid SFPs and leaves the selection of SFIs to 613 the local SFF; the detailed advertisement may have scaling concerns, 614 but allows a Controller that constructs an SFP to make an explicit 615 choice of SFI. 617 Note that a node may advertise all its SFIs of one SFT in one shot 618 using normal BGP Update packing. That is, all of the SFIRs in an 619 Update share a common Tunnel Encapsulation and Route Target (RT) 620 attribute. See also Section 3.2.1. 622 The SFIR representing a given SFI will contain an NLRI with RD field 623 set to an RD as specified above, and with SFT field set to identify 624 that SFI's Service Function Type. The values for the SFT field are 625 taken from a registry administered by IANA (see Section 10). A BGP 626 Update containing one or more SFIRs MUST also include a Tunnel 627 Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data 628 packet needs to be sent to an SFI identified in one of the SFIRs, it 629 will be encapsulated as specified by the Tunnel Encapsulation 630 attribute, and then transmitted through the underlay network. 632 Note that the Tunnel Encapsulation attribute MUST contain sufficient 633 information to allow the advertising SFF to identify the overlay or 634 VPN network which a received packet is transiting. This is because 635 the [SPI, SI] in a received packet is specific to a particular 636 overlay or VPN network. 638 3.1.1. SFIR Pool Identifier Extended Community 640 This document defines a new transitive extended community [RFC4360] 641 of type TBD6 called the SFC extended community. When used with Sub- 642 Type 1, this is called the SFIR Pool Identifier extended community. 643 It MAY be included in SFIR advertisements, and is used to indicate 644 the identity of a pool of SFIRs to which an SFIR belongs. Since an 645 SFIR may be a member of multiple pools, multiple of these extended 646 communities may be present on a single SFIR advertisement. 648 SFIR pools allow SFIRs to be grouped for any purpose. Possible uses 649 include control plane scalability and stability. A pool identifier 650 may be included in an SFPR to indicate a set of SFIs that are 651 acceptable at a specific point on an SFP (see Section 3.2.1.3 and 652 Section 4.3). 654 The SFIR Pool Identifier extended community is encoded in 8 octets as 655 shown in Figure 4. 657 +--------------------------------------------+ 658 | Type = TBD6 (1 octet) | 659 +--------------------------------------------+ 660 | Sub-Type = 1 (1 octet) | 661 +--------------------------------------------+ 662 | SFIR Pool Identifier Value (6 octets) | 663 +--------------------------------------------+ 665 Figure 4: The SFIR Pool Identifier Extended Community 667 The SFIR Pool Identifier Value is encoded in a 6 octet field in 668 network byte order, and the value is unique within the scope of an 669 overlay network. This means that pool identifiers need to be 670 centrally managed, which is consistent with the assignment of SFIs to 671 pools. 673 3.1.2. MPLS Mixed Swapping/Stacking Extended Community 675 As noted in Section 3.1.1, this document defines a new transitive 676 extended community of type TBD6 called the SFC extended community. 677 When used with Sub-Type 2, this is called the MPLS Mixed Swapping/ 678 Stacking Labels extended community. The community is encoded as 679 shown in Figure 5. It contains a pair of MPLS labels: an SFC Context 680 Label and an SF Label as described in [RFC8595]. Each label is 20 681 bits encoded in a 3-octet (24 bit) field with 4 trailing bits that 682 MUST be set to zero. 684 +--------------------------------------------+ 685 | Type = TBD6 (1 octet) | 686 +--------------------------------------------| 687 | Sub-Type = 2 (1 octet) | 688 +--------------------------------------------| 689 | SFC Context Label (3 octets) | 690 +--------------------------------------------| 691 | SF Label (3 octets) | 692 +--------------------------------------------+ 694 Figure 5: The MPLS Mixed Swapping/Stacking Extended Community 696 Note that it is assumed that each SFF has one or more globally unique 697 SFC Context Labels and that the context label space and the SPI 698 address space are disjoint (i.e., a label value cannot be used both 699 to indicate an SFC context and an SPI, and it can be determined from 700 knowledge of the label spaces whether a label indicates an SFC 701 context or an SPI). 703 If an SFF supports SFP Traversal with an MPLS Label Stack it MUST 704 include this extended community with the SFIRs that it advertises. 706 See Section 7.6 for a description of how this extended community is 707 used. 709 3.2. Service Function Path Route (SFPR) 711 Figure 6 shows the Route Type specific NLRI of the SFPR. 713 +-----------------------------------------------+ 714 | Route Distinguisher (RD) (8 octets) | 715 +-----------------------------------------------+ 716 | Service Path Identifier (SPI) (3 octets) | 717 +-----------------------------------------------+ 719 Figure 6: SFPR Route Type Specific NLRI 721 [RFC4364] defines a Route Distinguisher (RD) to consist of a two byte 722 Type field and a six byte Value field and it defines RD types 0, 1, 723 and 2. In this specification, the RD (used for the SFPR) MUST be of 724 type 0, 1, or 2. 726 All SFPs MUST be associated with an RD. The association of an SFP 727 with an RD is determined by provisioning. If two SFPRs are 728 originated from different Controllers they MUST have different RDs. 730 Additionally, SFPRs from different VPNs (i.e., in different service 731 function overlay networks) MUST have different RDs, and those RDs 732 MUST be different from any non-VPN SFPRs. 734 The Service Path Identifier is defined in [RFC8300] and is the value 735 to be placed in the Service Path Identifier field of the NSH header 736 of any packet sent on this Service Function Path. It is expected 737 that one or more Controllers will originate these routes in order to 738 configure a service function overlay network. 740 The SFP is described in a new BGP Path attribute, the SFP attribute. 741 Section 3.2.1 shows the format of that attribute. 743 3.2.1. The SFP Attribute 745 [RFC4271] defines BGP Path attributes. This document introduces a 746 new Optional Transitive Path attribute called the SFP attribute with 747 value TBD3 to be assigned by IANA. The first SFP attribute MUST be 748 processed and subsequent instances MUST be ignored. 750 The common fields of the SFP attribute are set as follows: 752 o Optional bit is set to 1 to indicate that this is an optional 753 attribute. 755 o The Transitive bit is set to 1 to indicate that this is a 756 transitive attribute. 758 o The Extended Length bit is set if the length of the SFP attribute 759 is encoded in one octet (set to 0) or two octets (set to 1) as 760 described in [RFC4271]. 762 o The Attribute Type Code is set to TBD3. 764 The content of the SFP attribute is a series of Type-Length-Value 765 (TLV) constructs. Some TLVs may include sub-TLVs. All TLVs and sub- 766 TLVs have a common format that is: 768 o Type: A single octet indicating the type of the SFP attribute TLV. 769 Values are taken from the registry described in Section 10.3. 771 o Length: A two octet field indicating the length of the data 772 following the Length field counted in octets. 774 o Value: The contents of the TLV. 776 The formats of the TLVs defined in this document are shown in the 777 following sections. The presence rules and meanings are as follows. 779 o The SFP attribute contains a sequence of zero or more Association 780 TLVs. That is, the Association TLV is OPTIONAL. Each Association 781 TLV provides an association between this SFPR and another SFPR. 782 Each associated SFPR is indicated using the RD with which it is 783 advertised (we say the SFPR-RD to avoid ambiguity). 785 o The SFP attribute contains a sequence of one or more Hop TLVs. 786 Each Hop TLV contains all of the information about a single hop in 787 the SFP. 789 o Each Hop TLV contains an SI value and a sequence of one or more 790 SFT TLVs. Each SFT TLV contains an SFI reference for each 791 instance of an SF that is allowed at this hop of the SFP for the 792 specific SFT. Each SFI is indicated using the RD with which it is 793 advertised (we say the SFIR-RD to avoid ambiguity). 795 Section 6 of [RFC4271] describes the handling of malformed BGP 796 attributes, or those that are in error in some way. [RFC7606] 797 revises BGP error handling specifically for the UPDATE message, 798 provides guidelines for the authors of documents defining new 799 attributes, and revises the error handling procedures for a number of 800 existing attributes. This document introduces the SFP attribute and 801 so defines error handling as follows: 803 o When parsing a message, an unknown Attribute Type code or a length 804 that suggests that the attribute is longer than the remaining 805 message is treated as a malformed message and the "treat-as- 806 withdraw" approach used as per [RFC7606]. 808 o When parsing a message that contains an SFP attribute, the 809 following cases constitute errors: 811 1. Optional bit is set to 0 in SFP attribute. 813 2. Transitive bit is set to 0 in SFP attribute. 815 3. Unknown TLV type field found in SFP attribute. 817 4. TLV length that suggests the TLV extends beyond the end of the 818 SFP attribute. 820 5. Association TLV contains an unknown SFPR-RD. 822 6. No Hop TLV found in the SFP attribute. 824 7. No sub-TLV found in a Hop TLV. 826 8. Unknown SFIR-RD found in an SFT TLV. 828 o The errors listed above are treated as follows: 830 1., 2., 4., 6., 7.: The attribute MUST be treated as malformed 831 and the "treat-as-withdraw" approach used as per [RFC7606]. 833 3.: Unknown TLVs MUST be ignored, and message processing MUST 834 continue. 836 5., 8.: The absence of an RD with which to correlate is nothing 837 more than a soft error. The receiver SHOULD store the 838 information from the SFP attribute until a corresponding 839 advertisement is received. 841 3.2.1.1. The Association TLV 843 The Association TLV is an optional TLV in the SFP attribute. It MAY 844 be present multiple times. Each occurrence provides an association 845 with another SFP as advertised in another SFPR. The format of the 846 Association TLV is shown in Figure 7 848 +--------------------------------------------+ 849 | Type = 1 (1 octet) | 850 +--------------------------------------------| 851 | Length (2 octets) | 852 +--------------------------------------------| 853 | Association Type (1 octet) | 854 +--------------------------------------------| 855 | Associated SFPR-RD (8 octets) | 856 +--------------------------------------------| 857 | Associated SPI (3 octets) | 858 +--------------------------------------------+ 860 Figure 7: The Format of the Association TLV 862 The fields are as follows: 864 Type is set to 1 to indicate an Association TLV. 866 Length indicates the length in octets of the Association Type and 867 Associated SFPR-RD fields. The value of the Length field is 12. 869 The Association Type field indicate the type of association. The 870 values are tracked in an IANA registry (see Section 10.4). Only 871 one value is defined in this document: type 1 indicates 872 association of two unidirectional SFPs to form a bidirectional 873 SFP. An SFP attribute SHOULD NOT contain more than one 874 Association TLV with Association Type 1: if more than one is 875 present, the first one MUST be processed and subsequent instances 876 MUST be ignored. Note that documents that define new Association 877 Types must also define the presence rules for Association TLVs of 878 the new type. 880 The Associated SFPR-RD contains the RD of the associated SFP as 881 advertised in an SFPR. 883 The Associated SPI contains the SPI of the associated SFP as 884 advertised in an SFPR. 886 Association TLVs with unknown Association Type values SHOULD be 887 ignored. Association TLVs that contain an Associated SFPR-RD value 888 equal to the RD of the SFPR in which they are contained SHOULD be 889 ignored. If the Associated SPI is not equal to the SPI advertised in 890 the SFPR indicated by the Associated SFPR-RD then the Association TLV 891 SHOULD be ignored. In all three of these cases an implementation MAY 892 reject the SFP attribute as malformed and use the "treat-as-withdraw" 893 approach per [RFC7606], however implementers are cautioned that such 894 an approach may make an implementation less flexible in the event of 895 future extensions to this protocol. 897 Note that when two SFPRs reference each other using the Association 898 TLV, one SFPR advertisement will be received before the other. 899 Therefore, processing of an association MUST NOT be rejected simply 900 because the Associated SFPR-RD is unknown. 902 Further discussion of correlation of SFPRs is provided in 903 Section 7.1. 905 3.2.1.2. The Hop TLV 907 There is one Hop TLV in the SFP attribute for each hop in the SFP. 908 The format of the Hop TLV is shown in Figure 8. At least one Hop TLV 909 MUST be present in an SFP attribute. 911 +--------------------------------------------+ 912 | Type = 2 (1 octet) | 913 +--------------------------------------------| 914 | Length (2 octets) | 915 +--------------------------------------------| 916 | Service Index (1 octet) | 917 +--------------------------------------------| 918 | Hop Details (variable) | 919 +--------------------------------------------+ 921 Figure 8: The Format of the Hop TLV 923 The fields are as follows: 925 Type is set to 2 to indicate a Hop TLV. 927 Length indicates the length in octets of the Service Index and Hop 928 Details fields. 930 The Service Index is defined in [RFC8300] and is the value found 931 in the Service Index field of the NSH header that an SFF will use 932 to lookup to which next SFI a packet is to be sent. 934 The Hop Details field consists of a sequence of one or more sub- 935 TLVs. 937 Each hop of the SFP may demand that a specific type of SF is 938 executed, and that type is indicated in sub-TLVs of the Hop TLV. At 939 least one sub-TLV MUST be present. This document defines the SFT 940 Sub-TLV (see Section 3.2.1.3 and the MPLS Swapping/Stacking Sub-TLV 941 (see Section Section 3.2.1.4: other sub-TLVs may be defined in 942 future. This provides a list of which types of SF are acceptable at 943 a specific hop, and for each type it allows a degree of control to be 944 imposed on the choice of SFIs of that particular type. 946 If no Hop TLV is present in an SFP Attribute, it is a malformed 947 attribute 949 3.2.1.3. The SFT Sub-TLV 951 The SFT Sub-TLV MAY be included in the list of sub-TLVs of the Hop 952 TLV. The format of the SFT Sub-TLV is shown in Figure 9. The Sub- 953 TLV contains a list of SFIR-RD values each taken from the 954 advertisement of an SFI. Together they form a list of acceptable 955 SFIs of the indicated type. 957 +--------------------------------------------+ 958 | Type = 3 (1 octet) | 959 +--------------------------------------------| 960 | Length (2 octets) | 961 +--------------------------------------------| 962 | Service Function Type (2 octets) | 963 +--------------------------------------------| 964 | SFIR-RD List (variable) | 965 +--------------------------------------------+ 967 Figure 9: The Format of the SFT Sub-TLV 969 The fields are as follows: 971 Type is set to 3 to indicate an SFT Sub-TLV. 973 Length indicates the length in octets of the Service Function Type 974 and SFIR-RD List fields. 976 The Service Function Type value indicates the category (type) of 977 SF that is to be executed at this hop. The types are as 978 advertised for the SFs supported by the SFFs. SFT values in the 979 range 1-31 are Special Purpose SFT values and have meanings 980 defined by the documents that describe them - the value 'Change 981 Sequence' is defined in Section 6.1 of this document. 983 The hop description is further qualified beyond the specification 984 of the SFTs by listing, for each SFT in each hop, the SFIs that 985 may be used at the hop. The SFIs are identified using the SFIR- 986 RDs from the advertisements of the SFIs in the SFIRs. Note that 987 if the list contains one or more SFIR Pool Identifiers, then for 988 each the SFIR-RD list is effectively expanded to include the SFIR- 989 RD of each SFIR advertised with that SFIR Pool Identifier. An 990 SFIR-RD of value zero has special meaning as described in 991 Section 5. Each entry in the list is eight octets long, and the 992 number of entries in the list can be deduced from the value of the 993 Length field. 995 Note that an SFIR-RD is of type 0, 1, or 2 (as described in 996 Section 3.1. Thus the high order octet of an RD found in an SFIR- 997 RD List always has a value of 0x00. However, the high order octet 998 of an SFIR Pool Identifier (an extended community with Type field 999 TBD6), will always have a non-zero value. This allows the node 1000 processing the SFIR-RD List to distinguish between the two types 1001 of list entry. 1003 3.2.1.4. MPLS Swapping/Stacking Sub-TLV 1005 The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero length 1006 sub-TLV that is OPTIONAL in the Hop TLV and is used when the data 1007 representation is MPLS (see Section 7.5). When present it indicates 1008 to the Classifier imposing an MPLS label stack that the current hop 1009 is to use an {SFC Context Label, SF label} rather than an {SPI, SF} 1010 label pair. See Section 7.6 for more details. 1012 3.2.1.5. SFP Traversal With MPLS Label Stack TLV 1014 The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero 1015 length TLV that can be carried in the SFP Attribute and indicates to 1016 the Classifier and the SFFs on the SFP that an MPLS label stack with 1017 label swapping/stacking is to be used for packets traversing the SFP. 1018 All of the SFFs specified at each of the SFP's hops MUST have 1019 advertised an MPLS Mixed Swapping/Stacking Extended Community (see 1020 Section 3.1.2) for the SFP to be considered usable. 1022 3.2.2. General Rules For The SFP Attribute 1024 It is possible for the same SFI, as described by an SFIR, to be used 1025 in multiple SFPRs. 1027 When two SFPRs have the same SPI but different SFPR-RDs there can be 1028 three cases: 1030 o Two or more Controllers are originating SFPRs for the same SFP. 1031 In this case the content of the SFPRs is identical and the 1032 duplication is to ensure receipt and to provide Controller 1033 redundancy. 1035 o There is a transition in content of the advertised SFP and the 1036 advertisements may originate from one or more Controllers. In 1037 this case the content of the SFPRs will be different. 1039 o The reuse of an SPI may result from a configuration error. 1041 In all cases, there is no way for the receiving SFF to know which 1042 SFPR to process, and the SFPRs could be received in any order. At 1043 any point in time, when multiple SFPRs have the same SPI but 1044 different SFPR-RDs, the SFF MUST use the SFPR with the numerically 1045 lowest SFPR-RD when interpreting the RDs as 8-octet integers in 1046 network byte order. The SFF SHOULD log this occurrence to assist 1047 with debugging. 1049 Furthermore, a Controller that wants to change the content of an SFP 1050 is RECOMMENDED to use a new SPI and so create a new SFP onto which 1051 the Classifiers can transition packet flows before the SFPR for the 1052 old SFP is withdrawn. This avoids any race conditions with SFPR 1053 advertisements. 1055 Additionally, a Controller SHOULD NOT re-use an SPI after it has 1056 withdrawn the SFPR that used it until at least a configurable amount 1057 of time has passed. This timer SHOULD have a default of one hour. 1059 4. Mode of Operation 1061 This document describes the use of BGP as a control plane to create 1062 and manage a service function overlay network. 1064 4.1. Route Targets 1066 The main feature introduced by this document is the ability to create 1067 multiple service function overlay networks through the use of Route 1068 Targets (RTs) [RFC4364]. 1070 Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. 1071 The RT carried by a particular SFIR or SFPR is determined by the 1072 provisioning of the route's originator. 1074 Every node in a service function overlay network is configured with 1075 one or more import RTs. Thus, each SFF will import only the SFPRs 1076 with matching RTs allowing the construction of multiple service 1077 function overlay networks or the instantiation of Service Function 1078 Chains within an Layer 3 Virtual Private Network (L3VPN) or Ethernet 1079 VPN (EVPN) instance (see Section 7.3). An SFF that has a presence in 1080 multiple service function overlay networks (i.e., imports more than 1081 one RT) will usually maintain separate forwarding state for each 1082 overlay network. 1084 4.2. Service Function Instance Routes 1086 The SFIR (see Section 3.1) is used to advertise the existence and 1087 location of a specific Service Function Instance and consists of: 1089 o The RT as just described. 1091 o A Service Function Type (SFT) that is the type of service function 1092 that is provided (such as "firewall"). 1094 o A Route Distinguisher (RD) that is unique to a specific overlay. 1096 4.3. Service Function Path Routes 1098 The SFPR (see Section 3.2) describes a specific path of a Service 1099 Function Chain. The SFPR contains the Service Path Identifier (SPI) 1100 used to identify the SFP in the NSH in the data plane. It also 1101 contains a sequence of Service Indexes (SIs). Each SI identifies a 1102 hop in the SFP, and each hop is a choice between one of more SFIs. 1104 As described in this document, each Service Function Path Route is 1105 identified in the service function overlay network by an RD and an 1106 SPI. The SPI is unique within a single VPN instance supported by the 1107 underlay network. 1109 The SFPR advertisement comprises: 1111 o An RT as described in Section 4.1. 1113 o A tuple that identifies the SFPR 1115 * An RD that identifies an advertisement of an SFPR. 1117 * The SPI that uniquely identifies this path within the VPN 1118 instance distinguished by the RD. This SPI also appears in the 1119 NSH. 1121 o A series of Service Indexes. Each SI is used in the context of a 1122 particular SPI and identifies one or more SFs (distinguished by 1123 their SFTs) and for each SF a set of SFIs that instantiate the SF. 1124 The values of the SI indicate the order in which the SFs are to be 1125 executed in the SFP that is represented by the SPI. 1127 o The SI is used in the NSH to identify the entries in the SFP. 1128 Note that the SI values have meaning only relative to a specific 1129 path. They have no semantic other than to indicate the order of 1130 Service Functions within the path and are assumed to be 1131 monotonically decreasing from the start to the end of the path 1132 [RFC8300]. 1134 o Each Service Index is associated with a set of one or more Service 1135 Function Instances that can be used to provide the indexed Service 1136 Function within the path. Each member of the set comprises: 1138 * The RD used in an SFIR advertisement of the SFI. 1140 * The SFT that indicates the type of function as used in the same 1141 SFIR advertisement of the SFI. 1143 This may be summarized as follows where the notations "SFPR-RD" and 1144 "SFIR-RD" are used to distinguish the two different RDs, and where 1145 "*" indicates a multiplier: 1147 RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } } 1149 Where: 1151 RT: Route Target 1153 SFPR-RD: The Route Descriptor of the Service Function Path Route 1154 advertisement 1156 SPI: Service Path Identifier used in the NSH 1158 m: The number of hops in the Service Function Path 1160 n: The number of choices of Service Function Type for a specific 1161 hop 1163 p: The number of choices of Service Function Instance for given 1164 Service Function Type in a specific hop 1166 SI: Service Index used in the NSH to indicate a specific hop 1168 SFT: The Service Function Type used in the same advertisement of 1169 the Service Function Instance Route 1171 SFIR-RD: The Route Descriptor used in an advertisement of the 1172 Service Function Instance Route 1174 That is, there can be multiple SFTs at a given hop as described in 1175 Section 5. 1177 Note that the values of SI are from the set {255, ..., 1} and are 1178 monotonically decreasing within the SFP. SIs MUST appear in order 1179 within the SFPR (i.e., monotonically decreasing) and MUST NOT appear 1180 more than once. Gaps MAY appear in the sequence as described in 1181 Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any 1182 previous instance of the SFPR (same SFPR-RD and SPI) to be discarded. 1184 Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR 1185 Pool identifiers, then in the above expression, 'p' is the sum of the 1186 number of individual SFIR-RD values and the sum for each SFIR Pool 1187 Identifier of the number of SFIRs advertised with that SFIR Pool 1188 Identifier. I.e., the list of SFIR-RD values is effectively expanded 1189 to include the SFIR-RD of each SFIR advertised with each SFIR Pool 1190 Identifier in the SFIR-RD list. 1192 The choice of SFI is explained further in Section 5. Note that an 1193 SFIR-RD value of zero has special meaning as described in that 1194 Section. 1196 4.4. Classifier Operation 1198 As shown in Figure 1, the Classifier is a component that is used to 1199 assign packets to an SFP. 1201 The Classifier is responsible for determining to which packet flow a 1202 packet belongs. The mechanism it uses to achieve that classification 1203 is out of scope of this document, but might include inspection of the 1204 packet header. The Classifier has been instructed (by the Controller 1205 or through some other configuration mechanism - see Section 7.4) 1206 which flows are to be assigned to which SFPs, and so it can impose an 1207 NSH on each packet and initialize the NSH with the SPI of the 1208 selected SFP and the SI of its first hop. 1210 Note that instructions delivered to the Classifier may include 1211 information about the metadata to encode (and the format for that 1212 encoding) on packets that are classified by the Classifier to a 1213 particular SFP. As mentioned in Section 2.2, this corresponds to the 1214 fifth element of control plane functionality described in [RFC7665]. 1215 Such instructions fall outside the scope of this specification 1216 (although, see Section 7.4), as do instructions to other SFC elements 1217 on how to interpret metadata (as described in the sixth element of 1218 control plane functionality described in [RFC7665]. 1220 4.5. Service Function Forwarder Operation 1222 Each packet sent to an SFF is transmitted encapsulated in an NSH. 1223 The NSH includes an SPI and SI: the SPI indicates the SFPR 1224 advertisement that announced the Service Function Path; the tuple 1225 SPI/SI indicates a specific hop in a specific path and maps to the 1226 RD/SFT of a particular SFIR advertisement. 1228 When an SFF gets an SFPR advertisement it will first determine 1229 whether to import the route by examining the RT. If the SFPR is 1230 imported the SFF then determines whether it is on the SFP by looking 1231 for its own SFIR-RDs or any SFIR-RD with value zero in the SFPR. For 1232 each occurrence in the SFP, the SFF creates forwarding state for 1233 incoming packets and forwarding state for outgoing packets that have 1234 been processed by the specified SFI. 1236 The SFF creates local forwarding state for packets that it receives 1237 from other SFFs. This state makes the association between the SPI/SI 1238 in the NSH of the received packet and one or more specific local SFIs 1239 as identified by the SFIR-RD/SFT. If there are multiple local SFIs 1240 that match this is because a single advertisement was made for a set 1241 of equivalent SFIs and the SFF may use local policy (such as load 1242 balancing) to determine to which SFI to forward a received packet. 1244 The SFF also creates next hop forwarding state for packets received 1245 back from the local SFI that need to be forwarded to the next hop in 1246 the SFP. There may be a choice of next hops as described in 1247 Section 4.3. The SFF could install forwarding state for all 1248 potential next hops, or it could choose to only install forwarding 1249 state to a subset of the potential next hops. If a choice is made 1250 then it will be as described in Section 5. 1252 The installed forwarding state may change over time reacting to 1253 changes in the underlay network and the availability of particular 1254 SFIs. Note that the forwarding state describes how one SFF send 1255 packets to another SFF, but not how those packets are routed through 1256 the underlay network. SFFs may be connected by tunnels across the 1257 underlay, or packets may be sent addressed to the next SFF and routed 1258 through the underlay. In any case, transmission across the underlay 1259 requires encapsulation of packets with a header for transport in the 1260 underlay network. 1262 Note that SFFs only create and store forwarding state for the SFPs on 1263 which they are included. They do not retain state for all SFPs 1264 advertised. 1266 An SFF may also install forwarding state to support looping, jumping, 1267 and branching. The protocol mechanism for explicit control of 1268 looping, jumping, and branching uses a specific reserved SFT value at 1269 a given hop of an SFPR and is described in Section 6.1. 1271 4.5.1. Processing With 'Gaps' in the SI Sequence 1273 The behavior of an SF as described in [RFC8300] is to decrement the 1274 value of the SI field in the NSH by one before returning a packet to 1275 the local SFF for further processing. This means that there is a 1276 good reason to assume that the SFP is composed of a series of SFs 1277 each indicated by an SI value one less than the previous. 1279 However, there is an advantage to having non-successive SIs in an 1280 SPI. Consider the case where an SPI needs to be modified by the 1281 insertion or removal of an SF. In the latter case this would lead to 1282 a "gap" in the sequence of SIs, and in the former case, this could 1283 only be achieved if a gap already existed into which the new SF with 1284 its new SI value could be inserted. Otherwise, all "downstream" SFs 1285 would need to be renumbered. 1287 Now, of course, such renumbering could be performed, but would lead 1288 to a significant disruption to the SFC as all the SFFs along the SFP 1289 were "reprogrammed". Thus, to achieve dynamic modification of an SFP 1290 (and even, in-service modification) it is desirable to be able to 1291 make these modifications without changing the SIs of the elements 1292 that were present before the modification. This will produce much 1293 more consistent/predictable behavior during the convergence period 1294 where otherwise the change would need to be fully propagated. 1296 Another approach says that any change to an SFP simply creates a new 1297 SFP that can be assigned a new SPI. All that would be needed would 1298 be to give a new instruction to the Classifier and traffic would be 1299 switched to the new SFP that contains the new set of SFs. This 1300 approach is practical, but neglects to consider that the SFP may be 1301 referenced by other SFPs (through "branch" instructions) and used by 1302 many Classifiers. In those cases the corresponding configuration 1303 resulting from a change in SPI may have wide ripples and give scope 1304 for errors that are hard to trace. 1306 Therefore, while this document requires that the SI values in an SFP 1307 are monotonic decreasing, it makes no assumption that the SI values 1308 are sequential. Configuration tools may apply that rule, but they 1309 are not required to. To support this, an SFF SHOULD process as 1310 follows when it receives a packet: 1312 o If the SI indicates a known entry in the SFP, the SFF MUST process 1313 the packet as normal, looking up the SI and determining to which 1314 local SFI to deliver the packet. 1316 o If the SI does not match an entry in the SFP, the SFF MUST reduce 1317 the SI value to the next (smaller) value present in the SFP and 1318 process the packet using that SI. 1320 o If there is no smaller SI (i.e., if the end of the SFP has been 1321 reached) the SFF MUST treat the SI value as invalid as described 1322 in [RFC8300]. 1324 This makes the behavior described in this document a superset of the 1325 function in [RFC8300]. That is, an implementation that strictly 1326 follows RFC 8300 in performing SI decrements in units of one, is 1327 perfectly in line with the mechanisms defined in this document. 1329 SFF implementations MAY choose to only support contiguous SI values 1330 in an SFP. Such an implementation will not support receiving an SI 1331 value that is not present in the SFP and will discard the packets as 1332 described in [RFC8300]. 1334 5. Selection within Service Function Paths 1336 As described in Section 2 the SPI/SI in the NSH passed back from an 1337 SFI to the SFF may leave the SFF with a choice of next hop SFTs, and 1338 a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, 1339 and the SI indicates an entry in that SFPR. Each entry in an SFPR is 1340 a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of 1341 these, identify the SFF that supports the chosen SFI, and send the 1342 packet to that next hop SFF. 1344 The choice be may offered for load balancing across multiple SFIs, or 1345 for discrimination between different actions necessary at a specific 1346 hop in the SFP. Different SFT values may exist at a given hop in an 1347 SFP to support several cases: 1349 o There may be multiple instances of similar service functions that 1350 are distinguished by different SFT values. For example, firewalls 1351 made by vendor A and vendor B may need to be identified by 1352 different SFT values because, while they have similar 1353 functionality, their behavior is not identical. Then, some SFPs 1354 may limit the choice of SF at a given hop by specifying the SFT 1355 for vendor A, but other SFPs might not need to control which 1356 vendor's SF is used and so can indicate that either SFT can be 1357 used. 1359 o There may be an obvious branch needed in an SFP such as the 1360 processing after a firewall where admitted packets continue along 1361 the SFP, but suspect packets are diverted to a "penalty box". In 1362 this case, the next hop in the SFP will be indicated with two 1363 different SFT values. 1365 In the typical case, the SFF chooses a next hop SFF by looking at the 1366 set of all SFFs that support the SFs identified by the SI (that set 1367 having been advertised in individual SFIR advertisements), finding 1368 the one or more that are "nearest" in the underlay network, and 1369 choosing between next hop SFFs using its own load-balancing 1370 algorithm. 1372 An SFI may influence this choice process by passing additional 1373 information back along with the packet and NSH. This information may 1374 influence local policy at the SFF to cause it to favor a next hop SFF 1375 (perhaps selecting one that is not nearest in the underlay), or to 1376 influence the load-balancing algorithm. 1378 This selection applies to the normal case, but also applies in the 1379 case of looping, jumping, and branching (see Section 6). 1381 Suppose an SFF in a particular service overlay network (identified by 1382 a particular import RT, RT-z) needs to forward an NSH-encapsulated 1383 packet whose SPI is SPI-x and whose SI is SI-y. It does the 1384 following: 1386 1. It looks for an installed SFPR that carries RT-z and that has 1387 SPI-x in its NLRI. If there is none, then such packets cannot be 1388 forwarded. 1390 2. From the SFP attribute of that SFPR, it finds the Hop TLV with SI 1391 value set to SI-y. If there is no such Hop TLV, then such 1392 packets cannot be forwarded. 1394 3. It then finds the "relevant" set of SFIRs by going through the 1395 list of SFT TLVs contained in the Hop TLV as follows: 1397 A. An SFIR is relevant if it carries RT-z, the SFT in its NLRI 1398 matches the SFT value in one of the SFT TLVs, and the RD 1399 value in its NLRI matches an entry in the list of SFIR-RDs in 1400 that SFT TLV. 1402 B. If an entry in the SFIR-RD list of an SFT TLV contains the 1403 value zero, then an SFIR is relevant if it carries RT-z and 1404 the SFT in its NLRI matches the SFT value in that SFT TLV. 1405 I.e., any SFIR in the service function overlay network 1406 defined by RT-z and with the correct SFT is relevant. 1408 C. If a pool identifier is in use then an SFIR is relevant if it 1409 is a member of the pool. 1411 Each of the relevant SFIRs identifies a single SFI, and contains a 1412 Tunnel Encapsulation attribute that specifies how to send a packet to 1413 that SFI. For a particular packet, the SFF chooses a particular SFI 1414 from the set of relevant SFIRs. This choice is made according to 1415 local policy. 1417 A typical policy might be to figure out the set of SFIs that are 1418 closest, and to load balance among them. But this is not the only 1419 possible policy. 1421 Thus, at any point in time when an SFF selects its next hop, it 1422 chooses from the intersection of the set of next hop RDs contained in 1423 the SFPR and the RDs contained in the SFF's local set of SFIRs (i.e., 1424 according to the determination of "relevance", above). If the 1425 intersection is null, the SFPR is unusable. Similarly, when this 1426 condition applies on the Controller that originated the SFPR, it 1427 SHOULD either withdraw the SFPR or re-advertise it with a new set of 1428 RDs for the affected hop. 1430 6. Looping, Jumping, and Branching 1432 As described in Section 2 an SFI or an SFF may cause a packet to 1433 "loop back" to a previous SF on a path in order that a sequence of 1434 functions may be re-executed. This is simply achieved by replacing 1435 the SI in the NSH with a higher value instead of decreasing it as 1436 would normally be the case to determine the next hop in the path. 1438 Section 2 also describes how an SFI or an SFF may cause a packets to 1439 "jump forward" to an SF on a path that is not the immediate next SF 1440 in the SFP. This is simply achieved by replacing the SI in the NSH 1441 with a lower value than would be achieved by decreasing it by the 1442 normal amount. 1444 A more complex option to move packets from one SFP to another is 1445 described in [RFC8300] and Section 2 where it is termed "branching". 1446 This mechanism allows an SFI or SFF to make a choice of downstream 1447 treatments for packets based on local policy and output of the local 1448 SF. Branching is achieved by changing the SPI in the NSH to indicate 1449 the new path and setting the SI to indicate the point in the path at 1450 which the packets enter. 1452 Note that the NSH does not include a marker to indicate whether a 1453 specific packet has been around a loop before. Therefore, the use of 1454 NSH metadata ([RFC8300]) may be required in order to prevent infinite 1455 loops. 1457 6.1. Protocol Control of Looping, Jumping, and Branching 1459 If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT 1460 value "Change Sequence" (see Section 10) then this is an indication 1461 that the SFF may make a loop, jump, or branch according to local 1462 policy and information returned by the local SFI. 1464 In this case, the SPI and SI of the next hop are encoded in the eight 1465 bytes of an entry in the SFIR-RD list as follows: 1467 3 bytes SPI 1469 1 bytes SI 1471 4 bytes Reserved (SHOULD be set to zero and ignored) 1473 If the SI in this encoding is not part of the SFPR indicated by the 1474 SPI in this encoding, then this is an explicit error that SHOULD be 1475 detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT 1476 cause any forwarding state to be installed in the SFF and packets 1477 received with the SPI that indicates this SFPR SHOULD be silently 1478 discarded. 1480 If the SPI in this encoding is unknown, the SFF SHOULD NOT install 1481 any forwarding state for this SFPR, but MAY hold the SFPR pending 1482 receipt of another SFPR that does use the encoded SPI. 1484 If the SPI matches the current SPI for the path, this is a loop or 1485 jump. In this case, if the SI is greater than to the current SI it 1486 is a loop. If the SPI matches and the SI is less than the next SI, 1487 it is a jump. 1489 If the SPI indicates another path, this is a branch and the SI 1490 indicates the point at which to enter that path. 1492 The Change Sequence SFT is just another SFT that may appear in a set 1493 of SFI/SFT tuples within an SI and is selected as described in 1494 Section 5. 1496 Note that Special Purpose SFTs MUST NOT be advertised in SFIRs. If 1497 such an SFIR is received it SHOULD be ignored. 1499 6.2. Implications for Forwarding State 1501 Support for looping and jumping requires that the SFF has forwarding 1502 state established to an SFF that provides access to an instance of 1503 the appropriate SF. This means that the SFF must have seen the 1504 relevant SFIR advertisements and known that it needed to create the 1505 forwarding state. This is a matter of local configuration and 1506 implementation: for example, an implementation could be configured to 1507 install forwarding state for specific looping/jumping. 1509 Support for branching requires that the SFF has forwarding state 1510 established to an SFF that provides access to an instance of the 1511 appropriate entry SF on the other SFP. This means that the SFF must 1512 have seen the relevant SFIR and SFPR advertisements and known that it 1513 needed to create the forwarding state. This is a matter of local 1514 configuration and implementation: for example, an implementation 1515 could be configured to install forwarding state for specific 1516 branching (identified by SPI and SI). 1518 7. Advanced Topics 1520 This section highlights several advanced topics introduced elsewhere 1521 in this document. 1523 7.1. Correlating Service Function Path Instances 1525 It is often useful to create bidirectional SFPs to enable packet 1526 flows to traverse the same set of SFs, but in the reverse order. 1527 However, packets on SFPs in the data plane (per [RFC8300]) do not 1528 contain a direction indicator, so each direction must use a different 1529 SPI. 1531 As described in Section 3.2.1.1 an SFPR can contain one or more 1532 correlators encoded in Association TLVs. If the Association Type 1533 indicates "Bidirectional SFP" then the SFP advertised in the SFPR is 1534 one direction of a bidirectional pair of SFPs where the other in the 1535 pair is advertised in the SFPR with RD as carried in the Associated 1536 SFPR-RD field of the Association TLV. The SPI carried in the 1537 Associated SPI field of the Association TLV provides a cross-check 1538 against the SPI advertised in the SFPR with RD as carried in the 1539 Associated SFPR-RD field of the Association TLV. 1541 As noted in Section 3.2.1.1, when SFPRs reference each other, one 1542 SFPR advertisement will be received before the other. Therefore, 1543 processing of an association will require that the first SFPR is not 1544 rejected simply because the Associated SFPR-RD it carries is unknown. 1545 However, the SFP defined by the first SFPR is valid and SHOULD be 1546 available for use as a unidirectional SFP even in the absence of an 1547 advertisement of its partner. 1549 Furthermore, in error cases where SFPR-a associates with SFPR-b, but 1550 SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs 1551 cannot be formed, the individual SFPs are still valid and SHOULD be 1552 available for use as unidirectional SFPs. An implementation SHOULD 1553 log this situation because it represents a Controller error. 1555 Usage of a bidirectional SFP may be programmed into the Classifiers 1556 by the Controller. Alternatively, a Classifier may look at incoming 1557 packets on a bidirectional packet flow, extract the SPI from the 1558 received NSH, and look up the SFPR to find the reverse direction SFP 1559 to use when it sends packets. 1561 See Section 8 for an example of how this works. 1563 7.2. Considerations for Stateful Service Functions 1565 Some service functions are stateful. That means that they build and 1566 maintain state derived from configuration or from the packet flows 1567 that they handle. In such cases it can be important or necessary 1568 that all packets from a flow continue to traverse the same instance 1569 of a service function so that the state can be leveraged and does not 1570 need to be regenerated. 1572 In the case of bidirectional SFPs, it may be necessary to traverse 1573 the same instances of a stateful service function in both directions. 1574 A firewall is a good example of such a service function. 1576 This issue becomes a concern where there are multiple parallel 1577 instances of a service function and a determination of which one to 1578 use could normally be left to the SFF as a load-balancing or local 1579 policy choice. 1581 For the forward direction SFP, the concern is that the same choice of 1582 service function is made for all packets of a flow under normal 1583 network conditions. It may be possible to guarantee that the load 1584 balancing functions applied in the SFFs are stable and repeatable, 1585 but a Controller that constructs SFPs might not want to trust to 1586 this. The Controller can, in these cases, build a number of more 1587 specific SFPs each traversing a specific instance of the stateful 1588 SFs. In this case, the load balancing choice can be left up to the 1589 Classifier. Thus the Classifier selects which instance of a stateful 1590 SF is used by a particular flow by selecting the SFP that the flow 1591 uses. 1593 For bidirectional SFPs where the same instance of a stateful SF must 1594 be traversed in both directions, it is not enough to leave the choice 1595 of service function instance as a local choice even if the load 1596 balancing is stable because coordination would be required between 1597 the decision points in the forward and reverse directions and this 1598 may be hard to achieve in all cases except where it is the same SFF 1599 that makes the choice in both directions. 1601 Note that this approach necessarily increases the amount of SFP state 1602 in the network (i.e., there are more SFPs). It is possible to 1603 mitigate this effect by careful construction of SFPs built from a 1604 concatenation of other SFPs. 1606 Section 8.9 includes some simple examples of SFPs for stateful 1607 service functions. 1609 7.3. VPN Considerations and Private Service Functions 1611 Likely deployments include reserving specific instances of Service 1612 Functions for specific customers or allowing customers to deploy 1613 their own Service Functions within the network. Building Service 1614 Functions in such environments requires that suitable identifiers are 1615 used to ensure that SFFs distinguish which SFIs can be used and which 1616 cannot. 1618 This problem is similar to how VPNs are supported and is solved in a 1619 similar way. The RT field is used to indicate a set of Service 1620 Functions from which all choices must be made. 1622 7.4. Flow Specification for SFC Classifiers 1624 [I-D.ietf-idr-rfc5575bis] defines a set of BGP routes that can be 1625 used to identify the packets in a given flow using fields in the 1626 header of each packet, and a set of actions, encoded as extended 1627 communities, that can be used to disposition those packets. This 1628 document enables the use of these mechanisms by SFC Classifiers by 1629 defining a new action extended community called "Flow Specification 1630 for SFC Classifiers" identified by the value TBD4. Note that 1631 implementation of this section of this specification will be 1632 Controllers or Classifiers communicating with each other directly for 1633 the purpose of instructing the Classifier how to place packets onto 1634 an SFP. In order that the implementation of Classifiers can be kept 1635 simple and to avoid the confusion between the purpose of different 1636 extended communities, a Controller MUST NOT include other action 1637 extended communities at the same time as a "Flow Specification for 1638 SFC Classifiers" extended community: a "Flow Specification for SFC 1639 Classifiers" Traffic Filtering Action Extended Community advertised 1640 with any other Traffic Filtering Action Extended Community MUST be 1641 treated as malformed in line with [I-D.ietf-idr-rfc5575bis] and 1642 result in the Flow Specification UPDATE message being handled as 1643 treat-as-withdraw according to [RFC7606] Section 2. 1645 To put the Flow Specification into context when multiple SFC overlays 1646 are present in one network, each FlowSpec update MUST be tagged with 1647 the route target of the overlay or VPN network for which it is 1648 intended. 1650 This extended community is encoded as an 8-octet value, as shown in 1651 Figure 10. 1653 1 2 3 1654 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 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Type=0x80 | Sub-Type=TBD4 | SPI | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | SPI (cont.) | SI | SFT | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 Figure 10: The Format of the Flow Specification for SFC Classifiers 1662 Extended Community 1664 The extended community contains the Service Path Identifier (SPI), 1665 Service Index (SI), and Service Function Type (SFT) as defined 1666 elsewhere in this document. Thus, each action extended community 1667 defines the entry point (not necessarily the first hop) into a 1668 specific service function path. This allows, for example, different 1669 flows to enter the same service function path at different points. 1671 Note that according to [I-D.ietf-idr-rfc5575bis] a given Flow 1672 Specification update may include multiple of these action extended 1673 communities. If a given action extended community does not contain 1674 an installed SFPR with the specified {SPI, SI, SFT} it MUST NOT be 1675 used for dispositioning the packets of the specified flow. 1677 The normal case of packet classification for SFC will see a packet 1678 enter the SFP at its first hop. In this case the SI in the extended 1679 community is superfluous and the SFT may also be unnecessary. To 1680 allow these cases to be handled, a special meaning is assigned to a 1681 Service Index of zero (not a valid value) and an SFT of zero (a 1682 reserved value in the registry - see Section 10.5). 1684 o If an SFC Classifiers Extended Community is received with SI = 0 1685 then it means that the first hop of the SFP indicated by the SPI 1686 MUST be used. 1688 o If an SFC Classifiers Extended Community is received with SFT = 0 1689 then there are two sub-cases: 1691 * If there is a choice of SFT in the hop indicated by the value 1692 of the SI (including SI = 0) then SFT = 0 means there is a free 1693 choice according to local policy of which SFT to use). 1695 * If there is no choice of SFT in the hop indicated by the value 1696 of SI, then SFT = 0 means that the value of the SFT at that hop 1697 as indicated in the SFPR for the indicated SPI MUST be used. 1699 One of the filters that the Flow Specification may describe is the 1700 VPN to which the traffic belongs. Additionally, as noted above, to 1701 put the indicated SPI into context when multiple SFC overlays are 1702 present in one network, each FlowSpec update MUST be tagged with the 1703 route target of the overlay or VPN network for which it is intended. 1705 Note that future extensions might be made to the Flow Specification 1706 for SFC Classifiers Extended Community to provide instruction to the 1707 Classifier about what metadata to add to packets that it classifies 1708 for forwarding on a specific SFP, but that is outside the scope of 1709 this document. 1711 7.5. Choice of Data Plane SPI/SI Representation 1713 This document ties together the control and data planes of an SFC 1714 overlay network through the use of the SPI/SI which is nominally 1715 carried in the NSH of a given packet. However, in order to handle 1716 situations in which the NSH is not ubiquitously deployed, it is also 1717 possible to use alternative data plane representations of the SPI/SI 1718 by carrying the identical semantics in other protocol fields such as 1719 MPLS labels [RFC8595]. 1721 This document defines a new sub-TLV for the Tunnel Encapsulation 1722 attribute [I-D.ietf-idr-tunnel-encaps], the SPI/SI Representation 1723 sub-TLV of type TBD5. This sub-TLV MAY be present in each Tunnel TLV 1724 contained in a Tunnel Encapsulation attribute when the attribute is 1725 carried by an SFIR. The value field of this sub-TLV is a two octet 1726 field of flags numbered counting from the the most significant bit, 1727 each of which describes how the originating SFF expects to see the 1728 SPI/SI represented in the data plane for packets carried in the 1729 tunnels described by the Tunnel TLV. 1731 The following bits are defined by this document and are tracked in an 1732 IANA registry described in Section 10.10: 1734 Bit TBD9: If this bit is set the NSH is to be used to carry the SPI/ 1735 SI in the data plane. 1737 Bit TBD10: If this bit is set two labels in an MPLS label stack are 1738 to be used as described in Section 7.5.1. 1740 If a given Tunnel TLV does not contain an SPI/SI Representation sub- 1741 TLV then it MUST be processed as if such a sub-TLV is present with 1742 Bit TBD9 set and no other bits set. That is, the absence of the sub- 1743 TLV SHALL be interpreted to mean that the NSH is to be used. 1745 If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with 1746 value field that has no flag set then the tunnel indicated by the 1747 Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given 1748 Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit 1749 TBD9 and bit TBD10 set then the tunnel indicated by the Tunnel TLV 1750 MUST NOT be used for forwarding SFC packets. The meaning and rules 1751 for presence of other bits is to be defined in future documents, but 1752 implementations of this specification MUST set other bits to zero and 1753 ignore them on receipt. 1755 If a given Tunnel TLV contains more than one SPI/SI Representation 1756 sub-TLV then the first one MUST be considered and subsequent 1757 instances MUST be ignored. 1759 Note that the MPLS representation of the logical NSH may be used even 1760 if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be 1761 used to carry other encodings of the logical NSH (specifically, the 1762 NSH itself). It is a requirement that both ends of a tunnel over the 1763 underlay network know that the tunnel is used for SFC and know what 1764 form of NSH representation is used. The signaling mechanism 1765 described here allows coordination of this information. 1767 7.5.1. MPLS Representation of the SPI/SI 1769 If bit TBD10 is set in the in the SPI/SI Representation sub-TLV then 1770 labels in the MPLS label stack are used to indicate SFC forwarding 1771 and processing instructions to achieve the semantics of a logical 1772 NSH. The label stack is encoded as shown in [RFC8595]. 1774 7.6. MPLS Label Swapping/Stacking Operation 1776 When a Classifier constructs an MPLS label stack for an SFP it starts 1777 with that SFP's last hop. If the last hop requires an {SPI, SI} 1778 label pair for label swapping, it pushes the SI (set to the SI value 1779 of the last hop) and the SFP's SPI onto the MPLS label stack. If the 1780 last hop requires a {context label, SFI label} label pair for label 1781 stacking it selects a specific SFIR and pushes that SFIR's SFI label 1782 and context label onto the MPLS label stack. 1784 The Classifier then moves sequentially back through the SFP one hop 1785 at a time. For each hop, if the hop requires an {SPI, SI]} and there 1786 is an {SPI, SI} at the top of the MPLS label stack, the SI is set to 1787 the SI value of the current hop. If there is not an {SPI, SI} at the 1788 top of the MPLS label stack, it pushes the SI (set to the SI value of 1789 the current hop) and the SFP's SPI onto the MPLS label stack. 1791 If the hop requires a {context label, SFI label}, it selects a 1792 specific SFIR and pushes that SFIR's SFI label and context label onto 1793 the MPLS label stack. 1795 7.7. Support for MPLS-Encapsulated NSH Packets 1797 [RFC8596] describes how to transport SFC packets using the NSH over 1798 an MPLS transport network. Signaling MPLS encapsulation of SFC 1799 packets using the NSH is also supported by this document by using the 1800 "BGP Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10 1801 (representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation 1802 Attribute Sub-TLVs" registry defined in [I-D.ietf-idr-tunnel-encaps], 1803 and also using the "SFP Traversal With MPLS Label Stack TLV" and the 1804 "SPI/SI Representation sub-TLV" with bit TBD9 set and bit TBD10 1805 cleared. 1807 In this case the MPLS label stack constructed by the SFF to forward a 1808 packet to the next SFF on the SFP will consist of the labels needed 1809 to reach that SFF, and if label stacking is used it will also include 1810 the labels advertised in the MPLS Label Stack sub-TLV and the labels 1811 remaining in the stack needed to traverse the remainder of the SFP. 1813 8. Examples 1815 Most of the examples in this section use IPv4 addressing. But there 1816 is nothing special about IPv4 in the mechanisms described in this 1817 document, and they are equally applicable to IPv6. A few examples 1818 using IPv6 addressing are provided in Section 8.10. 1820 Assume we have a service function overlay network with four SFFs 1821 (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the 1822 underlay network as follows: 1824 SFF1 192.0.2.1 1825 SFF2 192.0.2.2 1826 SFF3 192.0.2.3 1827 SFF4 192.0.2.4 1829 Each SFF provides access to some SFIs from the four Service Function 1830 Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows: 1832 SFF1 SFT=41 and SFT=42 1833 SFF2 SFT=41 and SFT=43 1834 SFF3 SFT=42 and SFT=44 1835 SFF4 SFT=43 and SFT=44 1837 The service function network also contains a Controller with address 1838 198.51.100.1. 1840 This example service function overlay network is shown in Figure 11. 1842 -------------- 1843 | Controller | 1844 | 198.51.100.1 | ------ ------ ------ ------ 1845 -------------- | SFI | | SFI | | SFI | | SFI | 1846 |SFT=41| |SFT=42| |SFT=41| |SFT=43| 1847 ------ ------ ------ ------ 1848 \ / \ / 1849 --------- --------- 1850 ---------- | SFF1 | | SFF2 | 1851 Packet --> | | |192.0.2.1| |192.0.2.2| 1852 Flows --> |Classifier| --------- --------- -->Dest 1853 | | --> 1854 ---------- --------- --------- 1855 | SFF3 | | SFF4 | 1856 |192.0.2.3| |192.0.2.4| 1857 --------- --------- 1858 / \ / \ 1859 ------ ------ ------ ------ 1860 | SFI | | SFI | | SFI | | SFI | 1861 |SFT=42| |SFT=44| |SFT=43| |SFT=44| 1862 ------ ------ ------ ------ 1864 Figure 11: Example Service Function Overlay Network 1866 The SFFs advertise routes to the SFIs they support. These 1867 advertisements contain Route Distinguishers that are set according to 1868 the network operator's configuration model. In all of these IPv4 1869 examples we use RDs of type 1 such that the available six octets are 1870 partitioned as four octets for the IPv4 address of the advertising 1871 SFF, and two octets that are a local index of the SFI. This scheme 1872 is chosen purely for convenience of documentation, and an operator is 1873 totally free to use any other scheme so long as it conforms to the 1874 definitions of SFIR and SFPR in Section 3.1 and Section 3.2. 1876 Thus we see the following SFIRs advertised: 1878 RD = 192.0.2.1/1, SFT = 41 1879 RD = 192.0.2.1/2, SFT = 42 1880 RD = 192.0.2.2/1, SFT = 41 1881 RD = 192.0.2.2/2, SFT = 43 1882 RD = 192.0.2.3/7, SFT = 42 1883 RD = 192.0.2.3/8, SFT = 44 1884 RD = 192.0.2.4/5, SFT = 43 1885 RD = 192.0.2.4/6, SFT = 44 1887 Note that the addressing used for communicating between SFFs is taken 1888 from the Tunnel Encapsulation attribute of the SFIR and not from the 1889 SFIR-RD. 1891 8.1. Example Explicit SFP With No Choices 1893 Consider the following SFPR. 1895 SFP1: RD = 198.51.100.1/101, SPI = 15, 1896 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 1897 [SI = 250, SFT = 43, RD = 192.0.2.2/2] 1899 The Service Function Path consists of an SF of type 41 located at 1900 SFF1 followed by an SF of type 43 located at SFF2. This path is 1901 fully explicit and each SFF is offered no choice in forwarding 1902 packets along the path. 1904 SFF1 will receive packets on the path from the Classifier and will 1905 identify the path from the SPI (15). The initial SI will be 255 and 1906 so SFF1 will deliver the packets to the SFI for SFT 41. 1908 When the packets are returned to SFF1 by the SFI the SI will be 1909 decreased to 250 for the next hop. SFF1 has no flexibility in the 1910 choice of SFF to support the next hop SFI and will forward the packet 1911 to SFF2 which will send the packets to the SFI that supports SFT 43 1912 before forwarding the packets to their destinations. 1914 8.2. Example SFP With Choice of SFIs 1916 SFP2: RD = 198.51.100.1/102, SPI = 16, 1917 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 1918 [SI = 250, SFT = 43, {RD = 192.0.2.2/2, 1919 RD = 192.0.2.4/5 } ] 1921 In this example the path also consists of an SF of type 41 located at 1922 SFF1 and this is followed by an SF of type 43, but in this case the 1923 SI = 250 contains a choice between the SFI located at SFF2 and the 1924 SFI located at SFF4. 1926 SFF1 will receive packets on the path from the Classifier and will 1927 identify the path from the SPI (16). The initial SI will be 255 and 1928 so SFF1 will deliver the packets to the SFI for SFT 41. 1930 When the packets are returned to SFF1 by the SFI the SI will be 1931 decreased to 250 for the next hop. SFF1 now has a choice of next hop 1932 SFF to execute the next hop in the path. It can either forward 1933 packets to SFF2 or SFF4 to execute a function of type 43. It uses 1934 its local load balancing algorithm to make this choice. The chosen 1935 SFF will send the packets to the SFI that supports SFT 43 before 1936 forwarding the packets to their destinations. 1938 8.3. Example SFP With Open Choice of SFIs 1940 SFP3: RD = 198.51.100.1/103, SPI = 17, 1941 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 1942 [SI = 250, SFT = 44, RD = 0] 1944 In this example the path also consists of an SF of type 41 located at 1945 SFF1 and this is followed by an SI with an RD of zero and SF of type 1946 44. This means that a choice can be made between any SFF that 1947 supports an SFI of type 44. 1949 SFF1 will receive packets on the path from the Classifier and will 1950 identify the path from the SPI (17). The initial SI will be 255 and 1951 so SFF1 will deliver the packets to the SFI for SFT 41. 1953 When the packets are returned to SFF1 by the SFI the SI will be 1954 decreased to 250 for the next hop. SFF1 now has a free choice of 1955 next hop SFF to execute the next hop in the path selecting between 1956 all SFFs that support SFs of type 44. Looking at the SFIRs it has 1957 received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. 1958 SFF1 uses its local load balancing algorithm to make this choice. 1959 The chosen SFF will send the packets to the SFI that supports SFT 44 1960 before forwarding the packets to their destinations. 1962 8.4. Example SFP With Choice of SFTs 1964 SFP4: RD = 198.51.100.1/104, SPI = 18, 1965 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 1966 [SI = 250, {SFT = 43, RD = 192.0.2.2/2, 1967 SFT = 44, RD = 192.0.2.3/8 } ] 1969 This example provides a choice of SF type in the second hop in the 1970 path. The SI of 250 indicates a choice between SF type 43 located at 1971 SF2 and SF type 44 located at SF3. 1973 SFF1 will receive packets on the path from the Classifier and will 1974 identify the path from the SPI (18). The initial SI will be 255 and 1975 so SFF1 will deliver the packets to the SFI for SFT 41. 1977 When the packets are returned to SFF1 by the SFI the SI will be 1978 decreased to 250 for the next hop. SFF1 now has a free choice of 1979 next hop SFF to execute the next hop in the path selecting between 1980 all SFFs that support an SF of type 43 and SFF3 that supports an SF 1981 of type 44. These may be completely different functions that are to 1982 be executed dependent on specific conditions, or may be similar 1983 functions identified with different type identifiers (such as 1984 firewalls from different vendors). SFF1 uses its local policy and 1985 load balancing algorithm to make this choice, and may use additional 1986 information passed back from the local SFI to help inform its 1987 selection. The chosen SFF will send the packets to the SFI that 1988 supports the chose SFT before forwarding the packets to their 1989 destinations. 1991 8.5. Example Correlated Bidirectional SFPs 1993 SFP5: RD = 198.51.100.1/105, SPI = 19, 1994 Assoc-Type = 1, Assoc-RD = 198.51.100.1/106, Assoc-SPI = 20, 1995 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 1996 [SI = 250, SFT = 43, RD = 192.0.2.2/2] 1998 SFP6: RD = 198.51.100.1/106, SPI = 20, 1999 Assoc-Type = 1, Assoc-RD = 198.51.100.1/105, Assoc-SPI = 19, 2000 [SI = 254, SFT = 43, RD = 192.0.2.2/2], 2001 [SI = 249, SFT = 41, RD = 192.0.2.1/1] 2003 This example demonstrates correlation of two SFPs to form a 2004 bidirectional SFP as described in Section 7.1. 2006 Two SFPRs are advertised by the Controller. They have different SPIs 2007 (19 and 20) so they are known to be separate SFPs, but they both have 2008 Association TLVs with Association Type set to 1 indicating 2009 bidirectional SFPs. Each has an Associated SFPR-RD field containing 2010 the value of the other SFPR-RD to correlated the two SFPs as a 2011 bidirectional pair. 2013 As can be seen from the SFPRs in this example, the paths are 2014 symmetric: the hops in SFP5 appear in the reverse order in SFP6. 2016 8.6. Example Correlated Asymmetrical Bidirectional SFPs 2018 SFP7: RD = 198.51.100.1/107, SPI = 21, 2019 Assoc-Type = 1, Assoc-RD = 198.51.100.1/108, Assoc-SPI = 22, 2020 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 2021 [SI = 250, SFT = 43, RD = 192.0.2.2/2] 2023 SFP8: RD = 198.51.100.1/108, SPI = 22, 2024 Assoc-Type = 1, Assoc-RD = 198.51.100.1/107, Assoc-SPI = 21, 2025 [SI = 254, SFT = 44, RD = 192.0.2.4/6], 2026 [SI = 249, SFT = 41, RD = 192.0.2.1/1] 2028 Asymmetric bidirectional SFPs can also be created. This example 2029 shows a pair of SFPs with distinct SPIs (21 and 22) that are 2030 correlated in the same way as in the example in Section 8.5. 2032 However, unlike in that example, the SFPs are different in each 2033 direction. Both paths include a hop of SF type 41, but SFP7 includes 2034 a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF 2035 type 44 supported at SFF4. 2037 8.7. Example Looping in an SFP 2039 SFP9: RD = 198.51.100.1/109, SPI = 23, 2040 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 2041 [SI = 250, SFT = 44, RD = 192.0.2.4/5], 2042 [SI = 245, {SFT = 1, RD = {SPI=23, SI=255, Rsv=0}, 2043 SFT = 42, RD = 192.0.2.3/7 } ] 2045 Looping and jumping are described in Section 6. This example shows 2046 an SFP that contains an explicit loop-back instruction that is 2047 presented as a choice within an SFP hop. 2049 The first two hops in the path (SI = 255 and SI = 250) are normal. 2050 That is, the packets will be delivered to SFF1 and SFF4 in turn for 2051 execution of SFs of type 41 and 44 respectively. 2053 The third hop (SI = 245) presents SFF4 with a choice of next hop. It 2054 can either forward the packets to SFF3 for an SF of type 42 (the 2055 second choice), or it can loop back. 2057 The loop-back entry in the SFPR for SI = 245 is indicated by the 2058 special purpose SFT value 1 ("Change Sequence"). Within this hop, 2059 the RD is interpreted as encoding the SPI and SI of the next hop (see 2060 Section 6.1. In this case the SPI is 23 which indicates that this is 2061 loop or branch: i.e., the next hop is on the same SFP. The SI is set 2062 to 255: this is a higher number than the current SI (245) indicating 2063 a loop. 2065 SFF4 must make a choice between these two next hops. Either the 2066 packets will be forwarded to SFF3 with the NSH SI decreased to 245 or 2067 looped back to SFF1 with the NSH SI reset to 255. This choice will 2068 be made according to local policy, information passed back by the 2069 local SFI, and details in the packets' metadata that are used to 2070 prevent infinite looping. 2072 8.8. Example Branching in an SFP 2074 SFP10: RD = 198.51.100.1/110, SPI = 24, 2075 [SI = 254, SFT = 42, RD = 192.0.2.3/7], 2076 [SI = 249, SFT = 43, RD = 192.0.2.2/2] 2078 SFP11: RD = 198.51.100.1/111, SPI = 25, 2079 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 2080 [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}] 2082 Branching follows a similar procedure to that for looping (and 2083 jumping) as shown in Section 8.7 however there are two SFPs involved. 2085 SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for 2086 execution of service functions of type 42 and 43 respectively. 2088 SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1 2089 processes the next hop in the path and finds a "Change Sequence" 2090 Special Purpose SFT. The SFIR-RD field includes an SPI of 24 which 2091 indicates SFP10, not the current SFP. The SI in the SFIR-RD is 254, 2092 so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and 2093 send the packets to the appropriate SFF as advertised in the SFPR for 2094 SFP10 (that is, SFF3). 2096 8.9. Examples of SFPs with Stateful Service Functions 2098 This section provides some examples to demonstrate establishing SFPs 2099 when there is a choice of service functions at a particular hop, and 2100 where consistency of choice is required in both directions. The 2101 scenarios that give rise to this requirement are discussed in 2102 Section 7.2. 2104 8.9.1. Forward and Reverse Choice Made at the SFF 2106 Consider the topology shown in Figure 12. There are three SFFs 2107 arranged neatly in a line, and the middle one (SFF2) supports three 2108 SFIs all of SFT 42. These three instances can be used by SFF2 to 2109 load balance so that no one instance is swamped. 2111 ------ ------ ------ ------ ------ 2112 | SFI | | SFIa | | SFIb | | SFIc | | SFI | 2113 |SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43| 2114 ------ ------\ ------ /------ ------ 2115 \ \ | / / 2116 --------- --------- --------- 2117 ---------- | SFF1 | | SFF2 | | SFF3 | 2118 --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> 2119 --> |Classifier| --------- --------- --------- 2120 | | 2121 ---------- 2123 Figure 12: Example Where Choice is Made at the SFF 2125 This leads to the following SFIRs being advertised. 2127 RD = 192.0.2.1/11, SFT = 41 2128 RD = 192.0.2.2/11, SFT = 42 (for SFIa) 2129 RD = 192.0.2.2/12, SFT = 42 (for SFIb) 2130 RD = 192.0.2.2/13, SFT = 42 (for SFIc) 2131 RD = 192.0.2.3/11, SFT = 43 2133 The controller can create a single forward SFP (SFP12) giving SFF2 2134 the choice of which SFI to use to provide function of SFT 42 as 2135 follows. The load-balancing choice between the three available SFIs 2136 is assumed to be within the capabilities of the SFF and if the SFs 2137 are stateful it is assumed that the SFF knows this and arranges load 2138 balancing in a stable, flow-dependent way. 2140 SFP12: RD = 198.51.100.1/112, SPI = 26, 2141 Assoc-Type = 1, Assoc-RD = 198.51.100.1/113, Assoc-SPI = 27, 2142 [SI = 255, SFT = 41, RD = 192.0.2.1/11], 2143 [SI = 254, SFT = 42, {RD = 192.0.2.2/11, 2144 192.0.2.2/12, 2145 192.0.2.2/13 }], 2146 [SI = 253, SFT = 43, RD = 192.0.2.3/11] 2148 The reverse SFP (SFP13) in this case may also be created as shown 2149 below using association with the forward SFP and giving the load- 2150 balancing choice to SFF2. This is safe, even in the case that the 2151 SFs of type 42 are stateful because SFF2 is doing the load balancing 2152 in both directions and can apply the same algorithm to ensure that 2153 packets associated with the same flow use the same SFI regardless of 2154 the direction of travel. 2156 SFP13: RD = 198.51.100.1/113, SPI = 27, 2157 Assoc-Type = 1, Assoc-RD = 198.51.100.1/112, Assoc-SPI = 26, 2158 [SI = 255, SFT = 43, RD = 192.0.2.3/11], 2159 [SI = 254, SFT = 42, {RD = 192.0.2.2/11, 2160 192.0.2.2/12, 2161 192.0.2.2/13 }], 2162 [SI = 253, SFT = 41, RD = 192.0.2.1/11] 2164 How an SFF knows that an attached SFI is stateful is out of scope of 2165 this document. It is assumed that this will form part of the process 2166 by which SFIs are registered as local to SFFs. Section 7.2 provides 2167 additional observations about the coordination of the use of stateful 2168 SFIs in the case of bidirectional SFPs. 2170 In general, the problems of load balancing and the selection of the 2171 same SFIs in both directions of a bidirectional SFP can be addressed 2172 by using sufficiently precisely specified SFPs (specifying the exact 2173 SFIs to use) and suitable programming of the Classifiers at each end 2174 of the SFPs to make sure that the matching pair of SFPs are used. 2176 8.9.2. Parallel End-to-End SFPs with Shared SFF 2178 The mechanism described in Section 8.9.1 might not be desirable 2179 because of the functional assumptions it places on SFF2 to be able to 2180 load balance with suitable flow identification, stability, and 2181 equality in both directions. Instead, it may be desirable to place 2182 the responsibility for flow classification in the Classifier and let 2183 it determine load balancing with the implied choice of SFIs. 2185 Consider the network graph as shown in Figure 12 and with the same 2186 set of SFIRs as listed in Section 8.9.1. In this case the controller 2187 could specify three forward SFPs with their corresponding associated 2188 reverse SFPs. Each bidirectional pair of SFPs uses a different SFI 2189 for the SF of type 42. The controller can instruct the Classifier 2190 how to place traffic on the three bidirectional SFPs, or can treat 2191 them as a group leaving the Classifier responsible for balancing the 2192 load. 2194 SFP14: RD = 198.51.100.1/114, SPI = 28, 2195 Assoc-Type = 1, Assoc-RD = 198.51.100.1/117, Assoc-SPI = 31, 2196 [SI = 255, SFT = 41, RD = 192.0.2.1/11], 2197 [SI = 254, SFT = 42, RD = 192.0.2.2/11], 2198 [SI = 253, SFT = 43, RD = 192.0.2.3/11] 2200 SFP15: RD = 198.51.100.1/115, SPI = 29, 2201 Assoc-Type = 1, Assoc-RD = 198.51.100.1/118, Assoc-SPI = 32, 2202 [SI = 255, SFT = 41, RD = 192.0.2.1/11], 2203 [SI = 254, SFT = 42, RD = 192.0.2.2/12], 2204 [SI = 253, SFT = 43, RD = 192.0.2.3/11] 2206 SFP16: RD = 198.51.100.1/116, SPI = 30, 2207 Assoc-Type = 1, Assoc-RD = 198.51.100.1/119, Assoc-SPI = 33, 2208 [SI = 255, SFT = 41, RD = 192.0.2.1/11], 2209 [SI = 254, SFT = 42, RD = 192.0.2.2/13], 2210 [SI = 253, SFT = 43, RD = 192.0.2.3/11] 2212 SFP17: RD = 198.51.100.1/117, SPI = 31, 2213 Assoc-Type = 1, Assoc-RD = 198.51.100.1/114, Assoc-SPI = 28, 2214 [SI = 255, SFT = 43, RD = 192.0.2.3/11], 2215 [SI = 254, SFT = 42, RD = 192.0.2.2/11], 2216 [SI = 253, SFT = 41, RD = 192.0.2.1/11] 2218 SFP18: RD = 198.51.100.1/118, SPI = 32, 2219 Assoc-Type = 1, Assoc-RD = 198.51.100.1/115, Assoc-SPI = 29, 2220 [SI = 255, SFT = 43, RD = 192.0.2.3/11], 2221 [SI = 254, SFT = 42, RD = 192.0.2.2/12], 2222 [SI = 253, SFT = 41, RD = 192.0.2.1/11] 2224 SFP19: RD = 198.51.100.1/119, SPI = 33, 2225 Assoc-Type = 1, Assoc-RD = 198.51.100.1/116, Assoc-SPI = 30, 2226 [SI = 255, SFT = 43, RD = 192.0.2.3/11], 2227 [SI = 254, SFT = 42, RD = 192.0.2.2/13], 2228 [SI = 253, SFT = 41, RD = 192.0.2.1/11] 2230 8.9.3. Parallel End-to-End SFPs with Separate SFFs 2232 While the examples in Section 8.9.1 and Section 8.9.2 place the 2233 choice of SFI as subtended from the same SFF, it is also possible 2234 that the SFIs are each subtended from a different SFF as shown in 2235 Figure 13. In this case it is harder to coordinate the choices for 2236 forward and reverse paths without some form of coordination between 2237 SFF1 and SFF3. Therefore it would be normal to consider end-to-end 2238 parallel SFPs as described in Section 8.9.2. 2240 ------ 2241 | SFIa | 2242 |SFT=42| 2243 ------ 2244 ------ | 2245 | SFI | --------- 2246 |SFT=41| | SFF5 | 2247 ------ ..|192.0.2.5|.. 2248 | ..: --------- :.. 2249 ---------.: :.--------- 2250 ---------- | SFF1 | --------- | SFF3 | 2251 --> | |..|192.0.2.1|....| SFF6 |....|192.0.2.3| --> 2252 --> |Classifier| ---------: |192.0.2.6| :--------- 2253 | | : --------- : | 2254 ---------- : | : ------ 2255 : ------ : | SFI | 2256 :.. | SFIb | ..: |SFT=43| 2257 :.. |SFT=42| ..: ------ 2258 : ------ : 2259 :.---------.: 2260 | SFF7 | 2261 |192.0.2.7| 2262 --------- 2263 | 2264 ------ 2265 | SFIc | 2266 |SFT=42| 2267 ------ 2269 Figure 13: Second Example With Parallel End-to-End SFPs 2271 In this case, five SFIRs are advertised as follows: 2273 RD = 192.0.2.1/11, SFT = 41 2274 RD = 192.0.2.5/11, SFT = 42 (for SFIa) 2275 RD = 192.0.2.6/11, SFT = 42 (for SFIb) 2276 RD = 192.0.2.7/11, SFT = 42 (for SFIc) 2277 RD = 192.0.2.3/11, SFT = 43 2279 In this case the controller could specify three forward SFPs with 2280 their corresponding associated reverse SFPs. Each bidirectional pair 2281 of SFPs uses a different SFF and SFI for middle hop (for an SF of 2282 type 42). The controller can instruct the Classifier how to place 2283 traffic on the three bidirectional SFPs, or can treat them as a group 2284 leaving the Classifier responsible for balancing the load. 2286 SFP20: RD = 198.51.100.1/120, SPI = 34, 2287 Assoc-Type = 1, Assoc-RD = 198.51.100.1/123, Assoc-SPI = 37, 2288 [SI = 255, SFT = 41, RD = 192.0.2.1/11], 2289 [SI = 254, SFT = 42, RD = 192.0.2.5/11], 2290 [SI = 253, SFT = 43, RD = 192.0.2.3/11] 2292 SFP21: RD = 198.51.100.1/121, SPI = 35, 2293 Assoc-Type = 1, Assoc-RD = 198.51.100.1/124, Assoc-SPI = 38, 2294 [SI = 255, SFT = 41, RD = 192.0.2.1/11], 2295 [SI = 254, SFT = 42, RD = 192.0.2.6/11], 2296 [SI = 253, SFT = 43, RD = 192.0.2.3/11] 2298 SFP22: RD = 198.51.100.1/122, SPI = 36, 2299 Assoc-Type = 1, Assoc-RD = 198.51.100.1/125, Assoc-SPI = 39, 2300 [SI = 255, SFT = 41, RD = 192.0.2.1/11], 2301 [SI = 254, SFT = 42, RD = 192.0.2.7/11], 2302 [SI = 253, SFT = 43, RD = 192.0.2.3/11] 2304 SFP23: RD = 198.51.100.1/123, SPI = 37, 2305 Assoc-Type = 1, Assoc-RD = 198.51.100.1/120, Assoc-SPI = 34, 2306 [SI = 255, SFT = 43, RD = 192.0.2.3/11], 2307 [SI = 254, SFT = 42, RD = 192.0.2.5/11], 2308 [SI = 253, SFT = 41, RD = 192.0.2.1/11] 2310 SFP24: RD = 198.51.100.1/124, SPI = 38, 2311 Assoc-Type = 1, Assoc-RD = 198.51.100.1/121, Assoc-SPI = 35, 2312 [SI = 255, SFT = 43, RD = 192.0.2.3/11], 2313 [SI = 254, SFT = 42, RD = 192.0.2.6/11], 2314 [SI = 253, SFT = 41, RD = 192.0.2.1/11] 2316 SFP25: RD = 198.51.100.1/125, SPI = 39, 2317 Assoc-Type = 1, Assoc-RD = 198.51.100.1/122, Assoc-SPI = 36, 2318 [SI = 255, SFT = 43, RD = 192.0.2.3/11], 2319 [SI = 254, SFT = 42, RD = 192.0.2.7/11], 2320 [SI = 253, SFT = 41, RD = 192.0.2.1/11] 2322 8.9.4. Parallel SFPs Downstream of the Choice 2324 The mechanism of parallel SFPs demonstrated in Section 8.9.3 is 2325 perfectly functional and may be practical in many environments. 2326 However, there may be scaling concerns because of the large amount of 2327 state (knowledge of SFPs, i.e., SFPR advertisements retained) if 2328 there is a very large amount of choice of SFIs (for example, tens of 2329 instances of the same stateful SF), or if there are multiple choices 2330 of stateful SF along a path. This situation may be mitigated using 2331 SFP fragments that are combined to form the end to end SFPs. 2333 The example presented here is necessarily simplistic, but should 2334 convey the basic principle. The example presented in Figure 14 is 2335 similar to that in Section 8.9.3 but with an additional first hop. 2337 ------ 2338 | SFIa | 2339 |SFT=43| 2340 ------ 2341 ------ ------ | 2342 | SFI | | SFI | --------- 2343 |SFT=41| |SFT=42| | SFF5 | 2344 ------ ------ ..|192.0.2.5|.. 2345 | | ..: --------- :.. 2346 --------- ---------.: :.--------- 2347 ------ | SFF1 | | SFF2 | --------- | SFF3 | 2348 -->|Class-|.|192.0.2.1|.|192.0.2.2|....| SFF6 |....|192.0.2.3|--> 2349 -->| ifier| --------- ---------: |192.0.2.6| :--------- 2350 ------ : --------- : | 2351 : | : ------ 2352 : ------ : | SFI | 2353 :.. | SFIb | ..: |SFT=44| 2354 :.. |SFT=43| ..: ------ 2355 : ------ : 2356 :.---------.: 2357 | SFF7 | 2358 |192.0.2.7| 2359 --------- 2360 | 2361 ------ 2362 | SFIc | 2363 |SFT=43| 2364 ------ 2366 Figure 14: Example With Parallel SFPs Downstream of Choice 2368 The six SFIs are advertised as follows: 2370 RD = 192.0.2.1/11, SFT = 41 2371 RD = 192.0.2.2/11, SFT = 42 2372 RD = 192.0.2.5/11, SFT = 43 (for SFIa) 2373 RD = 192.0.2.6/11, SFT = 43 (for SFIb) 2374 RD = 192.0.2.7/11, SFT = 43 (for SFIc) 2375 RD = 192.0.2.3/11, SFT = 44 2377 SFF2 is the point at which a load balancing choice must be made. So 2378 "tail-end" SFPs are constructed as follows. Each takes in a 2379 different SFF that provides access to an SF of type 43. 2381 SFP26: RD = 198.51.100.1/126, SPI = 40, 2382 Assoc-Type = 1, Assoc-RD = 198.51.100.1/130, Assoc-SPI = 44, 2383 [SI = 255, SFT = 43, RD = 192.0.2.5/11], 2384 [SI = 254, SFT = 44, RD = 192.0.2.3/11] 2386 SFP27: RD = 198.51.100.1/127, SPI = 41, 2387 Assoc-Type = 1, Assoc-RD = 198.51.100.1/131, Assoc-SPI = 45, 2388 [SI = 255, SFT = 43, RD = 192.0.2.6/11], 2389 [SI = 254, SFT = 44, RD = 192.0.2.3/11] 2391 SFP28: RD = 198.51.100.1/128, SPI = 42, 2392 Assoc-Type = 1, Assoc-RD = 198.51.100.1/132, Assoc-SPI = 46, 2393 [SI = 255, SFT = 43, RD = 192.0.2.7/11], 2394 [SI = 254, SFT = 44, RD = 192.0.2.3/11] 2396 Now an end-to-end SFP with load balancing choice can be constructed 2397 as follows. The choice made by SFF2 is expressed in terms of 2398 entering one of the three "tail end" SFPs. 2400 SFP29: RD = 198.51.100.1/129, SPI = 43, 2401 [SI = 255, SFT = 41, RD = 192.0.2.1/11], 2402 [SI = 254, SFT = 42, RD = 192.0.2.2/11], 2403 [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0}, 2404 RD = {SPI=41, SI=255, Rsv=0}, 2405 RD = {SPI=42, SI=255, Rsv=0} } ] 2407 Now, despite the load balancing choice being made other than at the 2408 initial Classifier, it is possible for the reverse SFPs to be well- 2409 constructed without any ambiguity. The three reverse paths appear as 2410 follows. 2412 SFP30: RD = 198.51.100.1/130, SPI = 44, 2413 Assoc-Type = 1, Assoc-RD = 198.51.100.1/126, Assoc-SPI = 40, 2414 [SI = 255, SFT = 44, RD = 192.0.2.4/11], 2415 [SI = 254, SFT = 43, RD = 192.0.2.5/11], 2416 [SI = 253, SFT = 42, RD = 192.0.2.2/11], 2417 [SI = 252, SFT = 41, RD = 192.0.2.1/11] 2419 SFP31: RD = 198.51.100.1/131, SPI = 45, 2420 Assoc-Type = 1, Assoc-RD = 198.51.100.1/127, Assoc-SPI = 41, 2421 [SI = 255, SFT = 44, RD = 192.0.2.4/11], 2422 [SI = 254, SFT = 43, RD = 192.0.2.6/11], 2423 [SI = 253, SFT = 42, RD = 192.0.2.2/11], 2424 [SI = 252, SFT = 41, RD = 192.0.2.1/11] 2426 SFP32: RD = 198.51.100.1/132, SPI = 46, 2427 Assoc-Type = 1, Assoc-RD = 198.51.100.1/128, Assoc-SPI = 42, 2428 [SI = 255, SFT = 44, RD = 192.0.2.4/11], 2429 [SI = 254, SFT = 43, RD = 192.0.2.7/11], 2430 [SI = 253, SFT = 42, RD = 192.0.2.2/11], 2431 [SI = 252, SFT = 41, RD = 192.0.2.1/11] 2433 8.10. Examples Using IPv6 Addressing 2435 This section provides several examples using IPv6 addressing. As 2436 will be seen from the examples, there is nothing special or clever 2437 about using IPv6 addressing rather than IPv4 addressing. 2439 The reference network for these IPv6 examples is based on that 2440 described at the top of Section 8 and shown in Figure 11. 2442 Assume we have a service function overlay network with four SFFs 2443 (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the 2444 underlay network as follows: 2446 SFF1 2001:db8::192:0:2:1 2447 SFF2 2001:db8::192:0:2:2 2448 SFF3 2001:db8::192:0:2:3 2449 SFF4 2001:db8::192:0:2:4 2451 Each SFF provides access to some SFIs from the four Service Function 2452 Types SFT=41, SFT=42, SFT=43, and SFT=44 just as before: 2454 SFF1 SFT=41 and SFT=42 2455 SFF2 SFT=41 and SFT=43 2456 SFF3 SFT=42 and SFT=44 2457 SFF4 SFT=43 and SFT=44 2459 The service function network also contains a Controller with address 2460 2001:db8::198:51:100:1. 2462 This example service function overlay network is shown in Figure 15. 2464 ------------------------ 2465 | Controller | 2466 | 2001:db8::198:51:100:1 | 2467 ------------------------ 2468 ------ ------ ------ ------ 2469 | SFI | | SFI | | SFI | | SFI | 2470 |SFT=41| |SFT=42| |SFT=41| |SFT=43| 2471 ------ ------ ------ ------ 2472 \ / \ / 2473 ------------------- ------------------- 2474 | SFF1 | | SFF2 | 2475 |2001:db8::192:0:2:1| |2001:db8::192:0:2:2| 2476 ------------------- ------------------- 2477 ---------- 2478 Packet --> | | --> 2479 Flows --> |Classifier| -->Dest 2480 | | --> 2481 ---------- 2482 ------------------- ------------------- 2483 | SFF3 | | SFF4 | 2484 |2001:db8::192:0:2:3| |2001:db8::192:0:2:4| 2485 ------------------- ------------------- 2486 / \ / \ 2487 ------ ------ ------ ------ 2488 | SFI | | SFI | | SFI | | SFI | 2489 |SFT=42| |SFT=44| |SFT=43| |SFT=44| 2490 ------ ------ ------ ------ 2492 Figure 15: Example Service Function Overlay Network 2494 The SFFs advertise routes to the SFIs they support. These 2495 advertisements contain Route Distinguishers that are set according to 2496 the network operator's configuration model. Note that in an IPv6 2497 network, the RD is not large enough to contain the full IPv6 address 2498 as only six octets are available so, in all of these IPv6 examples, 2499 we use RDs of type 1 such that the available six octets are 2500 partitioned as four octets for an IPv4 address of the advertising 2501 SFF, and two octets that are a local index of the SFI. Furthermore, 2502 we have chosen an IPv6 addressing scheme so that the low order four 2503 octets of the IPv6 address match an IPv4 address of the advertising 2504 node. This scheme is chosen purely for convenience of documentation, 2505 and an operator is totally free to use any other scheme so long as it 2506 conforms to the definitions of SFIR and SFPR in Section 3.1 and 2507 Section 3.2. 2509 Observant readers will notice that this makes the BGP advertisements 2510 shown in these examples exactly the same as in the previous examples. 2511 All that is different is that the advertising SFFs and Controller 2512 have IPv6 addresses. 2514 Thus we see the following SFIRs advertised: 2516 The SFFs advertise routes to the SFIs they support. So we see the 2517 following SFIRs: 2519 RD = 192.0.2.1/1, SFT = 41 2520 RD = 192.0.2.1/2, SFT = 42 2521 RD = 192.0.2.2/1, SFT = 41 2522 RD = 192.0.2.2/2, SFT = 43 2523 RD = 192.0.2.3/7, SFT = 42 2524 RD = 192.0.2.3/8, SFT = 44 2525 RD = 192.0.2.4/5, SFT = 43 2526 RD = 192.0.2.4/6, SFT = 44 2528 Note that the addressing used for communicating between SFFs is taken 2529 from the Tunnel Encapsulation attribute of the SFIR and not from the 2530 SFIR-RD. 2532 8.10.1. Example Explicit SFP With No Choices 2534 Consider the following SFPR similar to that in Section 8.1. 2536 SFP1: RD = 198.51.100.1/101, SPI = 15, 2537 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 2538 [SI = 250, SFT = 43, RD = 192.0.2.2/2] 2540 The Service Function Path consists of an SF of type 41 located at 2541 SFF1 followed by an SF of type 43 located at SFF2. This path is 2542 fully explicit and each SFF is offered no choice in forwarding packet 2543 along the path. 2545 SFF1 will receive packets on the path from the Classifier and will 2546 identify the path from the SPI (15). The initial SI will be 255 and 2547 so SFF1 will deliver the packets to the SFI for SFT 41. 2549 When the packets are returned to SFF1 by the SFI the SI will be 2550 decreased to 250 for the next hop. SFF1 has no flexibility in the 2551 choice of SFF to support the next hop SFI and will forward the packet 2552 to SFF2 which will send the packets to the SFI that supports SFT 43 2553 before forwarding the packets to their destinations. 2555 8.10.2. Example SFP With Choice of SFIs 2557 SFP2: RD = 198.51.100.1/102, SPI = 16, 2558 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 2559 [SI = 250, SFT = 43, {RD = 192.0.2.2/2, 2560 RD = 192.0.2.4/5 } ] 2562 In this example, like that in Section 8.2, the path also consists of 2563 an SF of type 41 located at SFF1 and this is followed by an SF of 2564 type 43, but in this case the SI = 250 contains a choice between the 2565 SFI located at SFF2 and the SFI located at SFF4. 2567 SFF1 will receive packets on the path from the Classifier and will 2568 identify the path from the SPI (16). The initial SI will be 255 and 2569 so SFF1 will deliver the packets to the SFI for SFT 41. 2571 When the packets are returned to SFF1 by the SFI the SI will be 2572 decreased to 250 for the next hop. SFF1 now has a choice of next hop 2573 SFF to execute the next hop in the path. It can either forward 2574 packets to SFF2 or SFF4 to execute a function of type 43. It uses 2575 its local load balancing algorithm to make this choice. The chosen 2576 SFF will send the packets to the SFI that supports SFT 43 before 2577 forwarding the packets to their destinations. 2579 8.10.3. Example SFP With Open Choice of SFIs 2581 SFP3: RD = 198.51.100.1/103, SPI = 17, 2582 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 2583 [SI = 250, SFT = 44, RD = 0] 2585 In this example, like that in Section 8.3 the path also consists of 2586 an SF of type 41 located at SFF1 and this is followed by an SI with 2587 an RD of zero and SF of type 44. This means that a choice can be 2588 made between any SFF that supports an SFI of type 44. 2590 SFF1 will receive packets on the path from the Classifier and will 2591 identify the path from the SPI (17). The initial SI will be 255 and 2592 so SFF1 will deliver the packets to the SFI for SFT 41. 2594 When the packets are returned to SFF1 by the SFI the SI will be 2595 decreased to 250 for the next hop. SFF1 now has a free choice of 2596 next hop SFF to execute the next hop in the path selecting between 2597 all SFFs that support SFs of type 44. Looking at the SFIRs it has 2598 received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. 2599 SFF1 uses its local load balancing algorithm to make this choice. 2600 The chosen SFF will send the packets to the SFI that supports SFT 44 2601 before forwarding the packets to their destinations. 2603 8.10.4. Example SFP With Choice of SFTs 2605 SFP4: RD = 198.51.100.1/104, SPI = 18, 2606 [SI = 255, SFT = 41, RD = 192.0.2.1/1], 2607 [SI = 250, {SFT = 43, RD = 192.0.2.2/2, 2608 SFT = 44, RD = 192.0.2.3/8 } ] 2610 This example, similar to that in Section 8.4 provides a choice of SF 2611 type in the second hop in the path. The SI of 250 indicates a choice 2612 between SF type 43 located through SF2 and SF type 44 located at SF3. 2614 SFF1 will receive packets on the path from the Classifier and will 2615 identify the path from the SPI (18). The initial SI will be 255 and 2616 so SFF1 will deliver the packets to the SFI for SFT 41. 2618 When the packets are returned to SFF1 by the SFI the SI will be 2619 decreased to 250 for the next hop. SFF1 now has a free choice of 2620 next hop SFF to execute the next hop in the path selecting between 2621 all SFFs that support an SF of type 43 and SFF3 that supports an SF 2622 of type 44. These may be completely different functions that are to 2623 be executed dependent on specific conditions, or may be similar 2624 functions identified with different type identifiers (such as 2625 firewalls from different vendors). SFF1 uses its local policy and 2626 load balancing algorithm to make this choice, and may use additional 2627 information passed back from the local SFI to help inform its 2628 selection. The chosen SFF will send the packets to the SFI that 2629 supports the chose SFT before forwarding the packets to their 2630 destinations. 2632 9. Security Considerations 2634 The mechanisms in this document use BGP for the control plane. 2635 Hence, techniques such as those discussed in [RFC5925]] can be used 2636 to help authenticate BGP sessions and thus the messages between BGP 2637 peers, making it harder to spoof updates (which could be used to 2638 install bogus SFPs or to advertise false SIs) or withdrawals. 2640 Further discussion of security considerations for BGP may be found in 2641 the BGP specification itself [RFC4271] and in the security analysis 2642 for BGP [RFC4272]. The original discussion of the use of the TCP MD5 2643 signature option to protect BGP sessions is found in [RFC5925], while 2644 [RFC6952] includes an analysis of BGP keying and authentication 2645 issues. 2647 Additionally, this document depends on other documents that specify 2648 BGP Multiprotocol Extensions and the documents that define the 2649 attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. 2650 [RFC4760] observes that the use of AFI/SAFI does not change the 2651 underlying security issues inherent in the existing BGP. Relevant 2652 additional security measures are considered in 2653 [I-D.ietf-idr-tunnel-encaps]. 2655 This document does not fundamentally change the security behavior of 2656 BGP deployments, which depend considerably on the network operator's 2657 perception of risk in their network. It may be observed that the 2658 application of the mechanisms described in this document are scoped 2659 to a single domain as implied by [RFC8300] noted in Section 2.1 of 2660 this document. Applicability of BGP within a single domain may 2661 enable a network operator to make easier and more consistent 2662 decisions about what security measures to apply, and the domain 2663 boundary, which BGP enforces by definition, provides a safeguard that 2664 prevents leakage of SFC programming in either direction at the 2665 boundary. 2667 Service Function Chaining provides a significant attack opportunity: 2668 packets can be diverted from their normal paths through the network, 2669 packets can be made to execute unexpected functions, and the 2670 functions that are instantiated in software can be subverted. 2671 However, this specification does not change the existence of Service 2672 Function Chaining and security issues specific to Service Function 2673 Chaining are covered in [RFC7665] and [RFC8300]. 2675 This document defines a control plane for Service Function Chaining. 2676 Clearly, this provides an attack vector for a Service Function 2677 Chaining system as an attack on this control plane could be used to 2678 make the system misbehave. Thus, the security of the BGP system is 2679 critically important to the security of the whole Service Function 2680 Chaining system. The control plane mechanisms are very similar to 2681 those used for BGP/MPLS IP VPNs as described in [RFC4364], and so the 2682 security considerations in that document (Section 13) provide good 2683 guidance for securing SFC systems reliant on this specification. Of 2684 particular relevance is the need to securely distinguish between 2685 messages intended for the control of different SFC overlays which is 2686 similar to the need to distinguish between different VPNs. 2687 Section 19 of [RFC7432] also provides useful guidance on the use of 2688 BGP in a similar environment. 2690 Note that a component of an SFC system that uses the procedures 2691 described in this document also requires communications between a 2692 Controller and the SFC network elements (specifically the SFFs and 2693 Classifiers). This communication covers instructing the Classifiers 2694 using BGP mechanisms (see Section 7.4), thus the use of BGP security 2695 is strongly recommended. But it also covers other mechanisms for 2696 programming the Classifier and instructing the SFFs and SFs (for 2697 example, to bind SFs to an SFF, and to cause the establishment of 2698 tunnels between SFFs). This document does not cover these latter 2699 mechanisms and so their security is out of scope, but it should be 2700 noted that these communications provide an attack vector on the SFC 2701 system and so attention must be paid to ensuring that they are 2702 secure. 2704 There is an intrinsic assumption in SFC systems that nodes that 2705 announce support for specific SFs actually offer those functions, and 2706 that SFs are not, themselves, attacked or subverted. This is 2707 particularly important when the SFs are implemented as software that 2708 can be updated. Protection against this sort of concern forms part 2709 of the security of any SFC system and so is outside the scope of the 2710 control plane mechanisms described in this document. 2712 Similarly, there is a vulnerability if a rogue or subverted 2713 Controller announces SFPs especially if that controller "takes over" 2714 an existing SFP and changes its contents. This is corresponds to a 2715 rogue BGP speaker entering a routing system, or even to a Route 2716 Reflector becoming subverted. Protection mechanisms, as above, 2717 include securing BGP sessions and protecting software loads on the 2718 controllers. 2720 In an environment where there is concern that rogue Controllers might 2721 be introduced to the network and inject false SFPRs or take over and 2722 change existing SFPRs, it is RECOMMENDED that each SFF and Classifier 2723 be configured with the identities of authorized Controllers. Thus, 2724 the announcement of an SFPR by any other BGP peer would be rejected. 2726 Lastly, note that Section 3.2.2 makes two operational suggestions 2727 that have implications for the stability and security of the 2728 mechanisms described in this document: 2730 o That modifications to active SFPs not be made. 2732 o That SPIs not be immediately re-used. 2734 10. IANA Considerations 2736 10.1. New BGP AF/SAFI 2738 IANA maintains a registry of "Address Family Numbers". IANA is 2739 requested to assign a new Address Family Number from the "Standards 2740 Action" range called "BGP SFC" (TBD1 in this document) with this 2741 document as a reference. 2743 IANA maintains a registry of "Subsequent Address Family Identifiers 2744 (SAFI) Parameters". IANA is requested to assign a new SAFI value 2745 from the "Standards Action" range called "BGP SFC" (TBD2 in this 2746 document) with this document as a reference. 2748 10.2. New BGP Path Attribute 2750 IANA maintains a registry of "Border Gateway Protocol (BGP) 2751 Parameters" with a subregistry of "BGP Path Attributes". IANA is 2752 requested to assign a new Path attribute called "SFP attribute" (TBD3 2753 in this document) with this document as a reference. 2755 10.3. New SFP Attribute TLVs Type Registry 2757 IANA maintains a registry of "Border Gateway Protocol (BGP) 2758 Parameters". IANA is request to create a new subregistry called the 2759 "SFP Attribute TLVs" registry. 2761 Valid values are in the range 0 to 65535. 2763 o Values 0 and 65535 are to be marked "Reserved, not to be 2764 allocated". 2766 o Values 1 through 65534 are to be assigned according to the "First 2767 Come First Served" policy [RFC8126]. 2769 This document should be given as a reference for this registry. 2771 The new registry should track: 2773 o Type 2774 o Name 2776 o Reference Document or Contact 2778 o Registration Date 2780 The registry should initially be populated as follows: 2782 Type | Name | Reference | Date 2783 ------+-------------------------+---------------+--------------- 2784 1 | Association TLV | [This.I-D] | Date-to-be-set 2785 2 | Hop TLV | [This.I-D] | Date-to-be-set 2786 3 | SFT TLV | [This.I-D] | Date-to-be-set 2787 4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set 2788 5 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set 2790 10.4. New SFP Association Type Registry 2792 IANA maintains a registry of "Border Gateway Protocol (BGP) 2793 Parameters". IANA is request to create a new subregistry called the 2794 "SFP Association Type" registry. 2796 Valid values are in the range 0 to 65535. 2798 o Values 0 and 65535 are to be marked "Reserved, not to be 2799 allocated". 2801 o Values 1 through 65534 are to be assigned according to the "First 2802 Come First Served" policy [RFC8126]. 2804 This document should be given as a reference for this registry. 2806 The new registry should track: 2808 o Association Type 2810 o Name 2812 o Reference Document or Contact 2814 o Registration Date 2816 The registry should initially be populated as follows: 2818 Association Type | Name | Reference | Date 2819 -----------------+--------------------+------------+--------------- 2820 1 | Bidirectional SFP | [This.I-D] | Date-to-be-set 2822 10.5. New Service Function Type Registry 2824 IANA is request to create a new top-level registry called "Service 2825 Function Chaining Service Function Types". 2827 Valid values are in the range 0 to 65535. 2829 o Values 0 and 65535 are to be marked "Reserved, not to be 2830 allocated". 2832 o Values 1 through 31 are to be assigned by "Standards Action" 2833 [RFC8126] and are referred to as the Special Purpose SFT values. 2835 o Values 32 through 64495 are to be assigned according to the "First 2836 Come First Served" policy [RFC8126]. 2838 o Values 64496 through 65534 are for Private Use and are not to be 2839 recorded by IANA. 2841 This document should be given as a reference for this registry. 2843 The new registry should track: 2845 o Value 2847 o Name 2849 o Reference Document or Contact 2851 o Registration Date 2853 The registry should initially be populated as follows where 2854 [I-D.darwa] should be expanded to 2855 [I-D.dawra-idr-bgp-ls-sr-service-segments]. 2857 Value | Name | Reference | Date 2858 ------+-------------------------+------------+--------------- 2859 0 | Reserved, not to be | [This.I-D] | Date-to-be-set 2860 | allocated | | 2861 1 | Change Sequence | [This.I-D] | Date-to-be-set 2862 2-31 | Unassigned | | 2863 32 | Classifier | [This.I-D] | Date-to-be-set 2864 | | [I-D.dawra]| 2865 33 | Firewall | [This.I-D] | Date-to-be-set 2866 | | [I-D.dawra]| 2867 34 | Load balancer | [This.I-D] | Date-to-be-set 2868 | | [I-D.dawra]| 2869 35 | Deep packet inspection | [This.I-D] | Date-to-be-set 2870 | engine | [I-D.dawra]| 2871 36 | Penalty box | [This.I-D] | Date-to-be-set 2872 | | [RFC8300] | 2873 37 | WAN accelerator | [This.I-D] | Date-to-be-set 2874 | | [RFC7665] | 2875 | | [RFC8300] | 2876 38 | Application accelerator | [This.I-D] | Date-to-be-set 2877 | | [RFC7665] | 2878 39 | TCP optimizer | [This.I-D] | Date-to-be-set 2879 | | [RFC7665] | 2880 40 | Network Address | [This.I-D] | Date-to-be-set 2881 | Translator | [RFC7665] | 2882 41 | NAT44 | [This.I-D] | Date-to-be-set 2883 | | [RFC7665] | 2884 | | [RFC3022] | 2885 42 | NAT64 | [This.I-D] | Date-to-be-set 2886 | | [RFC7665] | 2887 | | [RFC6146] | 2888 43 | NPTv6 | [This.I-D] | Date-to-be-set 2889 | | [RFC7665] | 2890 | | [RFC6296] | 2891 44 | Lawful intercept | [This.I-D] | Date-to-be-set 2892 | | [RFC7665] | 2893 45 | HOST_ID injection | [This.I-D] | Date-to-be-set 2894 | | [RFC7665] | 2895 46 | HTTP header enrichment | [This.I-D] | Date-to-be-set 2896 | | [RFC7665] | 2897 47 | Caching engine | [This.I-D] | Date-to-be-set 2898 | | [RFC7665] | 2899 48- | | | 2900 -65534|Unassigned | | 2901 65535 | Reserved, not to be | | 2902 | allocated | [This.I-D] | Date-to-be-set 2904 10.6. New Generic Transitive Experimental Use Extended Community Sub- 2905 Types 2907 IANA maintains a registry of "Border Gateway Protocol (BGP) 2908 Parameters" with a subregistry of "Generic Transitive Experimental 2909 Use Extended Community Sub-Type". IANA is requested to assign a new 2910 sub-type as follows: 2912 "Flow Specification for SFC Classifiers" (TBD4 in this document) 2913 with this document as the reference. 2915 10.7. New BGP Transitive Extended Community Type 2917 IANA maintains a registry of "Border Gateway Protocol (BGP) 2918 Parameters" with a subregistry of "BGP Transitive Extended Community 2919 Types". IANA is requested to assign a new type as follows: 2921 o SFC (Sub-Types are defined in the "SFC Extended Community Sub- 2922 Types" registry) (TBD6 in this document) with this document as the 2923 reference. 2925 10.8. New SFC Extended Community Sub-Types Registry 2927 IANA maintains a registry of "Border Gateway Protocol (BGP) 2928 Parameters". IANA is requested to create a new sub-registry called 2929 the "SFC Extended Community Sub-Types Registry". 2931 IANA should include the following note replacing the string "TBD6" 2932 with the value assigned for Section 10.7: 2934 This registry contains values of the second octet (the "Sub-Type" 2935 field) of an extended community when the value of the first octet 2936 (the "Type" field) is set to TBD6. 2938 The allocation policy for this registry should be First Come First 2939 Served. 2941 Valid values are 0 to 255. The value 0 is reserved and should not be 2942 allocated. 2944 IANA is requested to populate this registry with the following 2945 entries: 2947 Sub-Type | | | 2948 Value | Name | Reference | Date 2949 ---------+----------------------+-------------+--------------- 2950 0 | Reserved, not to be | | 2951 | allocated | | 2952 1 | SFIR Pool Identifier | [This.I-D] | Date-to-be-set 2953 2 | MPLS Label Stack | [This.I-D] | Date-to-be-set 2954 | Mixed Swapping/ | | 2955 | Stacking Labels | | 2956 3-255 | Unassigned | | 2958 All other values should be marked "Unassigned". 2960 10.9. SPI/SI Representation 2962 IANA is requested to assign a codepoint from the "BGP Tunnel 2963 Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI 2964 Representation Sub-TLV" (TBD5 in this document) with this document 2965 being the reference. 2967 10.10. SFC SPI/SI Representation Flags Registry 2969 IANA maintains the "BGP Tunnel Encapsulation Attribute Sub-TLVs" 2970 registry and is requested to create an associated registry called the 2971 "SFC SPI/SI Representation Flags" registry. 2973 Bits are to be assigned by Standards Action. The field is 16 bits 2974 long, and bits are counted from the the most significant bit as bit 2975 zero. 2977 IANA is requested to populate the registry as follows: 2979 Bit number | Name | Reference 2980 -----------+----------------------+----------- 2981 TBD9 | NSH data plane | [This.I-D] 2982 TBD10 | MPLS data plane | [This.I-D] 2984 11. Contributors 2985 Stuart Mackie 2986 Juniper Networks 2988 Email: wsmackie@juinper.net 2990 Keyur Patel 2991 Arrcus, Inc. 2993 Email: keyur@arrcus.com 2995 Avinash Lingala 2996 AT&T 2998 Email: ar977m@att.com 3000 12. Acknowledgements 3002 Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful 3003 comments, and to Joel Halpern for discussions that improved this 3004 document. Yuanlong Jiang provided a useful review and caught some 3005 important issues. Stephane Litkowski did an exceptionally good and 3006 detailed document shepherd review. 3008 Andy Malis contributed text that formed the basis of Section 7.7. 3010 Brian Carpenter and Martin Vigoureux provided useful reviews during 3011 IETF last call. Thanks also to Sheng Jiang, Med Boucadair, Ravi 3012 Singh, Benjamin Kaduk, Roman Danyliw, Adam Roach, Alvaro Retana, 3013 Barry Leiba, and Murray Kucherawy for review comments. Ketan 3014 Talaulikar provided helpful discussion of the SFT code point 3015 registry. Ron Bonica kept us honest on the difference between an RD 3016 and RT; Benjamin Kaduk kept us on message about the differnce between 3017 an RD and an extended community. 3019 13. References 3021 13.1. Normative References 3023 [I-D.ietf-idr-rfc5575bis] 3024 Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 3025 Bacher, "Dissemination of Flow Specification Rules", 3026 draft-ietf-idr-rfc5575bis-26 (work in progress), August 3027 2020. 3029 [I-D.ietf-idr-tunnel-encaps] 3030 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 3031 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 3032 encaps-17 (work in progress), July 2020. 3034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3035 Requirement Levels", BCP 14, RFC 2119, 3036 DOI 10.17487/RFC2119, March 1997, 3037 . 3039 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 3040 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 3041 DOI 10.17487/RFC4271, January 2006, 3042 . 3044 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 3045 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 3046 February 2006, . 3048 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 3049 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 3050 2006, . 3052 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 3053 "Multiprotocol Extensions for BGP-4", RFC 4760, 3054 DOI 10.17487/RFC4760, January 2007, 3055 . 3057 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 3058 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 3059 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 3060 2015, . 3062 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 3063 Patel, "Revised Error Handling for BGP UPDATE Messages", 3064 RFC 7606, DOI 10.17487/RFC7606, August 2015, 3065 . 3067 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 3068 Chaining (SFC) Architecture", RFC 7665, 3069 DOI 10.17487/RFC7665, October 2015, 3070 . 3072 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3073 Writing an IANA Considerations Section in RFCs", BCP 26, 3074 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3075 . 3077 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3078 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3079 May 2017, . 3081 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 3082 "Network Service Header (NSH)", RFC 8300, 3083 DOI 10.17487/RFC8300, January 2018, 3084 . 3086 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 3087 Forwarding Plane for Service Function Chaining", RFC 8595, 3088 DOI 10.17487/RFC8595, June 2019, 3089 . 3091 [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, 3092 "MPLS Transport Encapsulation for the Service Function 3093 Chaining (SFC) Network Service Header (NSH)", RFC 8596, 3094 DOI 10.17487/RFC8596, June 2019, 3095 . 3097 13.2. Informative References 3099 [I-D.dawra-idr-bgp-ls-sr-service-segments] 3100 Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., 3101 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., 3102 Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS 3103 Advertisement of Segment Routing Service Segments", draft- 3104 dawra-idr-bgp-ls-sr-service-segments-04 (work in 3105 progress), August 2020. 3107 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 3108 Address Translator (Traditional NAT)", RFC 3022, 3109 DOI 10.17487/RFC3022, January 2001, 3110 . 3112 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 3113 RFC 4272, DOI 10.17487/RFC4272, January 2006, 3114 . 3116 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 3117 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 3118 June 2010, . 3120 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 3121 NAT64: Network Address and Protocol Translation from IPv6 3122 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 3123 April 2011, . 3125 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 3126 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 3127 . 3129 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 3130 BGP, LDP, PCEP, and MSDP Issues According to the Keying 3131 and Authentication for Routing Protocols (KARP) Design 3132 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 3133 . 3135 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 3136 Service Function Chaining", RFC 7498, 3137 DOI 10.17487/RFC7498, April 2015, 3138 . 3140 Authors' Addresses 3142 Adrian Farrel 3143 Old Dog Consulting 3145 Email: adrian@olddog.co.uk 3147 John Drake 3148 Juniper Networks 3150 Email: jdrake@juniper.net 3152 Eric Rosen 3153 Juniper Networks 3155 Email: erosen52@gmail.com 3157 Jim Uttaro 3158 AT&T 3160 Email: ju1738@att.com 3162 Luay Jalil 3163 Verizon 3165 Email: luay.jalil@verizon.com