Re: [routing-wg]aggregation recommendations document

[Geoff Huston gih@localhost]

At 04:13 PM 23/09/2006, Philip Smith wrote:
> Hi everyone,
>
> Rob Evans, Mike Hughes and I have been working since the last RIPE
> meeting on putting together a route aggregation document. Our desire
> would be that this document becomes a Routing Working Group
> recommendation for the general Internet industry.
>
> We have 10 minutes in the WG agenda week after next to discuss it. But
> to start discussion, I've attached the current draft.
>
> Comments, additions, feedback, etc, are most welcome.
Thanks for this document - it encompasses  much of what we've learned 
so far in the routing space over time, and should be mandatory 
reading for all network operators who play in the BGP space!
One aspect of the document did strike me as deserving of some mention 
- many transit providers these days provide their customers with a 
rich set of BGP communities over and above the lowest common 
denominator of NO-EXPORT. Such prefixes allow a customer to define an 
explicit limitation of the level of re-advertisement of a prefix by 
the transit provider. Such communities allow the customer to define a 
propagation policy that can limit the extent to which a more specific 
prefix is advertised, allowing the customer a finer level of control 
over traffic, while at the same time having the potential to remove 
more specifics from the global default free routing system.
The issue today appears to be that this form of community-based 
propagation control is implemented in ways that are specific to each 
transit provider and the level of knowledge required by a customer to 
achieve their results is certainly higher, particularly if the 
customer is multi-homed to a number of such transit SPs But, in the 
global scheme of things, such communities make a huge amount of 
sense. It allows the customer more control of incoming traffic, and 
if the Transit SP is using these same communities for their announced 
routes, also allows the customer greater control in outbound traffic 
path selection. It would be useful in this document to at least 
reference this practice of custom communities (and perhaps refer to 
the community settings published by a number of transit providers as 
examples), It would be good to see this work encourage SPs to use 
such mechanisms if they are transit providers, and encourage customer 
SPs to make use of these communities as a sensible alternative to 
bombing the global routing system with all permutations of more 
specifics and AS path manipulations.
again, nice work!

 Geoff