--- 1/draft-ietf-bess-nsh-bgp-control-plane-07.txt 2019-03-01 12:13:09.369553586 -0800 +++ 2/draft-ietf-bess-nsh-bgp-control-plane-08.txt 2019-03-01 12:13:09.477556242 -0800 @@ -1,57 +1,58 @@ BESS Working Group A. Farrel Internet-Draft Old Dog Consulting Intended status: Standards Track J. Drake -Expires: August 30, 2019 E. Rosen +Expires: September 2, 2019 E. Rosen Juniper Networks J. Uttaro AT&T L. Jalil Verizon - February 26, 2019 + March 1, 2019 BGP Control Plane for NSH SFC - draft-ietf-bess-nsh-bgp-control-plane-07 + draft-ietf-bess-nsh-bgp-control-plane-08 Abstract This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC AFI/SAFI with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be - used in conjunction with the Network Service Header. + used in conjunction with the Network Service Header defined in RFC + 8300. This document adopts the SFC architecture described in RFC 7665. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 30, 2019. + This Internet-Draft will expire on September 2, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,103 +60,104 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1. Overview of Service Function Chaining . . . . . . . . . . 6 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7 - 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10 - 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11 - 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12 + 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 11 + 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 12 + 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 13 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13 - 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13 - 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 18 - 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 19 - 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 19 - 4.2. Service Function Instance Routes . . . . . . . . . . . . 19 - 4.3. Service Function Path Routes . . . . . . . . . . . . . . 20 - 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 22 - 4.5. Service Function Forwarder Operation . . . . . . . . . . 22 - 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 23 - 5. Selection in Service Function Paths . . . . . . . . . . . . . 24 - 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 26 - 6.1. Protocol Control of Looping, Jumping, and Branching . . . 26 - 6.2. Implications for Forwarding State . . . . . . . . . . . . 27 - 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 28 - 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 28 - 7.2. Correlating Service Function Path Instances . . . . . . . 28 - 7.3. Considerations for Stateful Service Functions . . . . . . 29 - 7.4. VPN Considerations and Private Service Functions . . . . 30 - 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30 - 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32 - 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33 - 7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33 - 7.8. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 33 - 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35 - 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 36 - 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 37 - 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 37 - 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 38 - 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38 - 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 39 - 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 40 - 8.9. Examples of SFPs with Stateful Service Functions . . . . 40 - 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 41 - 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 42 - 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 43 - 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 45 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 48 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 - 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 49 - 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 49 - 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 49 - 10.4. New SFP Association Type Registry . . . . . . . . . . . 50 - 10.5. New Service Function Type Registry . . . . . . . . . . . 50 + 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 14 + 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 19 + 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 20 + 4.2. Service Function Instance Routes . . . . . . . . . . . . 20 + 4.3. Service Function Path Routes . . . . . . . . . . . . . . 21 + 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 23 + 4.5. Service Function Forwarder Operation . . . . . . . . . . 23 + 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 24 + 5. Selection in Service Function Paths . . . . . . . . . . . . . 25 + 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 27 + 6.1. Protocol Control of Looping, Jumping, and Branching . . . 27 + 6.2. Implications for Forwarding State . . . . . . . . . . . . 28 + 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 29 + 7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 29 + 7.2. Correlating Service Function Path Instances . . . . . . . 29 + 7.3. Considerations for Stateful Service Functions . . . . . . 30 + 7.4. VPN Considerations and Private Service Functions . . . . 31 + 7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 31 + 7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 33 + 7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 34 + 7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 34 + 7.8. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 34 + 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 36 + 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 37 + 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 38 + 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 38 + 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 39 + 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 39 + 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 40 + 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 41 + 8.9. Examples of SFPs with Stateful Service Functions . . . . 41 + 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 42 + 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 43 + 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 44 + 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 46 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 + 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 50 + 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 50 + 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 50 + 10.4. New SFP Association Type Registry . . . . . . . . . . . 51 + 10.5. New Service Function Type Registry . . . . . . . . . . . 51 10.6. New Generic Transitive Experimental Use Extended - Community Sub-Types . . . . . . . . . . . . . . . . . . 51 - 10.7. New BGP Transitive Extended Community Types . . . . . . 51 - 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 52 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 52 - 13.2. Informative References . . . . . . . . . . . . . . . . . 53 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 + Community Sub-Types . . . . . . . . . . . . . . . . . . 52 + 10.7. New BGP Transitive Extended Community Types . . . . . . 52 + 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 53 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 53 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 54 + 13.2. Informative References . . . . . . . . . . . . . . . . . 55 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 1. Introduction As described in [RFC7498], the delivery of end-to-end services can require a packet to pass through a series of Service Functions (SFs) - (e.g., classifiers, firewalls, TCP accelerators, and server load - balancers) in a specified order: this is termed "Service Function - Chaining" (SFC). There are a number of issues associated with - deploying and maintaining service function chaining in production - networks, which are described below. + (e.g., WAN and application accelerators, Deep Packet Inspection (DPI) + engines, firewalls, TCP optimizers, and server load balancers) in a + specified order: this is termed "Service Function Chaining" (SFC). + There are a number of issues associated with deploying and + maintaining service function chaining in production networks, which + are described below. - Conventionally, if a packet needs to travel through a particular + Historically, if a packet needed to travel through a particular service chain, the nodes hosting the service functions of that chain - are placed in the network topology in such a way that the packet - cannot reach its ultimate destination without first passing through - all the service functions in the proper order. This need to place - the service functions at particular topological locations limits the - ability to adapt a service function chain to changes in network - topology (e.g., link or node failures), network utilization, or - offered service load. These topological restrictions on where the - service functions can be placed raise the following issues: + were placed in the network topology in such a way that the packet + could not reach its ultimate destination without first passing + through all the service functions in the proper order. This need to + place the service functions at particular topological locations + limited the ability to adapt a service function chain to changes in + network topology (e.g., link or node failures), network utilization, + or offered service load. These topological restrictions on where the + service functions can be placed raised the following issues: 1. The process of configuring or modifying a service function chain is operationally complex and may require changes to the network topology. 2. Alternate or redundant service functions may need to be co- located with the primary service functions. 3. When there is more than one path between source and destination, forwarding may be asymmetric and it may be difficult to support @@ -173,21 +175,21 @@ This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC AFI/SAFI with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be - used in conjunction with the Network Service Header. + used in conjunction with the Network Service Header [RFC8300]. This document adopts the SFC architecture described in [RFC7665]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. @@ -215,49 +217,56 @@ Additionally, this document uses the following terms from [RFC8300]: o Network Service Header (NSH) o Service Index (SI) o Service Path Identifier (SPI) This document introduces the following terms: - o Service Function Instance Route (SFIR) + o Service Function Instance Route (SFIR). A new BGP Route Type + advertised by the node that hosts an SFI to describe the SFI and + to announce the way to forward a packet to the node through the + underlay network. - o Service Function Overlay Network + o Service Function Overlay Network. The logical network comprised + of Classifiers, SFFs, and SFIs that are connected by paths or + tunnels through underlay transport networks. - o Service Function Path Route (SFPR) + o Service Function Path Route (SFPR). A new BGP Route Type + originated by Controllers to advertise the details of each SFP. - o Service Function Type (SFT) + o Service Function Type (SFT). An indication of the function and + features of an SFI. 2. Overview -2.1. Functional Overview +2.1. Overview of Service Function Chaining In [RFC8300] a Service Function Chain (SFC) is an ordered list of Service Functions (SFs). A Service Function Path (SFP) is an indication of which instances of SFs are acceptable to be traversed in an instantiation of an SFC in a service function overlay network. The Service Path Identifier (SPI) is a 24-bit number that identifies a specific SFP, and a Service Index (SI) is an 8-bit number that identifies a specific point in that path. In the context of a particular SFP (identified by an SPI), an SI represents a particular Service Function, and indicates the order of that SF in the SFP. In fact, each SI is mapped to one or more SFs that are implemented by one or more Service Function Instances (SFIs) that support those specified SFs. Thus an SI may represent a choice of SFIs of one or more Service Function Types. By deploying multiple SFIs for a single SF, one can provide load balancing and redundancy. - A special Service Function, called a Classifier, is located at each + A special functional element, called a Classifier, is located at each ingress point to a service function overlay network. It assigns the packets of a given packet flow to a specific Service Function Path. This may be done by comparing specific fields in a packet's header with local policy, which may be customer/network/service specific. The classifier picks an SFP and sets the SPI accordingly, it then sets the SI to the value of the SI for the first hop in the SFP, and then prepends a Network Services Header (NSH) [RFC8300] containing the assigned SPI/SI to that packet. Note that the Classifier and the node that hosts the first Service Function in a Service Function Path need not be located at the same point in the service function overlay @@ -270,21 +279,21 @@ Section 7.1, that the node prepending the NSH also provide some form of entropy indicator that can be used in the underlay network. The Service Function Forwarder (SFF) receives a packet from the previous node in a Service Function Path, removes the packet's link layer or tunnel encapsulation and hands the packet and the NSH to the Service Function Instance for processing. The SFI has no knowledge of the SFP. When the SFF receives the packet and the NSH back from the SFI it - must select the next SFI along the path using the SPI and SI in the + MUST select the next SFI along the path using the SPI and SI in the NSH and potentially choosing between multiple SFIs (possibly of different Service Function Types) as described in Section 5. In the normal case the SPI remains unchanged and the SI will have been decremented to indicate the next SF along the path. But other possibilities exist if the SF makes other changes to the NSH through a process of re-classification: o The SI in the NSH may indicate: * A previous SF in the path: known as "looping" (see Section 6). @@ -293,52 +302,59 @@ Section 6). o The SPI and the SI may point to an SF on a different SFP: known as "branching" (see also Section 6). Such modifications are limited to within the same service function overlay network. That is, an SPI is known within the scope of service function overlay network. Furthermore, the new SI value is interpreted in the context of the SFP identified by the SPI. - An unknown or invalid SPI SHALL be treated as an error and the SFF - MUST drop the packet. Such errors SHOULD be logged, and such logs - MUST be subject to rate limits. + As described in [RFC8300], an unknown or invalid SPI is treated as an + error and the SFF drops the packet. Such errors should be logged, + and such logs are subject to rate limits. - An SFF receiving an SI that is unknown in the context of the SPI MAY + An SFF receiving an SI that is unknown in the context of the SPI can reduce the value to the next meaningful SI value in the SFP indicated by the SPI. If no such value exists or if the SFF does not support - this function it MUST drop the packet and SHOULD log the event: such - logs MUST be subject to rate limits. + this function, the SFF drops the packet and should log the event: + such logs are also subject to rate limits. The SFF then selects an SFI that provides the SF denoted by the SPI/ SI, and forwards the packet to the SFF that supports that SFI. 2.2. Control Plane Overview To accomplish the function described in Section 2.1, this document - introduces a new BGP AFI/SAFI (values to be assigned by IANA) for - "SFC Routes". Two SFC Route Types are defined by this document: the - Service Function Instance Route (SFIR), and the Service Function Path - Route (SFPR). As detailed in Section 3, the route type is indicated - by a sub-field in the NLRI. + introduces the Service Function Type (SFT) that is the category of SF + that is supported by an SFF (such as "firewall"). An IANA registry + of Service Function Types is introduced in Section 10. An SFF may + support SFs of multiple different SFTs, and may support multiple SFIs + of each SF. + + This document also introduces a new BGP AFI/SAFI (values to be + assigned by IANA) for "SFC Routes". Two SFC Route Types are defined + by this document: the Service Function Instance Route (SFIR), and the + Service Function Path Route (SFPR). As detailed in Section 3, the + route type is indicated by a sub-field in the NLRI. o The SFIR is advertised by the node hosting the service function instance. The SFIR describes a particular instance of a - particular Service Function and the way to forward a packet to it - through the underlay network, i.e., IP address and encapsulation - information. + particular Service Function (i.e., an SFI) and the way to forward + a packet to it through the underlay network, i.e., IP address and + encapsulation information. o The SFPRs are originated by Controllers. One SFPR is originated for each Service Function Path. The SFPR specifies: A. the SPI of the path + B. the sequence of SFTs and/or SFIs of which the path consists C. for each such SFT or SFI, the SI that represents it in the identified path. This approach assumes that there is an underlay network that provides connectivity between SFFs and Controllers, and that the SFFs are grouped to form one or more service function overlay networks through which SFPs are built. We assume BGP connectivity between the Controllers and all SFFs within each service function overlay @@ -337,73 +353,97 @@ C. for each such SFT or SFI, the SI that represents it in the identified path. This approach assumes that there is an underlay network that provides connectivity between SFFs and Controllers, and that the SFFs are grouped to form one or more service function overlay networks through which SFPs are built. We assume BGP connectivity between the Controllers and all SFFs within each service function overlay network. - In addition, we also introduce the Service Function Type (SFT) that - is the category of SF that is supported by an SFF (such as - "firewall"). An IANA registry of Service Function Types is - introduced in Section 10. An SFF may support SFs of multiple - different SFTs, and may support multiple SFIs of each SF. - When choosing the next SFI in a path, the SFF uses the SPI and SI as well as the SFT to choose among the SFIs, applying, for example, a load balancing algorithm or direct knowledge of the underlay network topology as described in Section 4. The SFF then encapsulates the packet using the encapsulation specified by the SFIR of the selected SFI and forwards the packet. See Figure 1. - Thus the SFF can be seen as a portal in the underlay network through + Thus the SFF can be seen as a gateway in the underlay network through which a particular SFI is reached. + Figure 1 shows a reference model for the SFC architecture. There are + four SFFs (SFF-1 through SFF-4) connected by tunnels across the + underlay network. Packets arrive at a Classifier and are channelled + along SFPs to destinations reachable through SFF-4. + + SFF-1 and SFF-4 each have one instance of one SF attached (SFa and + SFe). SFF-2 has two types of SF attached: there is one instance of + one (SFc), and three instances of the other (SFb). SFF-3 has just + one instance of an SF (SFd), but it in this case the type of SFd is + the same type as SFb (SFTx). + + This figure demonstrates how load balancing can be achieved. Suppose + an SFC needs to include SFa, an SF of type SFTx, and SFd. A number + of SFPs can be constructed using any instance of SFb or using SFd. + Packets | | | | | | | | | ------------ | | | Classifier | | | ------------ | | - ------- ------- - | | Tunnel | | - | SFF |=============| SFF |=========== ......... - | | | | # : SFT : - | | -+---+- # : ----- : - | | / \ # : | SFI | : - | | ....../.......\...... # : --+-- : - | | : / \ : # ....|.... - | | : -+--- ---+- : # | - | | : | SFI | | SFI | : # ---+--- - | | : ----- ----- : ====| |--- - | | : : | SFF |--- Dests - | | : ----- : ====| |--- - | | : | SFI | : # ------- - | | : --+-- : # - | | : SFT | : # - | | ..........|.......... # - | | | # - | | | # - | | ---+--- # - | | | | # - | |=============| SFF |=========== - ------- | | - ------- + ------- --------- ------- + | | Tunnel | | | | + | SFF-1 |===============| SFF-2 |=========| SFF-4 | + | | | | | | + | | -+-----+- | | + | | ,,,,,,,,,,,,,,/,, \ | | + | | ' .........../. ' ..\...... | | + | | ' : SFb / : ' : \ SFc : | | + | | ' : ---+- : ' : --+-- : | | + | | ' : -| SFI | : ' : | SFI | : | | + | | ' : -| ----- : ' : ----- : | | + | | ' : | ----- : ' ......... | | + | | ' : ----- : ' | | + | | ' ............. ' | |--- Dests + | | ' ' | |--- Dests + | | ' ' | | + | | ' ......... ' | | + | | ' : ----- : ' | | + | | ' : | SFI | : ' | | + | | ' : --+-- : ' | | + | | ' :SFd | : ' | | + | | ' ....|.... ' | | + | | ' | ' | | + | | ' SFTx | ' | | + | | ',,,,,,,,|,,,,,,,,' | | + | | | | | + | | | | | + | | ---+--- | | + | | | | | | + | |======| SFF-3 |====================| | + ---+--- | | ---+--- + | ------- | + + ....|.... ....|.... + : | SFa: : | SFe: + : --+-- : : --+-- : + : | SFI | : : | SFI | : + : ----- : : ----- : + ......... ......... Figure 1: The SFC Architecture Reference Model 3. BGP SFC Routes This document defines a new AFI/SAFI for BGP, known as "SFC", with an NLRI that is described in this section. The format of the SFC NLRI is shown in Figure 2. @@ -436,103 +476,119 @@ The detailed encoding and procedures for these Route Types are described in subsequent sections. The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760] with an Address Family Identifier (AFI) of TBD1 and a Subsequent Address Family Identifier (SAFI) of TBD2. The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC NLRI, encoded as specified above. - In order for two BGP speakers to exchange SFC NLRIs, they must use + In order for two BGP speakers to exchange SFC NLRIs, they MUST use BGP Capabilities Advertisements to ensure that they both are capable of properly processing such NLRIs. This is done as specified in [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI of TBD1 and a SAFI of TBD2. 3.1. Service Function Instance Route (SFIR) Figure 3 shows the Route Type specific NLRI of the SFIR. +--------------------------------------------+ | Route Distinguisher (RD) (8 octets) | +--------------------------------------------+ | Service Function Type (2 octets) | +--------------------------------------------+ Figure 3: SFIR Route Type specific NLRI Per [RFC4364] the RD field comprises a two byte Type field and a six - byte Value field. Two SFIs of the same SFT must be associated with + byte Value field. Two SFIs of the same SFT MUST be associated with different RDs, where the association of an SFI with an RD is determined by provisioning. If two SFIRs are originated from - different administrative domains, they must have different RDs. In + different administrative domains, they MUST have different RDs. In particular, SFIRs from different VPNs (for different service function - overlay networks) must have different RDs, and those RDs must be + overlay networks) MUST have different RDs, and those RDs MUST be different from any non-VPN SFIRs. - The Service Function Type identifies a service function, e.g., + The Service Function Type identifies a service function type, e.g., classifier, firewall, load balancer, etc. There may be several SFIs that can perform a given Service Function. Each node hosting an SFI - must originate an SFIR for each type of SF that it hosts, and it may - advertise an SFIR for each instance of each type of SF. The SFIR - representing a given SFI will contain an NLRI with RD field set to an - RD as specified above, and with SFT field set to identify that SFI's - Service Function Type. The values for the SFT field are taken from a - registry administered by IANA (see Section 10). A BGP Update - containing one or more SFIRs will also include a Tunnel Encapsulation - attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be - sent to an SFI identified in one of the SFIRs, it will be - encapsulated as specified by the Tunnel Encapsulation attribute, and - then transmitted through the underlay network. + MUST originate an SFIR for each type of SF that it hosts, and it may + advertise an SFIR for each instance of each type of SF. The minimal + advertisement allows construction of valid SFPs and leaves the + selection of SFIs to the local SFF; the detailed advertisement may + have scaling concerns, but allows a Controller that constructs an SFP + to make an explicit choice of SFI. + + The SFIR representing a given SFI will contain an NLRI with RD field + set to an RD as specified above, and with SFT field set to identify + that SFI's Service Function Type. The values for the SFT field are + taken from a registry administered by IANA (see Section 10). A BGP + Update containing one or more SFIRs MUST also include a Tunnel + Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data + packet needs to be sent to an SFI identified in one of the SFIRs, it + will be encapsulated as specified by the Tunnel Encapsulation + attribute, and then transmitted through the underlay network. + + Note that the Tunnel Encapsulation attribute MUST contain sufficient + information to allow the advertising SFF to identify the overlay or + VPN network which a received packet is transiting. This is because + the [SPI, SI] in a received packet is specific to a particular + overlay or VPN network. 3.1.1. SFI Pool Identifier Extended Community This document defines a new transitive extended community of type TBD6 with Sub-Type 0x00 called the SFI Pool Identifier extended - community. It can be included in SFIR advertisements, and is used to + community. It MAY be included in SFIR advertisements, and is used to indicate the identity of a pool of SFIRs to which an SFIR belongs. Since an SFIR may be a member of multiple pools, multiple of these extended communities may be present on a single SFIR advertisement. SFIR pools allow SFIRs to be grouped for any purpose. Possible uses - include control plane scalability and stability. + include control plane scalability and stability. A pool identifier + may be included in an SFPR to indicate a set of SFIs that are + acceptable at a specific point on an SFP (see Section 3.2.1.3 and + Section 4.3). The SFI Pool Identifier extended community is encoded in 8 octets as shown in Figure 4. +--------------------------------------------+ - | Type = 0x80 (1 octet) | + | Type = TBD6 (1 octet) | +--------------------------------------------+ - | Sub-Type = TBD6 (1 octet) | + | Sub-Type = 0x00 (1 octet) | +--------------------------------------------+ | SFI Pool Identifier Value (6 octets) | +--------------------------------------------+ Figure 4: The SFI Pool Identifier Extended Community The SFI Pool Identifier Value is encoded in a 6 octet field in - network byte order, and is a globally unique value. + network byte order, and is a globally unique value. This means that + pool identifiers need to be centrally managed, which is consistent + with the assignment of SFIs to pools. 3.1.2. MPLS Mixed Swapping/Stacking Extended Community This document defines a new transitive extended community of type TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking Labels. The community is encoded as shown in Figure 5. It contains a pair of MPLS labels: an SFC Context Label and an SF Label as described in [I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a 3-octet (24 bit) field with 4 trailing bits that MUST be set to zero. +--------------------------------------------+ - | Type = 0x80 (1 octet) | + | Type = TBD7 (1 octet) | +--------------------------------------------| - | Sub-Type = TBD7 (1 octet) | + | Sub-Type = 0x00 (1 octet) | +--------------------------------------------| | SFC Context Label (3 octets) | +--------------------------------------------| | SF Label (3 octets) | +--------------------------------------------+ Figure 5: The MPLS Mixed Swapping/Stacking Extended Community Note that it is assumed that each SFF has one or more globally unique SFC Context Labels and that the context label space and the SPI @@ -550,42 +606,42 @@ +-----------------------------------------------+ | Route Distinguisher (RD) (8 octets) | +-----------------------------------------------+ | Service Path Identifier (SPI) (3 octets) | +-----------------------------------------------+ Figure 6: SFPR Route Type Specific NLRI Per [RFC4364] the RD field comprises a two byte Type field and a six - byte Value field. All SFPs must be associated with different RDs. + byte Value field. All SFPs MUST be associated with different RDs. The association of an SFP with an RD is determined by provisioning. - If two SFPRs are originated from different Controllers they must have + If two SFPRs are originated from different Controllers they MUST have different RDs. Additionally, SFPRs from different VPNs (i.e., in - different service function overlay networks) must have different RDs, - and those RDs must be different from any non-VPN SFPRs. + different service function overlay networks) MUST have different RDs, + and those RDs MUST be different from any non-VPN SFPRs. The Service Path Identifier is defined in [RFC8300] and is the value to be placed in the Service Path Identifier field of the NSH header of any packet sent on this Service Function Path. It is expected that one or more Controllers will originate these routes in order to configure a service function overlay network. The SFP is described in a new BGP Path attribute, the SFP attribute. Section 3.2.1 shows the format of that attribute. 3.2.1. The SFP Attribute [RFC4271] defines the BGP Path attribute. This document introduces a - new Path attribute called the SFP attribute with value TBD3 to be - assigned by IANA. The first SFP attribute MUST be processed and - subsequent instances MUST be ignored. + new Optional Transitive Path attribute called the SFP attribute with + value TBD3 to be assigned by IANA. The first SFP attribute MUST be + processed and subsequent instances MUST be ignored. The common fields of the SFP attribute are set as follows: o Optional bit is set to 1 to indicate that this is an optional attribute. o The Transitive bit is set to 1 to indicate that this is a transitive attribute. o The Extended Length bit is set according to the length of the SFP @@ -602,38 +658,41 @@ o Length: A two octet field indicating the length of the data following the Length field counted in octets. o Value: The contents of the TLV. The formats of the TLVs defined in this document are shown in the following sections. The presence rules and meanings are as follows. o The SFP attribute contains a sequence of zero or more Association - TLVs. That is, the Association TLV is optional. Each Association + TLVs. That is, the Association TLV is OPTIONAL. Each Association TLV provides an association between this SFPR and another SFPR. Each associated SFPR is indicated using the RD with which it is advertised (we say the SFPR-RD to avoid ambiguity). o The SFP attribute contains a sequence of one or more Hop TLVs. Each Hop TLV contains all of the information about a single hop in the SFP. o Each Hop TLV contains an SI value and a sequence of one or more SFT TLVs. Each SFT TLV contains an SFI reference for each instance of an SF that is allowed at this hop of the SFP for the specific SFT. Each SFI is indicated using the RD with which it is advertised (we say the SFIR-RD to avoid ambiguity). + Malformed SFP attributes, or those that in error in some way, MUST be + handled as described in Section 6 of [RFC4271]. + 3.2.1.1. The Association TLV - The Association TLV is an optional TLV in the SFP attribute. It may + The Association TLV is an optional TLV in the SFP attribute. It MAY be present multiple times. Each occurrence provides an association with another SFP as advertised in another SFPR. The format of the Association TLV is shown in Figure 7 +--------------------------------------------+ | Type = 1 (1 octet) | +--------------------------------------------| | Length (2 octets) | +--------------------------------------------| | Association Type (1 octet) | +--------------------------------------------| @@ -681,21 +740,21 @@ Therefore, processing of an association MUST NOT be rejected simply because the Associated SFPR-RD is unknown. Further discussion of correlation of SFPRs is provided in Section 7.2. 3.2.1.2. The Hop TLV There is one Hop TLV in the SFP attribute for each hop in the SFP. The format of the Hop TLV is shown in Figure 8. At least one Hop TLV - must be present in an SFP attribute. + MUST be present in an SFP attribute. +--------------------------------------------+ | Type = 2 (1 octet) | +--------------------------------------------| | Length (2 octets) | +--------------------------------------------| | Service Index (1 octet) | +--------------------------------------------| | Hop Details (variable) | +--------------------------------------------+ @@ -716,20 +775,23 @@ The Hop Details field consists of a sequence of one or more sub- TLVs. Each hop of the SFP may demand that a specific type of SF is executed, and that type is indicated in sub-TLVs of the Hop TLV. At least one sub-TLV MUST be present. This provides a list of which types of SF are acceptable at a specific hop, and for each type it allows a degree of control to be imposed on the choice of SFIs of that particular type. + If no Hop TLV is present in an SFP Attribute, it is a malformed + attribute + 3.2.1.3. The SFT TLV The SFT TLV MAY be included in the list of sub-TLVs of the Hop TLV. The format of the SFT TLV is shown in Figure 9. The TLV contains a list of SFIR-RD values each taken from the advertisement of an SFI. Together they form a list of acceptable SFIs of the indicated type. +--------------------------------------------+ | Type = 3 (1 octet) | +--------------------------------------------| @@ -776,21 +838,21 @@ indicates to the Classifier imposing an MPLS label stack that the current hop is to use an {SFC Context Label, SF label} rather than an {SPI, SF} label pair. See Section 7.7 for more details. 3.2.1.5. SFP Traversal With MPLS Label Stack TLV The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero length sub-TLV that can be carried in the SFP Attribute and indicates to the Classifier and the SFFs on the SFP that an MPLS labels stack with label swapping/stacking is to be used for packets traversing the - SFP. All of the SFF specified at each the SFP's hops must have + SFP. All of the SFF specified at each the SFP's hops MUST have advertised an MPLS Mixed Swapping/Stacking Extended Community (see Section 3.1.2) for the SFP to be considered usable. 3.2.2. General Rules For The SFP Attribute It is possible for the same SFI, as described by an SFIR, to be used in multiple SFPRs. When two SFPRs have the same SPI but different SFPR-RDs there can be three cases: @@ -951,22 +1013,22 @@ Identifier. I.e., the list of SFIR-RD values is effectively expanded to include the SFIR-RD of each SFIR advertised with each SFI Pool Identifier in the SFIR-RD list. The choice of SFI is explained further in Section 5. Note that an SFIR-RD value of zero has special meaning as described in that Section. 4.4. Classifier Operation - As shown in Figure 1, the Classifier is a special Service Function - that is used to assign packets to an SFP. + As shown in Figure 1, the Classifier is a component that is used to + assign packets to an SFP. The Classifier is responsible for determining to which packet flow a packet belongs (usually by inspecting the packet header), imposing an NSH, and initializing the NSH with the SPI of the selected SFP and the SI of its first hop. The Classifier may also provide an entropy indicator as described in Section 7.1. 4.5. Service Function Forwarder Operation @@ -1004,22 +1066,22 @@ The installed forwarding state may change over time reacting to changes in the underlay network and the availability of particular SFIs. Note that SFFs only create and store forwarding state for the SFPs on which they are included. They do not retain state for all SFPs advertised. An SFF may also install forwarding state to support looping, jumping, and branching. The protocol mechanism for explicit control of - looping, jumping, and branching uses a specific reserved SFT value - at a given hop of an SFPR and is described in Section 6.1. + looping, jumping, and branching uses a specific reserved SFT value at + a given hop of an SFPR and is described in Section 6.1. 4.5.1. Processing With 'Gaps' in the SI Sequence The behavior of an SF as described in [RFC8300] is to decrement the value of the SI field in the NSH by one before returning a packet to the local SFF for further processing. This means that there is a good reason to assume that the SFP is composed of a series of SFs each indicated by an SI value one less than the previous. However, there is an advantage to having non-successive SIs in an @@ -1071,21 +1133,21 @@ in an SFP. Such an implementation will not support receiving an SI value that is not present in the SFP and will discard the packets as described in [RFC8300]. 5. Selection in Service Function Paths As described in Section 2 the SPI/SI in the NSH passed back from an SFI to the SFF may leave the SFF with a choice of next hop SFTs, and a choice of SFIs for each SFT. That is, the SPI indicates an SFPR, and the SI indicates an entry in that SFPR. Each entry in an SFPR is - a set of one or more SFT/SFIR-RD pairs. The SFF must choose one of + a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of these, identify the SFF that supports the chosen SFI, and send the packet to that next hop SFF. The choice may offered for load balancing across multiple SFIs, or for discrimination between different actions necessary at a specific hop in the SFP. Different SFT values may exist at a given hop in an SFP to support several cases: o There may be multiple instances of similar service functions that are distinguished by different SFT values. For example, firewalls @@ -1424,20 +1486,23 @@ then there are two sub-cases: * If there is a choice of SFT in the hop indicated by the value of the SI (including SI = 0) then SFT = 0 means there is a free choice according to local policy of which SFT to use). * If there is no choice of SFT in the hop indicated by the value of SI, then SFT = 0 means that the value of the SFT at that hop as indicated in the SPFR for the indicated SPI MUST be used. + Note that each FlowSpec update MUST be tagged with the route target + of the overlay or VPN network for which it is intended. + 7.6. Choice of Data Plane SPI/SI Representation This document ties together the control and data planes of an SFC overlay network through the use of the SPI/SI which is nominally carried in the NSH of a given packet. However, in order to handle situations in which the NSH is not ubiquitously deployed, it is also possible to use alternative data plane representations of the SPI/SI by carrying the identical semantics in other protocol fields such as MPLS labels [I-D.ietf-mpls-sfc]. @@ -2317,33 +2382,44 @@ Avinash Lingala AT&T Email: ar977m@att.com 12. Acknowledgements Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful comments, and to Joel Halpern for discussions that improved this document. Yuanlong Jiang provided a useful review and caught some - important issues. + important issues. Stephane Litkowski did an exceptionally good and + detailed document shepherd review. Andy Malis contributed text that formed the basis of Section 7.8. 13. References - 13.1. Normative References [I-D.ietf-idr-tunnel-encaps] Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11 (work in progress), February 2019. + [I-D.ietf-mpls-sfc] + Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based + Forwarding Plane for Service Function Chaining", draft- + ietf-mpls-sfc-05 (work in progress), February 2019. + + [I-D.ietf-mpls-sfc-encapsulation] + Malis, A., Bryant, S., Halpern, J., and W. Henderickx, + "MPLS Transport Encapsulation For The SFC NSH", draft- + ietf-mpls-sfc-encapsulation-03 (work in progress), March + 2019. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . @@ -2354,66 +2430,56 @@ [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, . + [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function + Chaining (SFC) Architecture", RFC 7665, + DOI 10.17487/RFC7665, October 2015, + . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . 13.2. Informative References - [I-D.ietf-mpls-sfc] - Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based - Forwarding Plane for Service Function Chaining", draft- - ietf-mpls-sfc-05 (work in progress), February 2019. - - [I-D.ietf-mpls-sfc-encapsulation] - Malis, A., Bryant, S., Halpern, J., and W. Henderickx, - "MPLS Encapsulation For The SFC NSH", draft-ietf-mpls-sfc- - encapsulation-02 (work in progress), December 2018. - [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, . [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April 2015, . - [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function - Chaining (SFC) Architecture", RFC 7665, - DOI 10.17487/RFC7665, October 2015, - . - Authors' Addresses Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk John Drake Juniper Networks