> How do you know that the overlapping route takes traffic through the > same path? AS path != routing path and BGP is a distance-vector > protocol. Your router has no reliable knowledge of the routing path > more than 1 hop away.
All that matters is that I draw the same traffic into my AS, where the more specifics still exist, so I can optimally route the traffic out of my AS --the same as I always have. You seem to be thinking that this would be done at the edge in some way --that the originating AS would be doing the suppression. That's not the way this is designed to work at all. The suppression is supposed to take place at least one hop away from the route origin, and only if I can be reasonably certain that my suppression of the longer route isn't going to change traffic patterns from my perspective. > Even if you could know the routing path was the same, consider: > > ISP 88 > 10.1.0.0/16 via 2 3 > 10.1.1.0/24 via 2 3 (suppressed) > > ISP 99 > 10.1.0.0/16 via 4 12 62 16 2 3 > 10.1.1.0/24 via 4 8 9 5 3 (not suppressed) > > ISP 111 (customer of 88 & 99): > 10.1.0.0/16 via 88 2 3 > 10.1.1.0/24 via 99 4 8 9 5 3 > > Best route was lost. But 111 can't safely suppress the /24 route > because he has no knowledge of whether the /24 is reachable via 88 1 2 > 3. To the best of 111's knowledge, AS3 might look like this right now: So, I'm trying to guess how you have things connected, but it seems like what you're saying is that the longer prefix is suppressed, leaving a shorter prefix that loses to another peer's shorter prefix which doesn't actually contain the longer prefix. Further, the two AS' advertising the two shorter prefixes cannot be connected to one another. I actually don't see how this would work in normal routing, much less if you suppress the shorter --you're saying you have a situation where one AS has access to 10.1.0.0/16 and 10.1.1.0/24, and another has access to 10.1.0.0/16, but not 10.1.1.0/24. I'd like to see a network designed where this is true without data plane filters implemented. :-) Russ _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
