Re: [Idr] RCA = ELCv3 + NHC

Hi, John:

I think this is the right direction for these two drafts.
Want to ask two questions for the current version:
1) Why do you include still the AFI/SAFI value for this newly defined attribute?  Given such information has been included within the associated BGP update.
2) Why doesn’t the current draft include the RLD value that has been mentioned in https://datatracker.ietf.org/doc/html/draft-ietf-idr-next-hop-capability-08

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: idr-bounces@ietf.org <idr-bounces@ietf.org> On Behalf Of John Scudder
Sent: Monday, October 10, 2022 10:20 PM
To: idr@ietf.org
Subject: [Idr] RCA = ELCv3 + NHC

Hi All,

During the WG adoption discussion for ELCv3, Bruno made several good suggestions. Following that, we’ve worked to see if we could merge NHC and ELCv3. The result is posted as draft-ietf-idr-entropy-label-01. Please have a look, I think this version addresses either all or most, of the concerns that were raised during the adoption discussion.

To summarize the merger:

- Semantically, it’s the same as 00 for purposes of entropy label support.
- Syntactically, it retains the format introduced in ELCv3 draft 00, but the trailing data now carries router capability TLVs as defined in NHC.
- Router capability = 1 is ELCv3, it carries no additional data.
- Semantically it’s close to NHC for purposes of introducing new TLVs, but it’s transitive instead of nontransitive.
- The language from draft 00 regarding matching the next hop field, dropping the attribute, etc, is generalized.
- The language from NHC regarding TLV formats, interpretation, etc, is brought in.

One less-important — in a way — change is that the title is now "BGP Router Capabilities Attribute”, short name “RCA”. Various names were discussed, none of them ideal,  [*] and this is still open to being changed again but we needed to publish with some name. :-) One thing that bugs me, personally (I can’t speak for any other the other authors), is the collision between what we call “capabilities” here, and RFC 5492 Capabilities, with the attendant potential for confusion in the future.

It’s also the case that with this merger, the draft name “entropy-label” is misleading since ELCv3 becomes just one use for the Router Capabilities Attribute. I guess we could rename it, but it seemed more important to push the update so the WG can look than to get the naming exactly right.

Looking forward to discussing this at Thursday’s interim.

Regards,

—John

[*] As we all know, there are only two hard problems in computer science, naming things, cache invalidation, and off-by-one errors. ;-) _______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr