--- 1/draft-ietf-idr-bgp-prefix-sid-15.txt 2018-02-13 20:13:09.808771562 -0800 +++ 2/draft-ietf-idr-bgp-prefix-sid-16.txt 2018-02-13 20:13:09.848772518 -0800 @@ -1,23 +1,23 @@ IDR S. Previdi, Ed. Internet-Draft C. Filsfils Intended status: Standards Track A. Lindem -Expires: August 16, 2018 Cisco Systems +Expires: August 17, 2018 Cisco Systems A. Sreekantiah H. Gredler RtBrick Inc. - February 12, 2018 + February 13, 2018 Segment Routing Prefix SID extensions for BGP - draft-ietf-idr-bgp-prefix-sid-15 + draft-ietf-idr-bgp-prefix-sid-16 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. @@ -41,21 +41,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 August 16, 2018. + This Internet-Draft will expire on August 17, 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 @@ -424,45 +424,45 @@ The mechanisms through which a given label index value is assigned to a given prefix are outside the scope of this document. Given a label index L_I, we refer to (L = L_I + SRGB_Start) as the derived label. A BGP Prefix-SID attribute is designated "conflicting" for a speaker M if the derived label value L lies outside the SRGB configured on M. Otherwise the Label-Index TLV is designated "acceptable" to speaker M. If multiple different prefixes are received with the same label - index, all these but one of these different prefixes MUST have their - BGP Prefix-SID attribute considered as "conflicting" by the receiving - speaker. Alternately, all the different prefixes with the same label - index MAY be considered "conflicting". + index, either all or all but one of the different prefixes MUST have + their BGP Prefix-SID attribute considered as "conflicting". If one + of the different prefixes is considered "acceptable", it is + RECOMMENDED that the first prefix using the label index is selected. If multiple valid paths for the same prefix are received from multiple BGP speakers or, in the case of [RFC7911], from the same BGP speaker, and the BGP Prefix-SID attributes do not contain the same label index, then the label index from the best path BGP Prefix-SID - attribute SHOULD be chosen. + attribute SHOULD be chosen with a notable exception being when + [RFC5005] is being used to dampen route changes. When a BGP speaker receives a path from a neighbor with an "acceptable" BGP Prefix-SID attribute and that path is selected as the best path, it SHOULD program the derived label as the label for the prefix in its local MPLS dataplane. 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 (it does not have the capability or local - policy disables the capability), 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. + 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 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 @@ -480,43 +480,44 @@ when forwarding traffic to the prefix. The label NLRI defines the outbound label that MUST be used by the receiving node. 4.2. IPv6 Dataplane When an SR IPv6 BGP speaker receives an IPv6 Unicast BGP Update with a prefix having the BGP Prefix-SID attribute attached, it checks whether the IPv6 SID TLV is present and "acceptable". If multiple different prefixes are received with the same IPv6 SID, - all these but one of these different prefixes MUST have their BGP - Prefix-SID attribute considered as "conflicting" by the receiving - speaker. Alternately, all the different prefixes with the same IPv6 - SID MAY be considered "conflicting". + either all or all but one of the different prefixes MUST have their + BGP Prefix-SID attribute considered as "conflicting". If one of the + different prefixes is considered "acceptable", it is RECOMMENDED that + the first prefix using the IPv6 SID is selected. If multiple valid paths for the same prefix are received from multiple BGP speakers or, in the case of [RFC7911], from the same BGP speaker, and the BGP Prefix-SID attributes do not contain the same IPv6 SID, then the IPv6 SID from the best path BGP Prefix-SID - attributes SHOULD be chosen. + attribute SHOULD be chosen with a notable exception being when + [RFC5005] is being used to dampen route changes. If "acceptable" and chosen as the best path, the prefix is installed into the Segment Routing IPv6 dataplane as described in [I-D.ietf-spring-segment-routing]. 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 (it does not have the capability or local - policy disables the capability), it MUST ignore the BGP Prefix-SID - attribute and revert to [RFC2545] and [RFC4271]. Consistent with the - MPLS dataplane Section 4.1, a BGP speaker SHOULD log the condition - for further analysis. + is unable to process it (e.g, local policy disables the + functionality), it MUST ignore the BGP Prefix-SID attribute and + revert to [RFC2545] and [RFC4271]. Consistent with the MPLS + dataplane Section 4.1, a BGP speaker SHOULD log the condition for + further analysis. 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 IPv6 SIDs corresponding to these newly "acceptable" BGP Prefix- SID attributes. The Label-Index and Originator SRGB TLVs MUST be ignored on reception. For future extensibility, no TLVs are required for the @@ -803,20 +804,24 @@ Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", draft-ietf-idr-bgpls-segment-routing- epe-14 (work in progress), December 2017. [I-D.ietf-spring-segment-routing-msdc] Filsfils, C., Previdi, S., Mitchell, J., 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. + [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, + DOI 10.17487/RFC5005, September 2007, . + [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . Authors' Addresses Stefano Previdi (editor) Cisco Systems