nanog mailing list archives

Re: "Tactical" /24 announcements


From: Jeff Tantsura <jefftant.ietf () gmail com>
Date: Sat, 14 Aug 2021 10:49:04 -0700

Every major vendor at some point in time has implemented RIB->FIB(really BGP->RIB->FIB) filtering, on Redback/Ericsson 
routers we did around 2013/2014(@Jakob Heitz;-))
Route compression is a more complex topic, it is not difficult to aggregate, it is to effectively disaggregate on 
changes.
MS research  published a white paper in early 2010s, Volta in late 2010s implemented quite effectively route 
aggregation on top of FRR BGP stack (full BGP table into Trident2 class silicon),  to my memory, Spotify did a similar 
implementation with Arista.

Most importantly - these days (at least Cisco and Juniper) through service layer APIs allow to run best path off box 
and reinject the results back into RIB, where the routes computed would still be a subject to best route selection and 
hence reasonably safe wrt loops.
So if you feel advantageous - write your own compression code, toolset is there.

Cheers,
Jeff

On Aug 14, 2021, at 06:21, Masataka Ohta <mohta () necom830 hpcl titech ac jp> wrote:

Baldur Norddahl wrote:

For all the stub networks out there we should be able to aggressively
filter routes without much harm.

Stub networks, which, by definition, do not have transit traffic
over them, can not filter routes for transit traffic at all.

But, if both of two stub networks with address ranges of
131.112.32.0/24 and 131.112.33.0/24 advertise 131.112.32.0/23,
the result will be disastrous for the networks.

As such, even stub networks should advertise exact address
ranges of them.

                           Masataka Ohta


Current thread: