>> 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.
There's a vast difference between filtering out everything longer than a /21 and suppressing a /24 when an overlapping route that takes the traffic through the same path available. Completely different concepts. In the case of suppressing longer prefixes, the result is something like fisheye routing, or simple aggregation today. If an edge device only has a default route, you don't expect the traffic to travel to the far end of the network before it starts following a more sane path to the destination. Instead, the traffic might follow a less than optimal route until it reaches a point in the network where more specific routing information is available. This proposal does the same thing --I notice that I will be advertising two overlapping routes that will draw traffic along the same path (to me) to a peer. There's no reason to advertise both possible paths, it's simply overlapping information that's not needed to draw traffic in the right direction. So I don't advertise it. >> 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. Yes. Sorry, but it is always true that by removing information you always lose optimality (you increase stretch). Whether that removal is done at the edge or in the core, the result is always the same. There are two ironclad rules of routing: - Removing information decreases optimal routing. - Removing information is necessary for the stability of the system. You can play with different ways and places to remove information, but you're always going to need to remove information. You can try to remove information in the way that least impacts optimal routing, but you're always going to introduce suboptimality in some way. This proposal is about the minimal you can get to in terms of removing information (no worse than best path does today), to keep modifications to the path traffic actually flows to a minimum. I've looked at stuff that does less than this, none of which has turned out to have any meaningful impact, and stuff that does more than this, which has turned out to be either complex for the gain, or increases stretch in significant ways in normal operation (and not just broken corner cases). > It means that the source AS is the only place technically capable > of making verifiably correct aggregation decisions impacting transit > ASes. Actually, the origin AS is the one place where you can't know how far your route should propagate in order to effectively engineer traffic. The only place you can know that the longer prefix is no longer useful is at the point where two overlapping prefixes exist that will point traffic in the same direction. > 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. I can feel your hands waving all the way over here... :-) How about thinking up a specific situation where a problem exists that will not or can not exist through normal aggregation, or through normal route processing today, and posting it to the list? We can then sort out whether its something that's actually broken (outside brokenness that already exists in the routing system), if can be fixed, or if it's impossible to fix. :-) Russ _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
