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

Thanks Adrian, I’ll go through them asap.

s.

> On Apr 3, 2017, at 10:13 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
> 
> 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:idr-bounces@ietf.org] 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 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr