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

[Gyan Mishra <[e-mail]>]

Thanks John!

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*



On Wed, Feb 28, 2024 at 11:45 AM John Scudder <[e-mail]> wrote:

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