Re: [Idr] Martin Duke's No Objection on draft-ietf-idr-bgp-ls-segment-routing-msd-16: (with COMMENT)

[Martin Duke <[e-mail]>]

Bummer! Thanks for the reply.

On Fri, Apr 24, 2020 at 11:55 AM Alvaro Retana <[e-mail]>
wrote:

> On April 24, 2020 at 12:54:53 PM, Martin Duke wrote:
>
>
> Martin:
>
> Hi!
>
>
> > This is not a DISCUSS-level concern, but I found it odd that the Node
> MSD TLV
> > must be the minimum of all configured interfaces without regard for the
> > presence of any Link MSD TLVs.
> >
> > For example, if all node interfaces have an MSD of 20 except one with an
> MSD
> > of 10, it would be much more compact to advertise a Node MSD of 20 and a
> > single Link MSD of 10. Section 5 says the Link MSD would take
> precedence, so
> > there would be no information loss. As I understand the spec, this would
> not
> > be allowed, and each link would have to be advertised separately to gain
> that
> > level of granularity.
> >
> > If this is not the intent, then in Section 3, extending a sentence to say
> > "Node MSD is the smallest MSD supported by the node on the set of
> interfaces
> > configured for use, [excepting links advertised with their own Link MSD
> TLV]"
> > would avoid the problem.
>
> This could have been a good optimization.
>
> However, this ship has sailed.  BGP-LS is a mechanism to carry
> topology related information to a central controller.  This
> information, as in this case, is obtained from the IGPs (OSPF or
> IS-IS).  IOW, BGP-LS is simply carrying the same information that
> IS-IS/OSPF generated...with the same semantics, which is what the
> controller is expecting.  The corresponding IGP specifications
> (rfc8491/rfc8476) contain the same language...if we change this
> document then we would have to change the IGP documents...and all the
> implementations. :-(
>
> Thanks!
>
> Alvaro.
>