Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6 to 3/20/2017 - extending to 3/31

["Adrian Farrel" <[e-mail]>]

Hi Sue, WG,
 
Yes, sorry for not getting to this the first time around.
 
It's a good piece of work that needs to be standardised, and this document is
ready modulo the relatively small comments below.
 
Thanks,
Adrian
 
 
=== Code point stuff ===
 
I thought we had some fairly good clue in IDR about not "suggesting"
code point values, but in section 4 I found...
 
   The BGP Prefix SID attribute is an optional, transitive BGP path
   attribute.  The attribute type code is to be assigned by IANA
   (suggested value: 40).
 
As it turns out, an early allocation has been done and is recorded in
section 8. So this text should read...
 
   The BGP Prefix SID attribute is an optional, transitive BGP path
   attribute.  The attribute type code 40 has been assigned by IANA
   (see Section 8).
 
 
=== Rambling Thoughts ===
 
Section 4.2
 
      *  S flag: if set then it means that the BGP speaker attaching the
         Prefix-SID Attribute to a prefix is capable of processing the
         IPv6 Segment Routing Header (SRH,
         [I-D.ietf-6man-segment-routing-header]) for the segment
         corresponding to the originated IPv6 prefix.  The use case
         leveraging the S flag is described in
         [I-D.ietf-spring-segment-routing-msdc].
 
Suppose that sometime in the future a third type of SID processing is
defined. Well, you'd burn a new bit, say the X bit, to indicate the
support of that method. But how would you set the S bit in that case?
So, perhaps you need two bits already.
 
 
=== Minor ===
 
Odd to reference draft-ietf-6man-segment-routing-header but not
draft-ietf-spring-segment-routing-mpls.
 
---
 
I think draft-ietf-spring-segment-routing and draft-ietf-spring-segment-
routing-msdc are normative references based both on the importance as
background material and the text in the first paragraph of the document.
 
The material in Section 1 suggests that draft-ietf-spring-segment-
routing-central-epe and draft-ietf-idr-bgpls-segment-routing-epe might
also be normative references.
 
---
 
The RFC Editor will require that the first section of the document is
the "Introduction".  I think you fix this by moving the current Section
1 to be a sub-section of the current Section 2.
 
---
 
I wish we (or the SPRING WG) would nail down the terminology of a
"segment" and a "segment identifier." This muddiness is just not
necessary, but is perpetrated by this document saying that
  The ingress node of the SR domain prepends a (sic) SR
  header containing "segments" to an incoming packet.
but then saying that
  Each segment is identified by a Segment Identifier (SID).
So, in fact, the SR header contains SIDs not segments.
 
This confusions is continued by
  Each segment represents a topological instruction
Do segments *represent* topological instructions or are they
topological instruction?
 
---
 
Section 2 has...
   A BGP-Prefix-SID is always global within the SR/BGP domain
While this language is clear from the referenced documents, it is not
very clear in this document. I think you need to say ...
   A BGP-Prefix-SID is always a global SID [I-D.ietf-spring-segment-
   routing] within the SR/BGP domain
...although (of course) draft-ietf-spring-segment-routing talks about
global segments but not global SIDs except in 3.1.3 where the mention
is a little without context.
 
---
 
Section 3.1 has...
      While it is recommended to use the same SRGB across
      all the nodes within the SR domain, the SRGB of a node is a local
      property and could be different on different speakers.
I *think* that this recommendation comes from the referenced document
[I-D.ietf-spring-segment-routing] and not from this current document.
This would be clearer by writing...
      While [I-D.ietf-spring-segment-routing] recommends to use the same
      SRGB across all the nodes within the SR domain, the SRGB of a node
      is a local property and could be different on different speakers.
Doing this will stop questions about whether "recommended" is supposed
to be in 2119 upper case.
 
---
 
In 3.1...
 
      The index L_I is a 32 bit offset in 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.
 
Is this right or is L_I, as defined in draft-ietf-spring-segment-
routing-mpls, a 20 bit offset into a reduced 20-bit space out of the 32-
bit SID space?
 
FWIW, this section is another place I would have expected to see a
reference to draft-ietf-spring-segment-routing-mpls.
 
---
 
First para of section 4 ends...
 
   The value field of the BGP-Prefix-SID
   attribute has the following format:
 
Is there supposed to be a figure here? The next paragraph doesn't seem
to flow. Maybe this sentence can be deleted.
 
---
 
4.2
Are you sure you don't want a registry for flags?
 
---
 
5.1
   A BGP speaker may be locally configured with an SRGB=[GB_S, GB_E].
Probably "MAY"?
I think that the notation needs some small explanation.
 
---
 
5.1
   The Label Index gives a hint to the receiving node on which
   local/incoming label the BGP speaker SHOULD use.
 
This is like a double SHOULD: "hint" and "SHOULD use".
It might be helpful to describe the potential variance.
 
---
 
6.
   In order to
   prevent distribution of the BGP Prefix-SID attribute beyond its
   intended scope of applicability, attribute filtering MAY be deployed.
 
Yeah. That's OK, but the language implies there are other ways to prevent
distribution beyond the intended scope.
 
---
 
7.
   all the occurrences of
   the attribute other than the first one SHALL be discarded and the BGP
   Update message shall continue to be processed.
 
I think the second "shall" is a "SHALL" as well.
 
 
 
=== Nits ===
 
The authors need to sort out their affiliations and email addresses.
 
---
 
The AD will probably not be happy with 7 names on the front page.
 
---
 
3.1
s/This informations/This information/
 
---
 
4.1 and 4.3
s/None are/None is/
 
---
 
5.2
   When a SR IPv6 BGP speaker receives a IPv6 Unicast BGP Update with
s/a/an/ x2
 
---
 
6.
s/[RFC3107]or/[RFC3107] or/
 
---
 
6.1
s/([RFC3107])The/([RFC3107]).  The/
 
---
 
Section 11 might possibly be of no value.
 
From: Idr [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: 21 March 2017 16:53
To: 'idr wg'
Subject: Re: [Idr] 2 Week WG LC for draft-ietf-idr-bgp-prefix-sid-04.txt - 3/6
to 3/20/2017 - extending to 3/31
 
IDR WG: 
 
Perhaps the WG LC came at a bad time since have received only 1 response.  We
will length the call to 3/31.  Unless with have substantial input, this WG LC
will not indicate consensus. 
 
Sue Hares