IIRC, this has come up on cisco-nsp before, and the response has
been that
it's very "icky" to do and doesn't really save anything on most
platforms.
In the example case of
1) 192.168.0.0/16 AS11111 AS22222 AS33333
2) 192.168.1.0/24 AS11111 AS22222 AS33333
3) 192.168.2.0/24 AS11111 AS55555 AS44444 AS33333
4) 192.168.3.0/24 AS11111 AS22222 AS33333
Forrest says the router should be smart and reject paths 2 and 4
because
they're covered by 1. Now what happens when 1 is revoked? Do we
lose
connectivity to 2 and 4, or does the router have to keep track of all
these dependant routes and reinstall 2 and 4 when 1 is lost?
Based on what seems to be reported by the CIDR-REPORT, I would say
that if
#1 is revoked then it's likely all of the routes with the same AS Path
will be revoked anyway. But if not, rather than the router having to
recalculate whether the more specifics should or should not be
accepted
at each routing update, you could apply the same principles that route
flap dampening uses. Reject paths #2 and #4 for X number of minutes
before you bother checking again to see if the larger aggregate is
still
there.
The problem with this is that if you reject the routes initially and
then later need them, then they're not in your incoming BRIB to
reconsider. BGP is an incremental protocol. You can either save an
update or you can ignore it, but if you ignore it, it's just plain gone.
If you do save it in your BRIB, then you can do this filtering
between RIB and FIB. That turns out to be a completely local
feature, requiring no protocol changes or additions whatsoever, and
thus does not even require an RFC or Internet draft. This feature
has been seen in some circles under the name "ORIB". Ask YFRV's PM
for it. ;-)
Note that this feature *is* CPU intensive. This also does not
decrease the RP RAM usage the way that update filtering would. In
fact, due to the overhead of tracking filtered and non-filtered
prefixes, there is additional RP RAM usage. YMMV.
Tony
