Segment Routing Prefix SID extensions for BGP
draft-ietf-idr-bgp-prefix-sid-27

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

Alvaro Retana Yes

Comment (2018-06-12 for -21)
No email
send info
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

Ignas Bagdonas No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

Comment (2018-06-20 for -25)
No email
send info
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.

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-06-19 for -25)
No email
send info
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.

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-06-18 for -25)
No email
send info
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.
"

Mirja K├╝hlewind No Objection

Comment (2018-06-18 for -25)
No email
send info
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...

(Terry Manderson) No Objection

Alexey Melnikov No Objection

(Eric Rescorla) No Objection

Comment (2018-06-20 for -25)
No email
send info
Thanks for addressing my comments.

Adam Roach (was Discuss) No Objection

Comment (2018-06-21 for -25)
No email
send info
Thanks to Alvaro for clearing up my confusion about the scope of the changes in the document.

Martin Vigoureux No Objection

Comment (2018-06-21 for -25)
No email
send info
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