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
