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