Re: [Idr] [SUSPECTED SPAM] Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

[Jeffrey Haas <[e-mail]>]

Gyan,

On Tue, Mar 30, 2021 at 08:45:29PM -0400, Gyan Mishra wrote:
> The last question I had asked about type 2 4 byte AS extended communities
> defined in RFC 5568 due the 4 byte AS eating up an extra 2 bytes in the
> Global Admin field you are only left with 2 bytes in the Local Admin
> field.  RFC 8092 was supposed to solve that shortcoming with a larger local
> administrative field.
> 
> As this draft is updating RFC 8092, I think it really should account for
> shortcomings of 4 byte extended communities.  With large communities we
> have 10 bytes of data fields even with the 2 high order bytes used we
> should still be able to accommodate.

Our current status quo with large communities perhaps should serve as a
cautionary tale for those who want to "move fast" and "keep it simple".

As Sue noted in her chairs' response, there was discussion about
transitivity, and about whether we wanted to set aside code space in the new
feature for special treatment.  The pattern we had as an example of such
special treatment is the space set aside for well known communities in RFC 1997.

The strong consensus of the working group and the rather fervent portion of
the operational community at that time was "keep it simple, ship it now".
We did.  The feature is now heavily deployed.  

We don't get to change such a feature easily, there's too many pieces of
running code that wouldn't respect the new semantics.  

One of the hardest thing about working on BGP is dealing with incremental
deployment circumstances.  We don't have a lot of easy options here.

draft-ietf-grow-route-leak-detection-mitigation quite nicely summarizes some
of the additional headaches of trying to force behaviors to fit into generic
community features.  From that document:

:    On the other hand, BGP Communities do not require a router OS update.
:    The potential disadvantage of using a Community for the route-leak
:    detection signal is that it is more likely to be dropped somewhere
:    along the way in the AS path.  Currently, the use of BGP Communities
:    is somewhat overloaded.  BGP Communities are already used for
:    numerous applications: different types of route marking, route policy
:    control, blackholing, etc.  It is observed that some ASes seem to
:    purposefully or accidentally remove BGP Communities on receipt,
:    sometimes well-known ones.  Perhaps this issue may be mitigated with
:    strong policy guidance related to the handling of Communities.
: 
:    Large Communities have much higher capacity, and therefore they are
:    likely to be less overloaded.  Hence, Large Community is proposed to
:    be used for route-leak detection.  This document suggests reserving
:    <TBD1> class for the purpose of transitive well-known Large
:    Communities that MUST NOT be stripped on ingress or egress.

Basically, "people do these things with communities that can break this
feature, if carried in communities".  "Don't do that" doesn't scale terribly
well.

-- Jeff