Re: [Idr] clarification sought on rfc4360 non-transitive extended communities

[Jeffrey Haas <[e-mail]>]

I have slightly more context here.

On Fri, Apr 14, 2017 at 10:58:57AM -0400, Eric C Rosen wrote:
> On 4/14/2017 9:44 AM, Job Snijders wrote:
> >Hi IDR,
> >
> >RFC 4360 states:
> >     """
> >     If a route has a non-transitivity extended community, then before
> >     advertising the route across the Autonomous System boundary the
> >     community SHOULD be removed from the route.  However, the community
> >     SHOULD NOT be removed when advertising the route across the BGP
> >     Confederation boundary.
> >     """
> >
> 
> You'll note that there are very few non-transitive extended
> communities.  Extended communities are usually used to carry
> parameters of various BGP-based control protocols.  As such, it
> would be nice if they could be scoped to the "domain" of the control
> protocol.  The transitive/non-transitive distinction was a somewhat
> primitive attempt to provide this scoping.  Unfortunately, the
> boundaries of the control protocol domain are rarely the boundaries
> of the AS in which a route originates.  So this particular form of
> scoping has not proven to be very useful.
> 
> >For my edification, I have two questions:
> >
> >     o   Why was nothing specified for the behaviour of receivers?
> 
> Since the authors are either retired or in management, it is
> difficult to say for sure.  I'd say there are two possibilities:
> 
> - Sloppy specification writing.
> 
> - A belief that if the transmitter has decided to send the
> non-transitive EC over an AS boundary, it may have a good reason for
> doing so, and the receiver shouldn't second guess it.
> 
> I'd guess the former.

The missing use case covers the difference between propagation and
origination.

When you are originating a non-transitive EC, you can send it to your iBGP
peers and the case is clear to all parties.  However, you can also attach a
non-transitive community when sending routes to your eBGP peers.  This would
be the case if you're attaching a community that you wanted to only live
within that network.

Thus, by default, if you're not adding a non-transitive EC, you should strip
it when propagating your routes along an eBGP boudnary.

There of course is the annoying case where your policy says "propagate it",
which is effectively the same as if it's re-originating the community.

> >Is it a "SHOULD" because Extended Communities are wrapped in an optional
> >transitive path attribute, so strictly speaking, the non-transivity can't
> >be enforced anyway, since a middle-box might not understand the Extended
> >Community?
> 
> Well, that's a possibility, but I don't recall anyone worrying too
> much about ASBRS that don't understand the Extended Communities
> attribute.

I believe this was to handle the propagate via policy consideration.

-- Jeff