Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-msd-09

[Jeff Tantsura <[e-mail]>]

Dear Alvaro,

Many thanks for your thorougful review!
Please see inline

Cheers,
Jeff
On Feb 26, 2020, 2:19 PM -0800, Alvaro Retana <[e-mail]>, wrote:
> Dear authors:
>
> This is my review of draft-ietf-idr-bgp-ls-segment-routing-msd-09.  I
> have put some comments in-line below which should be easy to address.
>
> This document, like many other BGP-LS specifications to carry
> IGP-derived information is written with that assumption: that the
> information will come from the IGPs.  However, §2 reads:
>
>     The BGP-LS speaker may also advertise the MSD information for the local
>     node and its links when not running any link-state IGP protocol e.g. when
>     running BGP as the only routing protocol.
>
> This case (no IGP) is not fully explained in the text.  Borrowing from
> the IGP RFCs, two clear pieces of information that are missing are:
>
>    (1) A definition of what the Node/Link MSDs are.  I borrowed from rfc8476
>    and made suggestions for §3 and §4 of this document (in-line).
>
>    (2) "Procedures for Defining and Using Node and Link MSD Advertisements",
>    similar to §4 (in both rfc8476/rfc8491).  Suggestion: simply include the
>    text from rfc8476 after §4 of this document.
[jeff]Ack
>
>
> The text in §2 is also not specific on how this local information
> should be advertised using BGP-LS.  Should the Direct Protocol
> Identifier be used, or, because of "running BGP as the only routing
> protocol" should it be BGP?  Please add details to the specification.
[jeff] Ack, it is BGP
>
> One more related point.  The deployment model for collecting
> IGP-derived information is that "BGP-LS is configured on a small
> number of nodes" [rfc8491], but the model for advertising local
> information is different.  Please include some text about that too.
>
>
> I will wait for a revised document to primarily address this text from
> §2 (and the in-line comments marked as [major]) before starting the
> IETF LC.
>
> Thanks!
>
> Alvaro.
>
>
>
> [Line numbers from idnits.]
>
> ...
> 14 Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-
> 15                                 State
>
> [minor] s/Border Gateway Protocol Link-State/Border Gateway Protocol -
> Link State/g
> That is the form used in rfc7752 -- in the only place where BGP-LS is expanded.
[jeff]Ack
>
>
> ...
> 79 1.  Introduction
>
> 81   When Segment Routing (SR) [RFC8402] paths are computed by a
> 82   centralized controller, it is critical that the controller learns the
> 83   Maximum SID Depth (MSD) that can be imposed at each node/link on a
> 84   given SR path.  This ensures that the Segment Identifier (SID) stack
> 85   depth of a computed path doesn't exceed the number of SIDs the node
> 86   is capable of imposing.
>
> [nit] s/learns/learn
[jeff]Ack
>
>
>
> ...
> 93   However, if PCEP is not supported/configured on the head-end of a SR
> 94   tunnel or a Binding-SID anchor node, and controller does not
> 95   participate in IGP routing, it has no way of learning the MSD of
> 96   nodes and links.  BGP-LS [RFC7752] defines a way to advertise
> 97   topology and associated attributes and capabilities of the nodes in
> 98   that topology to a centralized controller.  This document defines
> 99   extensions to BGP-LS to advertise one or more types of MSDs at node
> 100   and/or link granularity.
>
> [nit] s/to advertise/to expose
> For consistency with the OSPF/ISIS documents.
>
>
> [minor] Including the last sentence above makes the text not flow
> well: it first says that extensions "to advertise one or more types of
> MSDs" are defined here...and then it talks about other types of MSDs.
> Suggestion:  Move that sentence to be the first one in the last
> paragraph.
[jeff]Ack
>
>
>
> 102   Other types of MSD are known to be useful.  For example,
> 103   [I-D.ietf-ospf-mpls-elc] and [I-D.ietf-isis-mpls-elc] define Readable
> 104   Label Depth Capability (RLDC) that is used by a head-end to insert an
> 105   Entropy Label (EL) at a depth that can be read by transit nodes