[c-nsp] bgp communities over vpn mpls

[Oliver Boehmer (oboehmer)]

> On Mon, Feb 28, 2011 at 1:52 AM, Oliver Boehmer (oboehmer)
> <oboehmer at cisco.com> wrote:
> 
> > It depends on the provider.  Extended communities are also used in
> vpn/vrf
> > route filters so honoring any community already seen on a customer
> route is
> > dangerous.
>> actually: RFC4364 deals with route-target extcomms already attached to
>> the eBGP customer routes, and removes all of those which are not
>> configured as RT export in the customer VRF on the PE.
> 
> I can assure you this isn't true of all vendor implementations.  

Hmm, ack.. looks like the behaviour is not specified in the RFC (or I missed it)..

> Also, if a
> MPLS provider wishes to allow a customer to use a specific set of
> communities all they would have to do is add them to the export policy, so
> this doesn't really answer the question.

Not sure I follow? And, BTW: I did not discuss the OP's question about getting standard communities across an MPLS-SP-service, this is different and straight-forward (only requires the SP allows to send standard communities across its core). Just wanted to reply to your comment about the danger accepting ext-comms.

> For example if you run BGP with a
> customer you can allow them to advertise extended communities and attach
> them to a pre-pend policy to allow customers to prepend individual routes
> without your intervention.  This is actually fairly common 

can you give an example, not sure I understand what you refer to..
	
>> This capability
>> allows the customer to specify only a subset of VRFs which should see
>> the pfx. Not really useful and not widely used as it would require the
>> customer to know exactly about the SP's RT import/export
>> structure/assignments, but I wanted to mention that RT extcomm's
>> received from the customer do not compromise the route
>> isolation/segmentation property of BGP-L3VPN..
> 
> How so? Communities applied on the cpe could affect import policies of
> remote vrf's depending on how your policies are configured. Having it
> advertised from the CPE would be the same as having it advertised from the
> customer if they are permitted by policy.  Again the communities aren't
> stripped by default in all implementations.  Even when they are, they can be
> allowed if there is a business case or a misconfiguration.

Not sure I understand, but just to highlight the point I was trying to make (which might have missed your point completely ;-)
The case I was referring to was: Imagine you have a vrf

ip vrf foo
 route-target export 123:123
 route-target export 456:456

where 456:456 is actually a central service route-target, imported at a shared datacenter at a remote PE. If the CE sends an eBGP path to this PE in vrf foo with an extended community RT:123:123, the PE (at least the Cisco PE) will accept this extcomm and, when converting this into a vpnv4 update, will NOT append RT:456:456, so the remote datacenter PE will not import this specific prefix. Does this make sense? It might. Is it being used? maybe, but likely not often.
The key point: If the customer appended community RT:999:999, the PE will strip this one, so security is not compromised as RT999:999 could belong to a completely different customer/vrf..

	oli