--- 1/draft-ietf-bess-nsh-bgp-control-plane-10.txt 2019-05-30 07:15:33.510937426 -0700 +++ 2/draft-ietf-bess-nsh-bgp-control-plane-11.txt 2019-05-30 07:15:33.626940359 -0700 @@ -1,24 +1,24 @@ BESS Working Group A. Farrel Internet-Draft Old Dog Consulting Intended status: Standards Track J. Drake -Expires: October 28, 2019 E. Rosen +Expires: December 1, 2019 E. Rosen Juniper Networks J. Uttaro AT&T L. Jalil Verizon - April 26, 2019 + May 30, 2019 BGP Control Plane for NSH SFC - draft-ietf-bess-nsh-bgp-control-plane-10 + draft-ietf-bess-nsh-bgp-control-plane-11 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,21 +38,21 @@ 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 October 28, 2019. + This Internet-Draft will expire on December 1, 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 @@ -97,45 +97,45 @@ 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 35 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 35 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 36 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 38 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 38 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 39 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 39 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 40 - 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 40 + 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 41 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 41 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 42 - 8.9. Examples of SFPs with Stateful Service Functions . . . . 42 + 8.9. Examples of SFPs with Stateful Service Functions . . . . 43 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 43 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 44 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 46 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 48 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 52 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 52 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 52 10.4. New SFP Association Type Registry . . . . . . . . . . . 53 10.5. New Service Function Type Registry . . . . . . . . . . . 54 10.6. New Generic Transitive Experimental Use Extended Community Sub-Types . . . . . . . . . . . . . . . . . . 55 10.7. New BGP Transitive Extended Community Types . . . . . . 55 10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 55 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 13.1. Normative References . . . . . . . . . . . . . . . . . . 56 13.2. Informative References . . . . . . . . . . . . . . . . . 57 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 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 maintaining service function chaining in production networks, which @@ -722,40 +722,44 @@ 3. Unknown TLV type field found in SFP attribute. 4. TLV length that suggests the TLV extends beyond the end of the SFP attribute. 5. Association TLV contains an unknown SFPR-RD. 6. No Hop TLV found in the SFP attribute. - 7. No SFT TLV found in a Hop TLV. + 7. No sub-TLV found in a Hop TLV. 8. Unknown SFIR-RD found in a Hop TLV. o The errors listed above are treated as follows: 1., 2., 6., 7.: The attribute MUST be treated as malformed and the "treat-as-withdraw" approach used as per [RFC7606]. 3.: Unknown TLVs SHOULD be ignored, and message processing SHOULD continue. 4.: Treated as a malformed message and the "treat-as-withdraw" approach used as per [RFC7606] - 5., 8.: The absence of an RD with which to corollate is nothing + 5., 8.: The absence of an RD with which to correlate is nothing more than a soft error. The receiver SHOULD store the information from the SFP attribute until a corresponding advertisement is received. An implementation MAY time-out such - stored SFP attributes to avoid becoming over-loaded. + stored SFP attributes to avoid becoming over-loaded. The time- + out value should be configurable and measured in minutes; a + default value of 30 minutes is suggested. Whenever an + implementation removes a stored SFP attribute, it SHOULD + generate a notification to the network operator. 3.2.1.1. The Association TLV 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) | @@ -893,25 +897,25 @@ 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.4. MPLS Swapping/Stacking TLV 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.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. + 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 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. @@ -1466,54 +1470,59 @@ Functions in such environments requires that suitable identifiers are used to ensure that SFFs distinguish which SFIs can be used and which cannot. This problem is similar to how VPNs are supported and is solved in a similar way. The RT field is used to indicate a set of Service Functions from which all choices must be made. 7.4. Flow Spec for SFC Classifiers - [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. + [RFC5575] and [I-D.ietf-idr-rfc5575bis] define 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 these 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 MUST NOT be present at the same time: the + inclusion of the "Flow Spec for SFC Classifiers" action extended + community along with any other action MUST be treated as an error + which SHOULD result in the Flow Specification UPDATE message being + handled as Treat-as-withdraw according to [RFC7606] Section 2. This extended community is encoded as an 8-octet value, as shown in - Figure 10: + 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 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 - multiple of these action extended communities, and that if a given - action extended community does not contain an installed SFPR with the - specified {SPI, SI, SFT} it MUST NOT be used for dispositioning the - packets of the specified flow. + Note that a given Flow Spec update according to [RFC5575] and + [I-D.ietf-idr-rfc5575bis] may include multiple of these action + extended communities, and that if a given action extended community + does not contain an installed SFPR with the specified {SPI, SI, SFT} + it MUST NOT be used for dispositioning the packets of the specified + flow. The normal case of packet classification for SFC will see a packet enter the SFP at its first hop. In this case the SI in the extended community is superfluous and the SFT may also be unnecessary. To allow these cases to be handled, a special meaning is assigned to a Service Index of zero (not a valid value) and an SFT of zero (a reserved value in the registry - see Section 10.5). o If an SFC Classifiers Extended Community is received with SI = 0 then it means that the first hop of the SFP indicated by the SPI @@ -1523,23 +1532,25 @@ 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 to put the - indicated SPI into context. + 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 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]. @@ -1959,21 +1970,21 @@ to SFF2. This is safe, even in the case that the SFs of type 42 are stateful because SFF2 is doing the load balancing in both directions and can apply the same algorithm to ensure that packets associated 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 bidirecitonal SFPs. + 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 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], @@ -2268,21 +2279,21 @@ Section 19 of [RFC7432] also provides useful guidance on the use of BGP in a similar environment. Note that a component of an SFC system that uses the procedures described in this document also requires communications between a controller and the SFC network elements. This communication covers instructing the Classifiers using BGP mechanisms (see Section 7.4) which is covered by BGP security. But it also covers other mechanisms for programming the Classifier and instructing the SFFs and SFs (for example, to bind SFs to an SFF, and to cause the - estblishment of tunnels between SFFs). This document does not cover + establishment of tunnels between SFFs). This document does not cover these latter mechanisms and so their security is out of scope, but it should be noted that these communications provide an attack vector on the SFC system and so attention must be paid to ensuring that they are secure. 10. IANA Considerations 10.1. New BGP AF/SAFI IANA maintains a registry of "Address Family Numbers". IANA is @@ -2457,24 +2468,29 @@ 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. 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-15 (work in progress), May 2019. + [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. + Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The + BGP Tunnel Encapsulation Attribute", draft-ietf-idr- + tunnel-encaps-12 (work in progress), May 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-07 (work in progress), March 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-04 (work in progress), March