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

From: Job Snijders <[email-masked]>
Date: Fri, 14 Apr 2017 16:44:35 +0300

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

For my edification, I have two questions:

    o   Why was nothing specified for the behaviour of receivers?
    o   why is it a "SHOULD" and not a "MUST"?

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?

Kind regards,

Job

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 14 Apr 2017 10:58:57 -0400

>      SHOULD NOT be removed when advertising the route across the BGP

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.

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

It is of course true that receivers have to be careful about getting ECs 
from outside the domain of the relevant control protocol, but that's 
true whether the EC is transitive or non-transitive.

>      o   why is it a "SHOULD" and not a "MUST"?

I'm pretty sure it is a "SHOULD"  because the authors thought that there 
might be applications that need to violate the rule, and hence it should 
be allowable to have policy that passes the non-transitive ECs.

> be enforced anyway, since a middle-box might not understand the Extended

Well, that's a possibility, but I don't recall anyone worrying too much 
about ASBRS that don't understand the Extended Communities attribute.

---

From: li zhenqiang <[email-masked]>
Date: Tue, 18 Apr 2017 03:06:28 +0000

Hi Eric and Job,

Extended communities are used to do more and more things by introducing new types. So we cann't expect a BGP speaker that understands the  Extended Communities attribute understands all the EC types.

Best Regards,
________________________________
[email-masked]

From: Eric C Rosen<mailto:[email-masked]>
Date: 2017-04-14 22:58
To: Job Snijders<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] clarification sought on rfc4360 non-transitive extended communities

I'd guess the former.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Apr 2017 17:25:35 -0400

I have slightly more context here.

On Fri, Apr 14, 2017 at 10:58:57AM -0400, Eric C Rosen wrote:
> 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.
> 
> Since the authors are either retired or in management, it is
> difficult to say for sure.  I'd say there are two possibilities:
> 

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.

> 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