Re: [Idr] Vendor Defaults (was Re: Review of draft-ietf-large-community-06.txt)

[Jeffrey Haas <[e-mail]>]

Gert,

> On Nov 7, 2016, at 11:20 AM, Gert Doering <[e-mail]> wrote:
> 
> Hi,
> 
> On Mon, Nov 07, 2016 at 04:14:32PM +0000, Jakob Heitz (jheitz) wrote:
>> 5539:100 is used by 5539 to tell its neighbors that the route was learned in Frankfurt/DECIX.
>> http://www.space.net/static/bgp_communities.html
> 
> Indeed, and sorry for the 5539:70 and 5539:130 example, these were 
> obviously incorrect - the list (and our configs) say it's 5539:3070,
> 5539:3100 and 5539:3130 to set local-pref in our network.
> 
> But this example prominently documents why operators think that the model
> "5539 defines the namespace for 5539:*" is the only thing that makes sense
> - there are communities set *by* 5539, to declare "information about a 
> prefix", and there are other community values sent *to* 5539 to cause some 
> sort of policy effect in our network, but both have to be declared by 
> 5539 to be a valid reflection of our configured BGP policy.

The general issue is that the context for the use of the community is a bit overloaded.  

If the namespace, e.g. AS 5539, has communities meant to be addressed *to* it and it also has communities internal that it sets itself, it likely should use 5539:*:* for both.  The thing that keeps the properties of the externally originated and internally originated would have to be the Local1:Local2.  Enforcement of this can be done via import policy dropping internal communities at ASBRs.

The same would hold for items attached by the context AS as information for external consumers.  Unfortunately, nothing stops an external party from attaching such a community; it's up to the downstream consumer to check the AS_PATH to see if the route has transited 5539 and to hope that none of the intervening routers have added 5539 internal communities.  

With regard to the internal vs. externally added routes, this is part of the motivation in the common header in the wide communities draft.  In that header, the SRC AS is the one attaching the community whereas the Context AS is how you interpret it.  Externally vs. internally attached communities are clear in that case, although with no additional protections against maliciously setting values in the protocol.

-- Jeff (and even SIDR wasn't willing to touch that in their first pass...)