Skip to main content

Segment Routing Prefix Segment Identifier Extensions for BGP
draft-ietf-idr-bgp-prefix-sid-27

Yes


No Objection

(Alexey Melnikov)
(Ben Campbell)
(Deborah Brungard)
(Ignas Bagdonas)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 21 and is now closed.

Warren Kumari
No Objection
Comment (2018-06-18 for -25) Unknown
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.
"
Alvaro Retana Former IESG member
Yes
Yes (2018-06-12 for -21) Unknown
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
Adam Roach Former IESG member
(was Discuss) No Objection
No Objection (2018-06-21 for -25) Unknown
Thanks to Alvaro for clearing up my confusion about the scope of the changes in the document.
Alexey Melnikov Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2018-06-20 for -25) Unknown
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.
Ben Campbell Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2018-06-19 for -25) Unknown
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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2018-06-20 for -25) Unknown
Thanks for addressing my comments.
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (2018-06-21 for -25) Unknown
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
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-06-18 for -25) Unknown
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...
Spencer Dawkins Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -25) Unknown