On 2016-04-29 12:48, Nick Hilliard wrote:
Alain Hebert wrote:
PS: "Superfluous" is a nice way to say that the best path of a subnet is the same as his supernet.
... from the point of view of the paths that you see, which is to say two egress paths. Someone else on the internet may have a different set of bgp views which will give a different set of results for the bgp decision process. The more paths you receive from different sources, the more likely it is that this list of 120k "superfluous" prefixes will converge towards zero.
You're right that it's often not necessary to accept all paths, and your fib view can optimised in a way that your rib shouldn't be. All these things can be used to drop the forwarding lookup engine resource requirements, although it is important to understand that there is no such thing as a free lunch and if you do this, there might well be edge cases which could cause your optimisation to fail and things to blow up horribly in your face. Still, it's an interesting thing to examine.
Nick
What Nick said is basically what I was asking about in the Arista thread. Are there new edge cases and new failure modes that are introduced by this strategy? It seems like you'd have to recompute the minimal set of forwarding rules each time a prefix is added or removed, and a single update may cause you to have to do many adds/removes to bring your compressed rules into sync, like when a hole is punched in an aggregated prefix. I'm curious about specific failure modes that can result from this, if anyone can share examples/experience with it. Thanks, Laszlo