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)]

[Robert Raszuk <[e-mail]>]

Hi Sue,

Robert:
>
>
>
> This draft-ietf-idr-entropy-09 text allows new features to be added to
> this attribute.
>

Those "features" and their yet to be defined handling requirements is what
worries me the most in this (well merged) proposal. We are standardizing
envelope with fixed header (read address space) and the requirements of the
future payloads may not fit the design of it.


> Are you suggesting that this signal the capability for handling different
> forms next-hops in the NLRI?
>

No, not at all. I hope not. This draft just described the property of the
last next hop (the same as in the NLRI) while allowing the future to be
defined aggregation of any information in other "capabilities".


> This seems to be within scope of this attribute as a capability.
>

I don't read it that way ... as we established so far today this is really
all opaque to BGP what is being carried by this attribute so far
with descriptive anchor being next hop.

Frankly what I am really afraid of is that we are opening the doors here
for a bunch of various new proposals which now will be moving all
signalling of node's capabilities from IGP to BGP and stuffing those into
the new attribute. And that would be done in a pretty wild uncontrolled way
as it is hard to say - oh entropy belongs here and why not XYZ (for example
MSD ) ?. We did that mistake with BGP-LS once already and one could hope
we learn from the past mistakes :-)


> draft-kaliraj-idr-multinexthop-attribute-09 suggests including multiple
> nexthops in an attribute (see section 5).  It removes the Next Hop from the
> AFI/SAFI NLRI into a attribute.   Are you suggesting we merge the
> draft-kaliraj-idr-multinexthop-attribute encoding also be merged into the
> variable Next Hop field?
>

Well - does it really remove it from MP_REACH ? My current reading of it
was that it allows to carry both best and non best path next hops in the
new attribute for various use cases, but not that it removes anything from
those SAFIs which do carry NH in the MP_REACH.

Please let me know if I understand your proposal.
>
>
>
> If I do understand your proposal, do you have a specific proposal for an
> encoding format?
>

My opinion is to actually limit the functionality of the new attribute to
ELCv3 only as described in the original proposal from John:

https://www.ietf.org/archive/id/draft-scudder-idr-entropy-label-01.txt
(with subsequent changes but pre-merge).

Kind regards,
Robert