--- 1/draft-ietf-bess-nsh-bgp-control-plane-11.txt 2019-08-20 05:13:40.616894867 -0700 +++ 2/draft-ietf-bess-nsh-bgp-control-plane-12.txt 2019-08-20 05:13:40.728897699 -0700 @@ -1,24 +1,24 @@ BESS Working Group A. Farrel Internet-Draft Old Dog Consulting Intended status: Standards Track J. Drake -Expires: December 1, 2019 E. Rosen +Expires: February 21, 2020 E. Rosen Juniper Networks J. Uttaro AT&T L. Jalil Verizon - May 30, 2019 + August 20, 2019 BGP Control Plane for NSH SFC - draft-ietf-bess-nsh-bgp-control-plane-11 + draft-ietf-bess-nsh-bgp-control-plane-12 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 December 1, 2019. + This Internet-Draft will expire on February 21, 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 @@ -77,65 +77,65 @@ 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 in Service Function Paths . . . . . . . . . . . . . 27 + 5. Selection within Service Function Paths . . . . . . . . . . . 27 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 29 6.1. Protocol Control of Looping, Jumping, and Branching . . . 29 6.2. Implications for Forwarding State . . . . . . . . . . . . 30 - 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 30 - 7.1. Correlating Service Function Path Instances . . . . . . . 30 - 7.2. Considerations for Stateful Service Functions . . . . . . 31 - 7.3. VPN Considerations and Private Service Functions . . . . 32 + 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 . . . . . . . . . . 35 + 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 36 - 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 35 + 7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 36 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 36 - 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37 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.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 39 + 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 40 + 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 40 + 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 41 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.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 42 + 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 43 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 + 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 44 + 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 45 + 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 47 + 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 49 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 + 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 53 + 10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 53 + 10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 53 + 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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 58 + 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 + 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 maintaining service function chaining in production networks, which @@ -588,22 +588,22 @@ 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. + described in [RFC8595]. Each label is 20 bits encoded in a 3-octet + (24 bit) field with 4 trailing bits that MUST be set to zero. +--------------------------------------------+ | Type = TBD7 (1 octet) | +--------------------------------------------| | Sub-Type = 0x00 (1 octet) | +--------------------------------------------| | SFC Context Label (3 octets) | +--------------------------------------------| | SF Label (3 octets) | +--------------------------------------------+ @@ -740,26 +740,21 @@ 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 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. 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. + advertisement is received. 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) | @@ -1194,21 +1189,21 @@ 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 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 +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, 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 these, identify the SFF that supports the chosen SFI, and send the packet to that next hop SFF. The choice be may offered for load balancing across multiple SFIs, or @@ -1278,20 +1273,28 @@ Each of the relevant SFIRs identifies a single SFI, and contains a Tunnel Encapsulation attribute that specifies how to send a packet to that SFI. For a particular packet, the SFF chooses a particular SFI from the set of relevant SFIRs. This choice is made according to 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 + 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. Section 2 also describes how an SFI or an SFF may cause a packets to "jump forward" to an SF on a path that is not the immediate next SF @@ -1546,21 +1549,21 @@ 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]. + MPLS labels [RFC8595]. This document defines a new sub-TLV for the Tunnel Encapsulation attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub- TLV MAY be present in each Tunnel TLV contained in a Tunnel Encapsulation attribute when the attribute is carried by an SFIR. The value field of this sub-TLV is a two octet field of flags, each of which describes how the originating SFF expects to see the SPI/SI represented in the data plane for packets carried in the tunnels described by the Tunnel TLV. @@ -1597,21 +1600,21 @@ NSH itself). It is a requirement that both ends of a tunnel over the underlay network know that the tunnel is used for SFC and know what form of NSH representation is used. The signaling mechanism described here allows coordination of this information. 7.5.1. MPLS Representation of the SPI/SI If bit 1 is set in the in the SPI/SI Representation sub-TLV then labels in the MPLS label stack are used to indicate SFC forwarding and processing instructions to achieve the semantics of a logical - NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc]. + NSH. The label stack is encoded as shown in [RFC8595]. 7.6. MPLS Label Swapping/Stacking Operation When a classifier constructs an MPLS label stack for an SFP it starts with that SFP' last hop. If the last hop requires an {SPI, SI} label pair for label swapping, it pushes the SI (set to the SI value of the last hop) and the SFP's SPI onto the MPLS label stack. If the last hop requires a {context label, SFI label} label pair for label stacking it selects a specific SFIR and pushes that SFIR's SFI label and context label onto the MPLS label stack. @@ -1622,29 +1625,28 @@ the SI value of the current hop. If there is not an {SPI, SI} at the top of the MPLS label stack, it pushes the SI (set to the SI value of the current hop) and the SFP's SPI onto the MPLS label stack. If the hop requires a {context label, SFI label}, it selects a specific SFIR and pushes that SFIR's SFI label and context label onto the MPLS label stack. 7.7. Support for MPLS-Encapsulated NSH Packets - [I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC - packets using the NSH over an MPLS transport network. Signaling MPLS - encapsulation of SFC packets using the NSH is also supported by this - document by using the "BGP Tunnel Encapsulation Attribute Sub-TLV" - with the codepoint 10 (representing "MPLS Label Stack") from the "BGP - Tunnel Encapsulation Attribute Sub-TLVs" registry defined in - [I-D.ietf-idr-tunnel-encaps], and also using the "SFP Traversal With - MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" with - bit 0 set and bit 1 cleared. + [RFC8596] describes how to transport SFC packets using the NSH over + an MPLS transport network. Signaling MPLS encapsulation of SFC + packets using the NSH is also supported by this document by using the + "BGP Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10 + (representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation + Attribute Sub-TLVs" registry defined in [I-D.ietf-idr-tunnel-encaps], + and also using the "SFP Traversal With MPLS Label Stack TLV" and the + "SPI/SI Representation sub-TLV" with bit 0 set and bit 1 cleared. In this case the MPLS label stack constructed by the SFF to forward a packet to the next SFF on the SFP will consist of the labels needed to reach that SFF, and if label stacking is used it will also include the labels advertised in the MPLS Label Stack sub-TLV and the labels remaining in the stack needed to traverse the remainder of the SFP. 8. Examples Assume we have a service function overlay network with four SFFs @@ -2471,37 +2473,27 @@ 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. + draft-ietf-idr-rfc5575bis-17 (work in progress), June + 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-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 - 2019. + tunnel-encaps-13 (work in progress), July 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, . @@ -2542,20 +2534,31 @@ [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, . + [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based + Forwarding Plane for Service Function Chaining", RFC 8595, + DOI 10.17487/RFC8595, June 2019, + . + + [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, + "MPLS Transport Encapsulation for the Service Function + Chaining (SFC) Network Service Header (NSH)", RFC 8596, + DOI 10.17487/RFC8596, June 2019, + . + 13.2. Informative References [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, . Authors' Addresses Adrian Farrel