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 <mo...@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
