--- 1/draft-ietf-idr-bgp-prefix-sid-21.txt 2018-06-13 11:13:49.956009589 -0700 +++ 2/draft-ietf-idr-bgp-prefix-sid-22.txt 2018-06-13 11:13:49.996010550 -0700 @@ -1,23 +1,23 @@ IDR S. Previdi, Ed. Internet-Draft C. Filsfils Intended status: Standards Track A. Lindem, Ed. -Expires: November 30, 2018 Cisco Systems +Expires: December 15, 2018 Cisco Systems A. Sreekantiah H. Gredler RtBrick Inc. - May 29, 2018 + June 13, 2018 Segment Routing Prefix SID extensions for BGP - draft-ietf-idr-bgp-prefix-sid-21 + draft-ietf-idr-bgp-prefix-sid-22 Abstract The Segment Routing (SR) architecture allows a node to steer a packet flow through any topological path and service chain by leveraging source routing. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SID). Each SID represents a topological or a service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An SR domain is defined as a single administrative domain for global SID @@ -43,21 +43,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 http://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 November 30, 2018. + This Internet-Draft will expire on December 15, 2018. Copyright Notice Copyright (c) 2018 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -93,58 +93,57 @@ 1. Introduction The Segment Routing (SR) architecture leverages the source routing paradigm. A group of inter-connected nodes that use SR forms an SR domain. A segment represents either a topological instruction such as "go to prefix P following shortest path" or a service instruction. Other types of segments may be defined in the future. A segment is identified through a Segment Identifier (SID). An SR domain is defined as a single administrative domain for global SID - assignment. It may be comprised of a single AS or multiple ASes - under consolidated global SID administration. Typically, the ingress - node of the SR domain prepends an SR header containing segments - identifiers (SIDs) to an incoming packet. + assignment. It may be comprised of a single Autonomous System (AS) + or multiple ASes under consolidated global SID administration. + Typically, the ingress node of the SR domain prepends an SR header + containing segments identifiers (SIDs) to an incoming packet. As described in [I-D.ietf-spring-segment-routing], when SR is applied to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the SID consists of a label. [I-D.ietf-spring-segment-routing] also describes how segment routing can be applied to an IPv6 dataplane (SRv6) using an IPv6 routing header containing a stack of SR SIDs encoded as IPv6 addresses [I-D.ietf-6man-segment-routing-header]. The applicability and support for Segment Routing over IPv6 is beyond the scope of this document. A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment attached to a BGP prefix. A BGP Prefix-SID is always a global SID ([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e., the set of Autonomous Systems under a common administration and control and where SR is used) and identifies an instruction to - forward the packet over the ECMP-aware best-path computed by BGP to - the related prefix. The BGP Prefix-SID is the identifier of the BGP - prefix segment. In this document, we always refer to the BGP segment - by the BGP Prefix-SID. + forward the packet over the Equal-Cost Multi-Path (ECMP) best-path + computed by BGP to the related prefix. The BGP Prefix-SID is the + identifier of the BGP prefix segment. In this document, we always + refer to the BGP segment by the BGP Prefix-SID. This document describes the BGP extension to signal the BGP Prefix- SID. Specifically, this document defines a BGP attribute known as the BGP Prefix-SID attribute and specifies the rules to originate, receive, and handle error conditions for the attribute. The BGP Prefix-SID attribute defined in this document can be attached to prefixes from Multiprotocol BGP labeled IPv4/IPv6 Unicast - ([RFC4760], [RFC8277]). Address Family Identifier (AFI)/ Subsequent - Address Family Identifier (SAFI) combinations. - - Usage of the BGP Prefix-SID attribute for other AFI/SAFI combinations - is not defined herein but may be specified in future specifications. + ([RFC4760], [RFC8277]). Usage of the BGP Prefix-SID attribute for + other Address Family Identifier (AFI)/ Subsequent Address Family + Identifier (SAFI) combinations is not defined herein but may be + specified in future specifications. [I-D.ietf-spring-segment-routing-msdc] describes example use cases where the BGP Prefix-SID is used for the above AFI/SAFI combinations. It should be noted that: o A BGP Prefix-SID MAY be global between domains when the interconnected domains agree on the SID allocation scheme. Alternatively, when interconnecting domains, the ASBRs of each domain will have to handle the advertisement of unique SIDs. The @@ -195,22 +194,22 @@ if traffic-engineering within the SR domain is required, each node may be required to advertise its local SRGB in addition to the topological information. This document assumes that BGP-LS is the preferred method for collecting both peer segments (Peer SIDs) and SRGB information through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an optional alternative for the advertisement of the local SRGB without the topology nor the peer SIDs, hence without - applicability for TE, the Originator SRGB TLV of the prefix-SID - attribute is specified in Section 3.2 of this document. + applicability for TE, the Originator SRGB TLV of the BGP Prefix- + SID attribute is specified in Section 3.2 of this document. As defined in [I-D.ietf-spring-segment-routing], the label index L_I is an offset into the SRGB. Each BGP speaker derives its local MPLS label, L, by adding L_I to the start value of its own SRGB, and programs L in its MPLS dataplane as its incoming/local label for the prefix. It should be noted that while SRGBs and SIDs are advertised using 32-bit values, the derived label is advertised in the 20 right-most bits. See Section 4.1 for more details. @@ -305,21 +304,21 @@ | SRGB n (6 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type is 3. o Length is the total length in octets of the value portion of the - TLV: 2 + (multiple of 6). + TLV: 2 + (non-zero multiple of 6). o Flags: 16 bits of flags. None are defined in this document. Flags MUST be clear on transmission and MUST be ignored on reception. o SRGB: 3 octets of base followed by 3 octets of range. Note that the SRGB field MAY appear multiple times. If the SRGB field appears multiple times, the SRGB consists of multiple ranges that are concatenated. @@ -352,25 +351,25 @@ The originator SRGB may only appear in a BGP Prefix-SID attribute attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST be ignored when received for other BGP AFI/SAFI combinations. Since the Label-Index TLV is required for IPv4/IPv6 prefix applicability, the originator SRGB will be ignored if it is not specified consistent with Section 6. 4. Receiving BGP Prefix-SID Attribute - A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP - neighbor residing outside the boundaries of the SR domain MUST - discard the attribute unless it is configured to accept the attribute - from the EBGP neighbor. A BGP speaker SHOULD log an error for - further analysis when discarding an attribute. + A BGP speaker receiving a BGP Prefix-SID attribute from an External + BGP (EBGP) neighbor residing outside the boundaries of the SR domain + MUST discard the attribute unless it is configured to accept the + attribute from the EBGP neighbor. A BGP speaker SHOULD log an error + for further analysis when discarding an attribute. 4.1. MPLS Dataplane: Labeled Unicast A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 Unicast ([RFC8277]) AFI/SAFI is required. The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY contain the Originator SRGB TLV. A BGP Prefix-SID attribute received without a Label-Index TLV MUST be considered as "invalid" by the receiving speaker. @@ -410,23 +409,23 @@ When a BGP speaker receives a path from a neighbor with an "invalid" or "conflicting" BGP Prefix-SID attribute or when a BGP speaker receives a path from a neighbor with a BGP Prefix-SID attribute but is unable to process it (e.g., local policy disables the functionality), it MUST ignore the BGP Prefix-SID attribute. For the purposes of label allocation, a BGP speaker MUST assign a local (also called dynamic) label (non-SRGB) for such a prefix as per classic Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker - MUST follow to the error handling rules specified in Section 6. A - BGP speaker SHOULD log an error for further analysis. In the case of - a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT + MUST follow the error handling rules specified in Section 6. A BGP + speaker SHOULD log an error for further analysis. In the case of a + "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT treat it as error and SHOULD propagate the attribute unchanged. A BGP Speaker SHOULD log a warning for further analysis, i.e., in the case the conflict is not due to a label index transition. When a BGP Prefix-SID attribute changes and transitions from "conflicting" to "acceptable", the BGP Prefix-SID attributes for other prefixes may also transition to "acceptable" as well. Implementations SHOULD assure all impacted prefixes revert to using the label indices corresponding to these newly "acceptable" BGP Prefix-SID attributes. @@ -532,29 +531,29 @@ 1 Label-Index this document 2 Deprecated this document 3 Originator SRGB this document 4-254 Unassigned 255 Reserved this document This document also requests creation of the "BGP Prefix-SID Label- Index TLV Flags" registry under the "Border Gateway Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid. Initially, this 16 bit flags registry will be empty. Flag bits will - be allocated First Come First Served (FCFS) consistent with the BGP- - SID TLV Types registry. + be allocated First Come First Served (FCFS) consistent with the BGP + Prefix-SID TLV Types registry. Finally, this document requests creation of the "BGP Prefix-SID Originator SRGB TLV Flags" registry under the "Border Gateway Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp- prefix-sid. Initially, this 16 bit flags registry will be empty. Flag bits will be allocated First Come First Served (FCFS) consistent - with the BGP-SID TLV Types registry. + with the BGP Prefix-SID TLV Types registry. 8. Manageability Considerations This document defines a BGP attribute to address use cases such as the one described in [I-D.ietf-spring-segment-routing-msdc]. It is assumed that advertisement of the BGP Prefix-SID attribute is controlled by the operator in order to: o Prevent undesired origination/advertisement of the BGP Prefix-SID attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be @@ -644,22 +643,22 @@ [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf-spring-segment-routing-15 (work in progress), January 2018. [I-D.ietf-spring-segment-routing-mpls] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS - data plane", draft-ietf-spring-segment-routing-mpls-13 - (work in progress), April 2018. + data plane", draft-ietf-spring-segment-routing-mpls-14 + (work in progress), June 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, . @@ -709,24 +708,24 @@ Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 (work in progress), May 2018. [I-D.ietf-idr-bgpls-segment-routing-epe] Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", draft-ietf-idr-bgpls-segment-routing- epe-15 (work in progress), March 2018. [I-D.ietf-spring-segment-routing-msdc] - Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. + Filsfils, C., Previdi, S., Dawra, G., Aries, E., and P. Lapukhov, "BGP-Prefix Segment in large-scale data - centers", draft-ietf-spring-segment-routing-msdc-08 (work - in progress), December 2017. + centers", draft-ietf-spring-segment-routing-msdc-09 (work + in progress), May 2018. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions from One External to Another", RFC 5004, DOI 10.17487/RFC5004, September 2007, .