On Mon, Feb 28, 2011 at 1:52 AM, Oliver Boehmer (oboehmer) < [email protected]> 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. 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. 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. You are right those communities do have to be in the VRF export policy. 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
