--- 1/draft-ietf-bess-nsh-bgp-control-plane-12.txt 2019-12-13 13:13:14.331384958 -0800 +++ 2/draft-ietf-bess-nsh-bgp-control-plane-13.txt 2019-12-13 13:13:14.451388032 -0800 @@ -1,24 +1,24 @@ BESS Working Group A. Farrel Internet-Draft Old Dog Consulting Intended status: Standards Track J. Drake -Expires: February 21, 2020 E. Rosen +Expires: June 15, 2020 E. Rosen Juniper Networks J. Uttaro AT&T L. Jalil Verizon - August 20, 2019 + December 13, 2019 BGP Control Plane for NSH SFC - draft-ietf-bess-nsh-bgp-control-plane-12 + draft-ietf-bess-nsh-bgp-control-plane-13 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 @@ -38,62 +38,62 @@ 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 February 21, 2020. + This Internet-Draft will expire on June 15, 2020. 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 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Overview of Service Function Chaining . . . . . . . . . . 6 - 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7 + 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 12 - 3.1.1. SFI Pool Identifier Extended Community . . . . . . . 13 + 3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 13 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 14 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 14 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 15 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 21 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 22 4.2. Service Function Instance Routes . . . . . . . . . . . . 22 4.3. Service Function Path Routes . . . . . . . . . . . . . . 22 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 24 4.5. Service Function Forwarder Operation . . . . . . . . . . 25 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 26 5. Selection within Service Function Paths . . . . . . . . . . . 27 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 29 - 6.1. Protocol Control of Looping, Jumping, and Branching . . . 29 + 6.1. Protocol Control of Looping, Jumping, and Branching . . . 30 6.2. Implications for Forwarding State . . . . . . . . . . . . 30 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 31 7.1. Correlating Service Function Path Instances . . . . . . . 31 7.2. Considerations for Stateful Service Functions . . . . . . 32 7.3. VPN Considerations and Private Service Functions . . . . 33 7.4. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 33 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 34 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 36 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 36 @@ -120,21 +120,21 @@ 10.4. New SFP Association Type Registry . . . . . . . . . . . 54 10.5. New Service Function Type Registry . . . . . . . . . . . 55 10.6. New Generic Transitive Experimental Use Extended Community Sub-Types . . . . . . . . . . . . . . . . . . 56 10.7. New BGP Transitive Extended Community Types . . . . . . 56 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 56 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 13.1. Normative References . . . . . . . . . . . . . . . . . . 57 - 13.2. Informative References . . . . . . . . . . . . . . . . . 58 + 13.2. Informative References . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 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., 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 @@ -173,23 +173,25 @@ packet flows that satisfy specified criteria will pass. 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 [RFC8300]. + Controller (a centralized network component responsible for planning + and coordinating Service Function Chaining within the network) 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 [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. @@ -305,35 +307,45 @@ 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. 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. + 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 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, the SFF drops the packet and should log the event: - such logs are also subject to rate limits. + Also, as described in [RFC8300], 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, 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. [RFC8300] makes it clear that the intended scope is for use within a single provider's operational domain. + This document adopts the SFC architecture described in [RFC7665] and + adds a control plane to support the functions as described in + Section 2.2. An essential component of this solution is the + Controller. This is a network component responsible for planning + SFPs within the network. It gathers information about the + availability of SFIs and SFFs, instructs the control plane about the + SFPs to be programmed, and instructs the Classifiers how to assign + traffic flows to individual SFPs. + 2.2. Control Plane Overview To accomplish the function described in Section 2.1, this document 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 @@ -514,84 +526,87 @@ +--------------------------------------------+ | 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 - 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. + byte Value field. 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 the functions/features of service function can offer, 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 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. + Note that a node may advertise all SFIs of one SFT in one shot using + normal BGP Update packing. That is, all of the SFIRs in an Update + share a common Tunnel Encapsulation and RT attribute. See also + Section 3.2.1. + 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 +3.1.1. SFIR 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 + TBD6 with Sub-Type 0x00 called the SFIR Pool Identifier extended 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. 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 + The SFIR Pool Identifier extended community is encoded in 8 octets as shown in Figure 4. +--------------------------------------------+ | Type = TBD6 (1 octet) | +--------------------------------------------+ | Sub-Type = 0x00 (1 octet) | +--------------------------------------------+ - | SFI Pool Identifier Value (6 octets) | + | SFIR Pool Identifier Value (6 octets) | +--------------------------------------------+ - Figure 4: The SFI Pool Identifier Extended Community + Figure 4: The SFIR Pool Identifier Extended Community - The SFI Pool Identifier Value is encoded in a 6 octet field in + The SFIR Pool Identifier Value is encoded in a 6 octet field in 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 @@ -662,21 +677,21 @@ 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 attribute as defined in [RFC4271]. o The Attribute Type Code is set to TBD3. - The content of the SFP attribute is a series of Type-Length-Variable + The content of the SFP attribute is a series of Type-Length-Value (TLV) constructs. Each TLV may include sub-TLVs. All TLVs and sub- TLVs have a common format that is: o Type: A single octet indicating the type of the SFP attribute TLV. Values are taken from the registry described in Section 10.3. 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. @@ -829,21 +844,21 @@ The fields are as follows: 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. + to lookup to which next SFI a packet is to be sent. 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. @@ -872,51 +887,51 @@ 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 + 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. Note that - if the list contains one or more SFI Pool Identifiers, then for + if the list contains one or more SFIR 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 + RD of each SFIR advertised with that SFIR 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.4. MPLS Swapping/Stacking TLV The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub- TLV that is OPTIONAL in the Hop TLV and is used when the data representation is MPLS (see Section 7.5). 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.6 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 + to the Classifier and the SFFs on the SFP that an MPLS label 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 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. @@ -1057,48 +1072,55 @@ Service Function Type in a specific hop SI: Service Index used in the NSH to indicate a specific hop SFT: The Service Function Type used in the same advertisement of the Service Function Instance Route SFIR-RD: The Route Descriptor used in an advertisement of the Service Function Instance Route + That is, there can be multiple SFTs at a given hop as described in + Section 5. + Note that the values of SI are from the set {255, ..., 1} and are monotonically decreasing within the SFP. SIs MUST appear in order within the SFPR (i.e., monotonically decreasing) and MUST NOT appear more than once. Gaps MAY appear in the sequence as described in Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any previous instance of the SFPR (same SFPR-RD and SPI) to be discarded. - Note that if the SFIR-RD list in an SFT TLV contains one or more SFI + Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR Pool identifiers, then in the above expression, 'p' is the sum of the - number of individual SFIR-RD values and the sum for each SFI Pool - Identifier of the number of SFIRs advertised with that SFI Pool + number of individual SFIR-RD values and the sum for each SFIR Pool + Identifier of the number of SFIRs advertised with that SFIR Pool 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 + to include the SFIR-RD of each SFIR advertised with each SFIR 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 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. + packet belongs. The mechanism it uses to achieve that classification + is out of scope of this document, but might include inspection of the + packet header. The Classifier has been instructed (by the Controller + or through some other configuration mechanism) which flows are to be + assigned to which SFPs, and so it can impose an NSH on each packet + and initialize the NSH with the SPI of the selected SFP and the SI of + its first hop. 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 RD/SFT of a particular SFIR advertisement. When an SFF gets an SFPR advertisement it will first determine @@ -1120,21 +1142,27 @@ The SFF also creates next hop forwarding state for packets received back from the local SFI that need to be forwarded to the next hop in the SFP. There may be a choice of next hops as described in Section 4.3. The SFF could install forwarding state for all potential next hops, or it could choose to only install forwarding state to a subset of the potential next hops. If a choice is made then it will be as described in Section 5. The installed forwarding state may change over time reacting to changes in the underlay network and the availability of particular - SFIs. + SFIs. Note that the forwarding state describes how one SFF send + packets to another SFF, but not how those packets are routed through + the underlay network. SFFs may be connected by tunnels across the + underlay, or packets may be sent addressed to the next SFF and routed + through the underlay. In any case, transmission across the underlay + requires encapsulation of packets with a header for transport in the + underlay network. 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. @@ -1184,20 +1212,25 @@ 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]. + This makes the bevahior described in this document a superset of the + function in [RFC8300]. That is, an implementation that strictly + follows RFC 8300 in performing SI decrements in units of one, is + perfectly in line with the mechanisms defined in this document. + SFF implementations MAY choose to only support contiguous SI values 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 within 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, @@ -1277,21 +1310,21 @@ local policy. A typical policy might be to figure out the set of SFIs that are closest, and to load balance among them. But this is not the only possible policy. Thus, at any point in time when an SFF selects its next hop, it chooses from the intersection of the set of next hop RDs contained in the SFPR and the RDs contained in its local set of SFIRs. If the intersection is null, the SFPR is unusable. Similarly, when this - condition obtains the originator of the SFPR should either withdraw + condition obtains the originator of the SFPR SHOULD either withdraw the SFPR or re-advertise it with a new set of RDs for the affected hop. 6. Looping, Jumping, and Branching As described in Section 2 an SFI or an SFF may cause a packet to "loop back" to a previous SF on a path in order that a sequence of functions may be re-executed. This is simply achieved by replacing the SI in the NSH with a higher value instead of decreasing it as would normally be the case to determine the next hop in the path. @@ -1301,21 +1334,21 @@ in the SFP. This is simply achieved by replacing the SI in the NSH with a lower value than would be achieved by decreasing it by the normal amount. A more complex option to move packets from one SFP to another is described in [RFC8300] and Section 2 where it is termed "branching". This mechanism allows an SFI or SFF to make a choice of downstream treatments for packets based on local policy and output of the local SF. Branching is achieved by changing the SPI in the NSH to indicate the new path and setting the SI to indicate the point in the path at - which the packets should enter. + which the packets enter. Note that the NSH does not include a marker to indicate whether a specific packet has been around a loop before. Therefore, the use of NSH metadata may be required in order to prevent infinite loops. 6.1. Protocol Control of Looping, Jumping, and Branching If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT value "Change Sequence" (see Section 10) then this is an indication that the SFF may make a loop, jump, or branch according to local @@ -1387,22 +1420,22 @@ contain a direction indicator, so each direction must use a different SPI. As described in Section 3.2.1.1 an SFPR can contain one or more correlators encoded in Association TLVs. If the Association Type indicates "Bidirectional SFP" then the SFP advertised in the SFPR is one direction of a bidirectional pair of SFPs where the other in the pair is advertised in the SFPR with RD as carried in the Associated SFPR-RD field of the Association TLV. The SPI carried in the Associated SPI field of the Association TLV provides a cross-check - and should match the SPI advertised in the SFPR with RD as carried in - the Associated SFPR-RD field of the Association TLV. + against the SPI advertised in the SFPR with RD as carried in the + Associated SFPR-RD field of the Association TLV. As noted in Section 3.2.1.1 SFPRs reference each other one SFPR advertisement will be received before the other. Therefore processing of an association will require that the first SFPR is not rejected simply because the Associated SFPR-RD it carries is unknown. However, the SFP defined by the first SFPR is valid and SHOULD be available for use as a unidirectional SFP even in the absence of an advertisement of its partner. Furthermore, in error cases where SFPR-a associates with SFPR-b, but @@ -1533,21 +1566,21 @@ o If an SFC Classifiers Extended Community is received with SFT = 0 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. + as indicated in the SFPR for the indicated SPI MUST be used. One of the filters that the Flow Spec may describe is the VPN to which the traffic belongs. Additionally, note that to put the indicated SPI into context when multiple SFC overlays are present in one network, each FlowSpec update MUST be tagged with the route target of the overlay or VPN network for which it is intended. 7.5. Choice of Data Plane SPI/SI Representation This document ties together the control and data planes of an SFC @@ -1975,21 +2008,21 @@ with the same flow use the same SFI regardless of the direction of travel. How an SFF knows that an attached SFI is stateful is is out of scope of this document. It is assumed that this will form part of the process by which SFIs are registered as local to SFFs. Section 7.2 provides additional observations about the coordination of the use of stateful SFIs in the case of bidirectional SFPs. In general, the problems of load balancing and the selection of the - same SFIs in both directions of a bidirectional SPF can be addressed + same SFIs in both directions of a bidirectional SFP can be addressed by using sufficiently precisely specified SFPs (specifying the exact SFIs to use) and suitable programming of the Classifiers at each end of the SFPs to make sure that the matching pair of SFPs are used. SFP13: RD = 198.51.100.1:113, SPI = 27, Assoc-Type = 1, Assoc-RD = 198.51.100.1:112, Assoc-SPI = 26, [SI = 255, SFT = 43, RD = 192.0.2.3:11], [SI = 254, SFT = 42, {RD = 192.0.2.2:11, 192.0.2.2:12, 192.0.2.2:13 }], @@ -2319,21 +2352,21 @@ IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA is request to create a new subregistry called the "SFP Attribute TLVs" registry. Valid values are in the range 0 to 65535. o Values 0 and 65535 are to be marked "Reserved, not to be allocated". - o Values 1 through 65524 are to be assigned according to the "First + o Values 1 through 65534 are to be assigned according to the "First Come First Served" policy [RFC8126]. This document should be given as a reference for this registry. The new registry should track: o Type o Name @@ -2355,21 +2388,21 @@ 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 allocated". - o Values 1 through 65524 are to be assigned according to the "First + o Values 1 through 65534 are to be assigned according to the "First Come First Served" policy [RFC8126]. This document should be given as a reference for this registry. The new registry should track: o Association Type o Name o Reference Document or Contact @@ -2426,21 +2459,21 @@ "Flow Spec for SFC Classifiers" (TBD4 in this document) with this document as the reference. 10.7. New BGP Transitive Extended Community Types IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters" with a subregistry of "BGP Transitive Extended Community Types". IANA is requested to assign new types as follows: - "SFI Pool Identifier" (TBD6 in this document) with this document + "SFIR Pool Identifier" (TBD6 in this document) with this document as the reference. "MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this document) with this document as the reference. 10.8. SPI/SI Representation IANA is requested to assign a codepoint from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI Representation Sub-TLV" (TBD5 in this document) with this document @@ -2466,34 +2499,37 @@ 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. Stephane Litkowski did an exceptionally good and detailed document shepherd review. Andy Malis contributed text that formed the basis of Section 7.7. + Brian Carpenter and Martin Vigoureux provided useful reviews during + IETF last call. + 13. References 13.1. Normative References [I-D.ietf-idr-rfc5575bis] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", - draft-ietf-idr-rfc5575bis-17 (work in progress), June + draft-ietf-idr-rfc5575bis-18 (work in progress), November 2019. [I-D.ietf-idr-tunnel-encaps] - Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The - BGP Tunnel Encapsulation Attribute", draft-ietf-idr- - tunnel-encaps-13 (work in progress), July 2019. + Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel + Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 + (work in progress), December 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, .