Re: [Idr] WGLC is for "BGP Router Capabilities Attribute” [was: Re: WG LC for draft-ietf-idr-entropy-09 (8/29 to 9/12/2023)]

[Kaliraj Vairavakkalai <[e-mail]>]

> My speculation is that if IDR adopts the multi-next-hop work, it would be appropriate to include something like the work in draft-ietf-idr-entropy as part of the multi-next-hop proposal.  I.e., the two pieces of state should be tightly coupled into a single path attribute.

Pls see https://www.ietf.org/archive/id/draft-kaliraj-idr-multinexthop-attribute-09.html#section-5.4.3.1

MNH does include EL capability tightly coupled per nexthop leg in the same attribute.
So the ELCv3 does not need to apply to the MNH. If that was the question being asked.

Thanks
Kaliraj





Juniper Business Use Only
From: Idr <[e-mail]> on behalf of Jeffrey Haas <[e-mail]>
Date: Thursday, September 7, 2023 at 2:31 PM
To: Robert Raszuk <[e-mail]>
Cc: John Scudder <jgs=[e-mail]>, [e-mail] <[e-mail]>, Sue Hares <[e-mail]>
Subject: Re: [Idr] WGLC is for "BGP Router Capabilities Attribute” [was: Re: WG LC for draft-ietf-idr-entropy-09 (8/29 to 9/12/2023)]
[External Email. Be cautious of content]

Robert,



On Sep 7, 2023, at 4:02 PM, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jeff,

Speaking as an individual contributor, I also think next-hop-capabilit(ies) better reflects the proposal.

IMHO it would be the preferred title and name of the draft.

But then we have the (multi) next hop attribute coming up as well.

Shouldn't that work be combined ?

That's making the specific leap that IDR adopts the multi-next-hop work.  Even then, the proposal is subject to the usual IDR process to work on the subject matter.

As currently specified, draft-ietf-idr-entropy covers behaviors against an existing BGP nexthops, and the changes the draft pulled in were to specifically address the scoping issues.

Those scoping issues were another one of my inspirations for the attribute-escape draft.

My speculation is that if IDR adopts the multi-next-hop work, it would be appropriate to include something like the work in draft-ietf-idr-entropy as part of the multi-next-hop proposal.  I.e., the two pieces of state should be tightly coupled into a single path attribute.

That said, that's speculation.  I'm sure the authors would appreciate feedback on their proposal covering such points.




That said, I think painting each service route with the same attribute(s) is a bit wasteful design at best.

It does seem to me like sooner or later we would benefit from separate next hop state/description SAFI especially for the applications which use BGP recursion and resolve BGP service routes via another BGP AF (example BGP-LU), but even if the next hop reachability is carried in IGPs as we do not want to pollute IGP link state flooding too much.

We've spent significant time the last few years discussing things that are used for such resolution.  I don't know that it all belongs in a new SAFI.  It may belong in a change to the UPDATE message.

But either way, I think that's a topic for a different proposal than draft-ietf-idr-entropy.

-- Jeff