Re: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-bgpls-srv6-ext-12: (with COMMENT)

Hi,

I am really happy to see where we are going with this. So far some BGP
implementations do not treat BGP-LS as opaque.

But I have a related question ...

Assume RR is getting BGP-LS from two nodes of an area. How does it choose
the best path before sending to controller/consumer ?

But reading further 7752/7752bis have section called "BGP Next-Hop
Information"

We see there statement:

   In case identical NLRIs are sourced by multiple BGP-LS Producers, the *BGP
Next-Hop attribute* is used to
   tiebreak as per the standard BGP path decision process.

What "attribute" ? The same very section 3.4/5,5 says that next hop is
carried in MP_REACH_NLRI not in separate attribute.

Isn't this a bit confusing ?

Also by tiebreaking do we mean that all steps of best path decision are
skipped ? Do we validate reachability of next hop ? Can the next hop used
be a bgp or igp router_id ?

Many thx,
Robert.

On Thu, Dec 15, 2022 at 3:52 PM Alvaro Retana <aretana.ietf@gmail.com>
wrote:

> On December 15, 2022 at 7:48:19 AM, John Scudder wrote:
>
> > I think that is the right way to think of it. Perhaps an explicit
> statement to
> > that effect would be helpful (maybe it even exists already in 7752, for
> all I
> > know, I haven’t checked).
>
> rfc7752bis has some subtle statements, for example:
>
>    5.2.  The Link-State NLRI
>
>    The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers
>    for carrying opaque information.  This specification defines three
>    Link-State NLRI types that describe either a node, a link, or a
>    prefix.
>
> I'll need to look for more.  In either case, I'll keep this in mind
> when addressing the comments on that draft.
>
> Thanks!
>
> Alvaro.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>