Re: [Idr] Error in draft-ietf-idr-sdwan-edge-discovery use of Encapsulation Extended Community

[John Scudder <[e-mail]>]

Hi Gyan,

> On Feb 28, 2024, at 11:19 AM, Gyan Mishra <[e-mail]> wrote:
> 
> Yes that is what I was thinking to mark tunnel affinity.  Yep that would be difficult since it’s separate from the tunnel endpoint TEA.  How to correlate back to the tunnel endpoint would be tricky.
> 
> RFC 9012 deprecates RFC 5512 extended community but kept section 4.1 for backwards compatibility to RFC 5512 and thus was encoded as a bare bones TLV and not allowing sub TLVs.  In cases such as SD WAN draft and maybe future use cases it would have been nice to allow for sub TLVs and not have that restriction.  
> 
> It seems the sub TLV restriction maybe was made for backwards compatibility to RFC 5512?  What do you think?  Or maybe not.

If you look at RFC 5512 Section 4.5, you’ll see it’s functionally the same as what’s in 9012. Importantly, the extended community *encodes a tunnel*, it doesn’t serve as a hint or linkage. Obviously it can only encode very simple tunnel types, since the extended community is fixed-format and small. Hint/linkage was never a feature of 5512. The sub-TLV thing isn’t exactly a “restriction”, it’s just that it’s never what the community was *for*. The encapsulation extended community also can’t encode GIFs. That’s not a “restriction", it’s just not what it’s for.

> Just wondering if would be worth an errata to lift the restriction since it makes it difficult for the extended community to be useful.

This isn't a valid use of an errata, since it’s seeking to change the specification from what was intended and agreed at time of publication. If the WG wanted to make this change, it would have to be through a bis or an update to 9012 — but I don’t see why we’d do that. If we want a tunnel-affinity community, we should just define one. Quicker, easier, clearer.

I also don’t agree it "makes it difficult for the extended community to be useful”. It works fine for its intended and documented purpose.

> I guess as you mentioned RFC 9012 could be updated adding a new TEA extended community path attribute for future use cases such as this one.

Exactly. 

—John