Ballot for draft-ietf-idr-bgp-prefix-sid
Yes
No Objection
Note: This ballot was opened for revision 21 and is now closed.
I'm balloting NoObjection, but I'm sad that nothing came of my previous request: "Major(ish) issue: Section 5. Advertising BGP Prefix-SID Attribute "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760]. In order to prevent distribution of the BGP Prefix-SID attribute beyond its intended scope of applicability, attribute filtering SHOULD be deployed." Thank you for including this -- however, as I'm sure you know, the state of BGP filtering in the wild is, er, poor. Can you please provide some additional guidance? For example, could you include an appendix with examples? Or simply a bit more text on determining the scope of applicability? Apologies if I missed this, but should this by default be filtered on eBGP sessions? The included text is a great start, but some more (so people don't miss it and shoot themselves in the foot would be much appreciated. "
Note to the IESG: This is a returning document. It went through IESG Evaluation and was approved at the Feb 8, 2018 Telechat. After approval (version -16 addressed any remaining Telechat comments), the authors proposed significant changes to the content of the document to remove support for the IPv6 SID due to lack of implementation and support [1]. The document went again through WG and IETF LCs. Note that the IPv6-specific work is being addressed in a different document. For your convenience, here are the diffs: https://www.ietf.org/rfcdiff?url1=draft-ietf-idr-bgp-prefix-sid-16&url2=draft-ietf-idr-bgp-prefix-sid-21 [1] https://mailarchive.ietf.org/arch/msg/idr/FM31nSL78B5L5yCBZB17NfLwQy4/?qid=7f0a07c88788f56211e8702176812f8e
Thanks to Alvaro for clearing up my confusion about the scope of the changes in the document.
Abstract: "This document defines an optional, transitive BGP attribute for announcing BGP Prefix Segment Identifiers (BGP Prefix-SID) information the specification for SR-MPLS SIDs." This is a sentence fragment. IANA considerations: "Currently, IANA temporarily assigned the following: 40 BGP Prefix-SID (TEMPORARY - registered 2015-09-30, expires 2016-09-30) [draft-ietf-idr-bgp-prefix-sid]" I'm not sure that this needs to stay in the document, but if it does, it shouldn't say "currently" (since that won't be true for long) and the dates should be updated to reflect the fact that the temporary registration was extended a couple of times, until 09-30-2018.
Please expand NLRI on first use. The "MUST be present" (in BGP Prefix-SID) in Section 3.1 seems to potentially be in conflict with the "are only used when SR is applied to the MPLS dataplane" in Section 3, but it's quite possible that I'm just missing the piece that ties things together. Section 7 It's a little weird to mark the value 2 as "deprecated" with reference "this document" but not have the previous usage described at all in the final version. Section 9 It might be nice to note the consequences of the BGP Prefix-SID attribute's non-protection by BGPsec signatures, though thank you for calling out the lack of coverage.
Thanks for addressing my comments.
Hello, thank you for this Document. I have few comments: Abstract: references to "service chain" were removed from SPRING originated documents. Should we do the same here? 1. Introduction It looks to me that these two definitions are not identical. Should only one be kept? A group of inter-connected nodes that use SR forms an SR domain. An SR domain is defined as a single administrative domain for global SID assignment. On that matter, I am not sure it is worth restating a definition further down "(i.e., the set of Autonomous Systems under a common administration and control and where SR is used)" Aren't these two sentences somehow in conflict (i.e. "always global" Vs. "MAY be global"): A BGP Prefix-SID is always a global SID ([I-D.ietf-spring-segment-routing]) within the SR domain A BGP Prefix-SID MAY be global across ASes when the interconnected ASes agree on the SID allocation scheme. I make the assumption that "interconnected ASes" which "agree on the SID allocation scheme" form an SR domain, but I may be wrong. s/we always refer to the BGP segment by the BGP Prefix-SID/we always refer to the BGP-Prefix segment by the BGP Prefix-SID/ ? A BGP Prefix-SID MAY be attached to a prefix. Do you mean a "A Prefix-SID MAY be attached to a BGP-Prefix" or do you mean "A BGP Prefix-SID attribute MAY be attached to a BGP IPv4/IPv6 Label Unicast prefix" ? I would say the latter but that sentence: "A BGP-Prefix Segment is a BGP prefix with a Prefix-SID attached" (found couple of paragraphs above) makes me doubt. 3.1. Label-Index TLV It MUST be ignored when received for other BGP AFI/SAFI combinations. Is that constraint needed? I am asking because in the Introduction you seem to at least allow for other AFI/SAFI to use the BGP Prefix-SID. 3.2. Originator SRGB TLV Same comment as above this time for the Originator SRGB TLV s/The originator SRGB/The Originator SRGB TLV/ (twice) 7. IANA Considerations This document defines 3 TLVs for the BGP Prefix-SID attribute. I guess that's a leftover from the IPv6 years. I only see two TLVs defined. 2 Deprecated this document Would it be worth to document why this is indicated as being deprecated? I understand that this was assigned to IPv6 SID TLV in earlier versions of the Document and that the Document now leaves v6 oos, but I guess it wouldn't hurt to have a couple of sentences. Thank you
Minor, no critical comment: I still don't really see why reserved bits and flags are needed given they are both defined the same way ("MUST be clear on transmission and MUST be ignored on reception."). Or more generally, I don't see at all why a flags field is needed given you can also just always create a new TLV...