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

[Susan Hares <[e-mail]>]

Robert:

[WG chair hat on]
Thank you for clarifying your comment.  I would like to respond to just one comment as an individual contributor.

>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.
[WG chair hat off]

[individual contributor hat on]
Your reading matches mine, but I may have missed something.

Sue

From: Robert Raszuk <[e-mail]>
Sent: Thursday, September 7, 2023 6:21 PM
To: Susan Hares <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>; John Scudder <jgs=[e-mail]>; [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)]

Hi Sue,  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2JmZGY5MTFlNDZhNThiY2FiMGRlZjY4MWYwNjYyNDVkLzE2OTQxMjUyNTcuMzc=#key=59494fd462979e7c1fb4fb4505d9cb03>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

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<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxFzcsOgjAQheFXIV3bliItl5Wv0jJTISKQ6SBe4rsrbtyeP_nOS6w0ijYTPfOSWq23bVMDclQznbWnrh9uqAfQQD6yTN0KgCQHIIkT07w85OgDjjI3iu8sDpm47NyE_AVMbmvXmEKn3hOm0wTPXnXzVYcIsTEGS-dtHTofcsDoahNz54rSgjauKU1hC1upY7WruKs0ByQ-kU_P9aK-H3uBX_lP7w8ehENN.MEUCIAvtVEMiQpadXidh3ixEj2s6gDAqAzoxX8xYUhDLb51DAiEAsRXpDeWWj8Y0wyAAJwREs3ygjpvi1Y6UmboCHwGIiH0> (with subsequent changes but pre-merge).

Kind regards,
Robert