--- 1/draft-ietf-bess-nsh-bgp-control-plane-04.txt 2019-01-12 07:13:24.320752280 -0800 +++ 2/draft-ietf-bess-nsh-bgp-control-plane-05.txt 2019-01-12 07:13:24.428754885 -0800 @@ -1,23 +1,24 @@ BESS Working Group A. Farrel -Internet-Draft J. Drake -Intended status: Standards Track E. Rosen -Expires: January 2, 2019 Juniper Networks +Internet-Draft Old Dog Consulting +Intended status: Standards Track J. Drake +Expires: July 16, 2019 E. Rosen + Juniper Networks J. Uttaro AT&T L. Jalil Verizon - July 1, 2018 + January 12, 2019 BGP Control Plane for NSH SFC - draft-ietf-bess-nsh-bgp-control-plane-04 + draft-ietf-bess-nsh-bgp-control-plane-05 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 @@ -36,25 +37,25 @@ 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 January 2, 2019. + This Internet-Draft will expire on July 15, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect 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 @@ -67,72 +68,72 @@ 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5 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.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13 - 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 - 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 36 - 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 . . . . . . . . . . . . . 38 - 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 38 - 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 39 - 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 . . . . 41 - 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 . . . . . . . . . . . 51 + 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 + 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35 + 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 35 + 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 36 + 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 37 + 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 37 + 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38 + 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 38 + 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 39 + 8.9. Examples of SFPs with Stateful Service Functions . . . . 40 + 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 40 + 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 41 + 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 42 + 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 44 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 47 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 + 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 48 + 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 48 + 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 48 + 10.4. New SFP Association Type Registry . . . . . . . . . . . 49 + 10.5. New Service Function Type Registry . . . . . . . . . . . 49 10.6. New Generic Transitive Experimental Use Extended - Community Sub-Types . . . . . . . . . . . . . . . . . . 51 - 10.7. New BGP Transitive Extended Community Types . . . . . . 52 - 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 52 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 53 - 13.2. Informative References . . . . . . . . . . . . . . . . . 54 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 + Community Sub-Types . . . . . . . . . . . . . . . . . . 50 + 10.7. New BGP Transitive Extended Community Types . . . . . . 50 + 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 51 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 51 + 13.2. Informative References . . . . . . . . . . . . . . . . . 52 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 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. @@ -465,67 +466,68 @@ 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 particular, SFIRs from different VPNs (for different service function 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., 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 SFI that it hosts. The SFIR + must originate an SFIR for each type of SF that it hosts, and it may + advertize 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. 3.1.1. SFI Pool Identifier Extended Community - This document defines a new transitive extended community with Sub- - Type TBD6 called the SFI Pool Identifier extended community. It can - 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. + 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 + 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. The SFI Pool Identifier extended community is encoded in 8 octets as shown in Figure 4. +--------------------------------------------+ | Type = 0x80 (1 octet) | +--------------------------------------------+ | Sub-Type = TBD6 (1 octet) | +--------------------------------------------+ - | SFI Pool Identifier (6 octets) | + | SFI Pool Identifier Value (6 octets) | +--------------------------------------------+ Figure 4: The SFI Pool Identifier Extended Community - The SFI Pool Identifier is encoded in a 6 octet field in network - byte order and is a globally unique value. + The SFI Pool Identifier Value is encoded in a 6 octet field in + network byte order, and is a globally unique value. 3.1.2. MPLS Mixed Swapping/Stacking Extended Community - This document defines a new transitive extended community with Sub- - Type TBD7 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. + 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) | +--------------------------------------------| | Sub-Type = TBD7 (1 octet) | +--------------------------------------------| | SFC Context Label (3 octets) | +--------------------------------------------| | SF Label (3 octets) | +--------------------------------------------+ @@ -650,26 +652,25 @@ values are tracked in an IANA registry (see Section 10.4). Only one value is defined in this document: type 1 indicates association of two unidirectional SFPs to form a bidirectional SFP. An SFP attribute SHOULD NOT contain more than one Association TLV with Association Type 1: if more than one is present, the first one MUST be processed and subsequent instances MUST be ignored. Note that documents that define new Association Types must also define the presence rules for Association TLVs of the new type. - The Associated SFPR-RD contains the RD of some other SFPR - advertisement that contains the SFP with which this SFP is - associated. + The Associated SFPR-RD contains the RD of the associated SFP as + advertized in an SFPR. The Associated SPI contains the SPI of the associated SFP as - advertised in the SFPR indicated by the Associated SFPR-RD field. + advertised in an SFPR. Association TLVs with unknown Association Type values SHOULD be ignored. Association TLVs that contain an Associated SFPR-RD value equal to the RD of the SFPR in which they are contained SHOULD be ignored. If the Associated SPI is not equal to the SPI advertised in the SFPR indicated by the Associated SFPR-RD then the Association TLV SHOULD be ignored. Note that when two SFPRs reference each other using the Association TLV, one SFPR advertisement will be received before the other. @@ -702,126 +704,86 @@ Type is set to 2 to indicate a Hop TLV. Length indicates the length in octets of the Service Index and Hop Details fields. The Service Index is defined in [RFC8300] and is the value found in the Service Index field of the NSH header that an SFF will use to lookup to which next SFI a packet should be sent. The Hop Details field consists of a sequence of one or more sub- - TLVs. These may be SFT-SFI TLVs and SFT-Pool TLVs. + 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, and the list of sub-TLVs may - include SFT-SFI and SFT-Pool TLVs as described in the following - sections. This provides a list of which types of SF are acceptable - at a specific hop, and for each type it allow a degree of control to - be imposed on the choice of SFIs of that particular type. + 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. -3.2.1.3. The SFT-SFI TLV +3.2.1.3. The SFT TLV - The SFT-SFI TLV MAY be included in the list of sub-TLVs of the Hop - TLV. The format of the SFT-SFI 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. + 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) | +--------------------------------------------| | Length (2 octets) | +--------------------------------------------| | Service Function Type (2 octets) | +--------------------------------------------| | SFIR-RD List (variable) | +--------------------------------------------+ - Figure 9: The Format of the SFT-SFI TLV + Figure 9: The Format of the SFT TLV The fields are as follows: Type is set to 3 to indicate an SFT TLV. Length indicates the length in octets of the Service Function Type and SFIR-RD List fields. The Service Function Type value indicates the category (type) of SF that is to be executed at this hop. The types are as advertised for the SFs supported by the SFFs SFT values in the range 1-31 are Special Purpose SFT values and have meanings defined by the documents that describe them - the value 'Change Sequence' is defined in Section 6.1 of this document. The hop description is further qualified beyond the specification of the SFTs by listing, for each SFT in each hop, the SFIs that may be used at the hop. The SFIs are identified using the SFIR- - RDs from the advertisements of the SFIs in the SFIRs. An SFIR-RD - of value zero has special meaning as described in Section 5. Each - entry in the list is 8 octets long, and the number of entries in - the list can be deduced from the value of the Length field. - -3.2.1.4. The SFT-Pool TLV - - The SFT-Pool TLV MAY be included in the list of sub-TLVs of the Hop - TLV. The format of the SFT-Pool TLV is shown in Figure 10. The TLV - contains a list of SFI Pool Identifier values each taken from the - advertisement of an SFI. Together they form a list of pools of - acceptable SFIs of the indicated type. - - +--------------------------------------------+ - | Type = 4 (1 octet) | - +--------------------------------------------| - | Length (2 octets) | - +--------------------------------------------| - | Service Function Type (2 octets) | - +--------------------------------------------| - | SFI Pool List (variable) | - +--------------------------------------------+ - - Figure 10: The Format of the SFT TLV - - The fields are as follows: - - Type is set to 4 to indicate an SFT TLV. - - Length indicates the length in octets of the Service Function Type - and SFIR-RD List fields. - - The Service Function Type value indicates the category (type) of - SF that is to be executed at this hop. The types are as - advertised for the SFs supported by the SFFs SFT values in the - range 1-31 are Special Purpose SFT values and have meanings - defined by the documents that describe them - the value 'Change - Sequence' is defined in Section 6.1 of this document. - - The hop description is further qualified beyond the specification - of the SFTs by listing, for each SFT in each hop, the SFI Pool - Identifiers that may be used at the hop. The SFI pools are - identified using SFI Pool Identifiers from the advertisements of - the SFIs in the SFIRs. Each entry in the list is 6 octets long, - and the number of entries in the list can be deduced from the - value of the Length field. + RDs from the advertisements of the SFIs in the SFIRs. Note that + if the list contains one or more SFI Pool Identifiers, then for + each the SFIR-RD list is effectively expanded to include the SFIR- + RD of each SFIR advertised with that SFI Pool Identifier. An + SFIR-RD of value zero has special meaning as described in + Section 5. Each entry in the list is eight octets long, and the + number of entries in the list can be deduced from the value of the + Length field. -3.2.1.5. MPLS Swapping/Stacking TLV +3.2.1.4. MPLS Swapping/Stacking TLV - The MPLS Swapping/Stacking TLV (Type value 5) is a zero length sub- - TLV that can be carried in the Hop TLV and is used when the data - representation is MPLS (see Section 7.6). It indicates to the - Classifier that imposes an MPLS label stack whether the current hop - is to use an {SPI, SI} label pair for label swapping or a {Context - label, SF label}. See Section 7.7 for more details. + The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub- + TLV that is optionally present in the Hop TLV and is used when the + data representation is MPLS (see Section 7.6). When present it + 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.6. SFP Traversal With MPLS Label Stack TLV +3.2.1.5. SFP Traversal With MPLS Label Stack TLV - The SFP Traversal With MPLS Label Stack TLV (Type value 6) is a zero + 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 advertised an SPI/SI Representation sub-TLV (see Section 7.6) with bit 0 set to 0 and bit 1 set to 1 for the SFP to be considered usable. 3.2.2. General Rules For The SFP Attribute @@ -883,22 +845,22 @@ (i.e., imports more than one RT) may find it helpful to maintain separate forwarding state for each overlay network. 4.2. Service Function Instance Routes The SFIR (see Section 3.1) is used to advertise the existence and location of a specific Service Function Instance and consists of: o The RT as just described. - o A Service Function Type (SFT) that is the category of Service - Function that is provided (such as "firewall"). + o A Service Function Type (SFT) that is the type of service function + that is provided (such as "firewall"). o A Route Distinguisher (RD) that is unique to a specific instance of a service function. 4.3. Service Function Path Routes The SFPR (see Section 3.2) describes a specific path of a Service Function Chain. The SFPR contains the Service Path Identifier (SPI) used to identify the SFP in the NSH in the data plane. It also contains a sequence of Service Indexes (SIs). Each SI identifies a @@ -992,22 +954,22 @@ 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. 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 to include the SPI of the selected SFPR - and to include the SI from first hop of the selected SFP. + 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 Each packet sent to an SFF is transmitted encapsulated in an NSH. The NSH includes an SPI and SI: the SPI indicates the SFPR advertisement that announced the Service Function Path; the tuple SPI/SI indicates a specific hop in a specific path and maps to the @@ -1040,22 +1002,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 is described in Section 6.1 using a - special value of the SFT within an entry in an SFPR. + looping, jumping, and branching uses a specific resereved 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 @@ -1085,22 +1047,22 @@ resulting from a change in SPI may have wide ripples and give scope for errors that are hard to trace. Therefore, while this document requires that the SI values in an SFP are monotonic decreasing, it makes no assumption that the SI values are sequential. Configuration tools may apply that rule, but they are not required to. To support this, an SFF SHOULD process as follows when it receives a packet: o If the SI indicates a known entry in the SFP, the SFF MUST process - the packet as normal, looking up the SI and determining whether to - deliver the packet to a local SFI or to forward it to another SFF. + the packet as normal, looking up the SI and determining to which + local SFI to deliver the packet. o If the SI does not match an entry in the SFP, the SFF MUST reduce the SI value to the next (smaller) value present in the SFP and process the packet using that SI. o If there is no smaller SI (i.e., if the end of the SFP has been reached) the SFF MUST treat the SI value as invalid as described in [RFC8300]. SFF implementations MAY choose to only support contiguous SI values @@ -1413,30 +1375,30 @@ [RFC5575] defines a set of BGP routes that can be used to identify the packets in a given flow using fields in the header of each packet, and a set of actions, encoded as extended communities, that can be used to disposition those packets. This document enables the use of RFC 5575 mechanisms by SFC Classifiers by defining a new action extended community called "Flow Spec for SFC classifiers" identified by the value TBD4. Note that other action extended communities may also be present. This extended community is encoded as an 8-octet value, as shown in - Figure 11: + Figure 10: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x80 | Sub-Type=TBD4 | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (cont.) | SI | SFT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 11: The Format of the Flow Spec for SFC Classifiers Extended + Figure 10: The Format of the Flow Spec for SFC Classifiers Extended Community The extended community contains the Service Path Identifier (SPI), Service Index (SI), and Service Function Type (SFT) as defined elsewhere in this document. Thus, each action extended community defines the entry point (not necessarily the first hop) into a specific service function path. This allows, for example, different flows to enter the same service function path at different points. Note that a given Flow Spec update according to [RFC5575] may include @@ -1564,21 +1526,21 @@ Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows: SFF1 SFT=41 and SFT=42 SFF2 SFT=41 and SFT=43 SFF3 SFT=42 and SFT=44 SFF4 SFT=43 and SFT=44 The service function network also contains a Controller with address 198.51.100.1. - This example service function overlay network is shown in Figure 12. + This example service function overlay network is shown in Figure 11. -------------- | Controller | | 198.51.100.1 | ------ ------ ------ ------ -------------- | SFI | | SFI | | SFI | | SFI | |SFT=41| |SFT=42| |SFT=41| |SFT=43| ------ ------ ------ ------ \ / \ / --------- --------- ---------- | SFF1 | | SFF2 | @@ -1588,21 +1550,21 @@ ---------- --------- --------- | SFF3 | | SFF4 | |192.0.2.3| |192.0.2.4| --------- --------- / \ / \ ------ ------ ------ ------ | SFI | | SFI | | SFI | | SFI | |SFT=42| |SFT=44| |SFT=43| |SFT=44| ------ ------ ------ ------ - Figure 12: Example Service Function Overlay Network + Figure 11: Example Service Function Overlay Network The SFFs advertise routes to the SFIs they support. So we see the following SFIRs: RD = 192.0.2.1,1, SFT = 41 RD = 192.0.2.1,2, SFT = 42 RD = 192.0.2.2,1, SFT = 41 RD = 192.0.2.2,2, SFT = 43 RD = 192.0.2.3,7, SFT = 42 RD = 192.0.2.3,8, SFT = 44 @@ -1820,38 +1782,38 @@ 8.9. Examples of SFPs with Stateful Service Functions This section provides some examples to demonstrate establishing SFPs when there is a choice of service functions at a particular hop, and where consistency of choice is required in both directions. The scenarios that give rise to this requirement are discussed in Section 7.3. 8.9.1. Forward and Reverse Choice Made at the SFF - Consider the topology shown in Figure 13. There are three SFFs + Consider the topology shown in Figure 12. There are three SFFs arranged neatly in a line, and the middle one (SFF2) supports three SFIs all of SFT 42. These three instances can be used by SFF2 to load balance so that no one instance is swamped. ------ ------ ------ ------ ------ | SFI | | SFIa | | SFIb | | SFIc | | SFI | |SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43| ------ ------\ ------ /------ ------ \ \ | / / --------- --------- --------- ---------- | SFF1 | | SFF2 | | SFF3 | --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> --> |Classifier| --------- --------- --------- | | ---------- - Figure 13: Example Where Choice is Made at the SFF + Figure 12: Example Where Choice is Made at the SFF This leads to the following SFIRs being advertised. RD = 192.0.2.1,11, SFT = 41 RD = 192.0.2.2,11, SFT = 42 (for SFIa) RD = 192.0.2.2,12, SFT = 42 (for SFIb) RD = 192.0.2.2,13, SFT = 42 (for SFIc) RD = 192.0.2.3,11, SFT = 43 The controller can create a single forward SFP giving SFF2 the choice @@ -1887,21 +1849,21 @@ 8.9.2. Parallel End-to-End SFPs with Shared SFF The mechanism described in Section 8.9.1 might not be desirable because of the functional assumptions it places on SFF2 to be able to load balance with suitable flow identification, stability, and equality in both directions. Instead, it may be desirable to place the responsibility for flow classification in the Classifier and let it determine load balancing with the implied choice of SFIs. - Consider the network graph as shown in Figure 13 and with the same + Consider the network graph as shown in Figure 12 and with the same set of SFIRs as listed in Section 8.9.1. In this case the controller could specify three forward SFPs with their corresponding associated reverse SFPs. Each bidirectional pair of SFPs uses a different SFI for the SF of type 42. The controller can instruct the Classifier how to place traffic on the three bidirectional SFPs, or can treat them as a group leaving the Classifier responsible for balancing the load. SFP14: RD = 198.51.100.1,114, SPI = 28, Assoc-Type = 1, Assoc-RD = 198.51.100.1,117, Assoc-SPI = 31, @@ -1937,21 +1899,21 @@ Assoc-Type = 1, Assoc-RD = 198.51.100.1,116, Assoc-SPI = 30, [SI = 255, SFT = 43, RD = 192.0.2.3,11], [SI = 254, SFT = 42, RD = 192.0.2.2,13], [SI = 253, SFT = 41, RD = 192.0.2.1,11] 8.9.3. Parallel End-to-End SFPs with Separate SFFs While the examples in Section 8.9.1 and Section 8.9.2 place the choice of SFI as subtended from the same SFF, it is also possible that the SFIs are each subtended from a different SFF as shown in - Figure 14. In this case it is harder to coordinate the choices for + Figure 13. In this case it is harder to coordinate the choices for forward and reverse paths without some form of coordination between SFF1 and SFF3. Therefore it would be normal to consider end-to-end parallel SFPs as described in Section 8.9.2. ------ | SFIa | |SFT=42| ------ ------ | | SFI | --------- @@ -1971,21 +1933,21 @@ :.---------.: | SFF7 | |192.0.2.7| --------- | ------ | SFIc | |SFT=42| ------ - Figure 14: Second Example With Parallel End-to-End SFPs + Figure 13: Second Example With Parallel End-to-End SFPs In this case, five SFIRs are advertised as follows: RD = 192.0.2.1,11, SFT = 41 RD = 192.0.2.5,11, SFT = 42 (for SFIa) RD = 192.0.2.6,11, SFT = 42 (for SFIb) RD = 192.0.2.7,11, SFT = 42 (for SFIc) RD = 192.0.2.3,11, SFT = 43 In this case the controller could specify three forward SFPs with @@ -2036,21 +1998,21 @@ The mechanism of parallel SFPs demonstrated in Section 8.9.3 is perfectly functional and may be practical in many environments. However, there may be scaling concerns because of the large amount of state (knowledge of SFPs, i.e., SFPR advertisements retained) if there is a very large amount of choice of SFIs (for example, tens of instances of the same stateful SF), or if there are multiple choices of stateful SF along a path. This situation may be mitigated using SFP fragments that are combined to form the end to end SFPs. The example presented here is necessarily simplistic, but should - convey the basic principle. The example presented in Figure 15 is + convey the basic principle. The example presented in Figure 14 is similar to that in Section 8.9.3 but with an additional first hop. ------ | SFIa | |SFT=43| ------ ------ ------ | | SFI | | SFI | --------- |SFT=41| |SFT=42| | SFF5 | ------ ------ ..|192.0.2.5|.. @@ -2068,21 +2030,21 @@ :.---------.: | SFF7 | |192.0.2.7| --------- | ------ | SFIc | |SFT=43| ------ - Figure 15: Example With Parallel SFPs Downstream of Choice + Figure 14: Example With Parallel SFPs Downstream of Choice The six SFIs are advertised as follows: RD = 192.0.2.1,11, SFT = 41 RD = 192.0.2.2,11, SFT = 42 RD = 192.0.2.5,11, SFT = 43 (for SFIa) RD = 192.0.2.6,11, SFT = 43 (for SFIb) RD = 192.0.2.7,11, SFT = 43 (for SFIc) RD = 192.0.2.3,11, SFT = 44 @@ -2212,24 +2174,23 @@ o Reference Document or Contact o Registration Date The registry should initially be populated as follows: Type | Name | Reference | Date ------+-------------------------+---------------+--------------- 1 | Association TLV | [This.I-D] | Date-to-be-set 2 | Hop TLV | [This.I-D] | Date-to-be-set - 3 | SFT-SFI TLV | [This.I-D] | Date-to-be-set - 4 | SFT-Pool TLV | [This.I-D] | Date-to-be-set - 5 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set - 6 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set + 3 | SFT TLV | [This.I-D] | Date-to-be-set + 4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set + 5 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set 10.4. New SFP Association Type Registry IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA is request to create a new subregistry called the "SFP Association Type" registry. Valid values are in the range 0 to 65535. o Values 0 and 65535 are to be marked "Reserved, not to be @@ -2342,22 +2303,22 @@ Thanks to Tony Przygienda for helpful comments, and to Joel Halpern for discussions that improved this document. Yuanlong Jiang provided a useful review and caught some important issues. 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-09 - (work in progress), February 2018. + Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-10 + (work in progress), August 2018. [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, . @@ -2388,21 +2349,21 @@ [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-01 (work in progress), May 2018. + ietf-mpls-sfc-04 (work in progress), November 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, . @@ -2413,23 +2374,23 @@ . [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 - Juniper Networks + Old Dog Consulting - Email: afarrel@juniper.net + Email: adrian@olddog.co.uk John Drake Juniper Networks Email: jdrake@juniper.net Eric Rosen Juniper Networks Email: erosen@juniper.net