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

[Gyan Mishra <[e-mail]>]

Thanks Jeffrey that makes sense.

So in essence the main goal of the WKLC as it is new as well as would not
get overloaded with the RFC 8092 12 byte data field or proposed WKLC 10
byte data field much higher capacity as it is néw and  would only be used
 for route leak detection using the same semantics for WKLC as RFC 1997
special space. For the route leak signaling per GROW draft makes sense the
special transitivity feature for WKLC class that cannot be stripped.

Makes sense.

Kind Regards

Gyan

On Wed, Mar 31, 2021 at 10:40 AM Jeffrey Haas <[e-mail]> wrote:

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*