On Wed, Oct 3, 2012 at 10:20 AM, Russ White <[email protected]> wrote: >>> I don't get how path information is lost in this draft. The AS Path is >>> not altered in any advertisement, so it's not like aggregation, where >>> you replace a series of AS' with a single AS, or anything like that. >> >> 10.1.0.0/16 AS path 12 5 4 2 >> 10.1.1.0/24 AS path 12 1 >> >> The 12->1 path, 1 being a completely different origin AS than the >> covering route's origin from 2, is lost when 10.1.1.0/24 is aggregated >> into 10.1.0.0/16. > > No more than if the longer prefix were filtered for any other reason > --such as if the provider is originating the shorter prefix, and decides > to filter the longer prefix for whatever local policy reason. The only > way to see this as "losing AS Path information," is to see the filtering > of any possible route, including routes lost because they aren't the > best path, as "losing AS Path information."
Hi Russ, With the occasional exception of leaf ASes, the longer prefix *isn't* filtered for any reason today. Precisely because it breaks the routing system. Some folks tried some filtering for a while, filtering at /21 based on RIR minimum allocation sizes within particular /8's but it didn't work out. Operationally, the current expectation is that any prefix /24 or shorter will be propagated throughout the system. The moment a major transit AS uses this technique, everybody doing something like the above has to disaggregate into non-overlapping routes in order to maintain operations. Those two advertisements become at least nine. Unless you can identify a sufficient number of origins who for one reason or another *wouldn't* choose to disaggregate, the use of the technique in any transit AS would result in an *increase* rather than decrease the routing table load. If you restrict your solution set to non-transit ASes there are some promising techniques based on aggregating for AS distance rather than overlap. As a leaf, once a route is distant enough from you, if you see it from all "upstream" neighbors you can usually aggregate it into a /8 covering route with typically negligible harm to your routing efficiency. But that only works if you are a leaf AS. If there's someone who would otherwise receive the more specific route from you then you've just broken the routing system. And of course offering the aggregate route to a neighboring AS is a recipe for nastiness since you can't really analyze its impact anywhere other than inside your own AS. However, since you're already at the leaf AS for this approach, it's not clear such a technique wouldn't be better applied to the FIB produced from the RIB rather than to the RIB directly. You have to process the prefixes inbound anyway and holding them in a radix tree that isn't accessed on a per-packet basis isn't computationally expensive. > This has always been true of any form of aggregation --this draft > doesn't introduce any new risk in this area. When you aggregate at any > level, ever, you always introduce the risk of suboptimal routes and/or > routing black holes. Does this mean all routes advertised into the DFZ > should be /24's, or host routes? No. It means that the source AS is the only place technically capable of making verifiably correct aggregation decisions impacting transit ASes. Stated more generally, an AS is only capable of making aggregation decisions which impact only that AS. The moment your aggregation choice spreads to a neighbor AS you've broken the system. As I mentioned in previous emails, this has been explored ad nauseam over in RRG. It would be very productive to dig through those archives and use the knowledge there to produce an RFC that documents the myriad issues that a solution in this space would have to resolve. Perhaps as a first step to further analyzing your approach. Regards, Bill Herrin -- William D. Herrin ................ [email protected] [email protected] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
