maximum ipv4 bgp prefix length of /24 ?

Mark Tinka mark at tinka.africa
Sat Oct 7 13:00:57 UTC 2023



On 10/7/23 14:32, Willy Manga wrote:

> How about we educate each other to not assume you must deaggregate 
> your prefix especially with IPv6?
>
> I see 'some' (it's highly relative) networks on IPv4, they 'believe' 
> they have to advertise every single /24 they have. And when they start 
> with IPv6, they replicate the same mindset with a tons of /48 . You 
> can imagine what will happen of course.
>
> A better alternative IMHO is to take advantage to the large prefix 
> range and advertise a sub-aggregate when necessary. But absolutely not 
> each end-node or customer prefix.

There are a number of operational reasons folk de-aggregate. I do agree 
that there is some behaviour around de-aggregating by default in IPv4 
that transferred to IPv6. But the main issue is that most people only 
consider the state of their own FIB situation. They hardly consider the 
FIB state of other network operators around the world.

As an operator, you have to consciously decide that you will not 
de-aggregate any of your allocations. Of course, there is a cost to that 
as well, so that cannot be ignored. We, for example, do not de-aggregate 
any of our allocations (AS37100), but we can afford to do so because we 
always ensure all peering and transit exit/entry points have the same 
bandwidth (TE being the main reason networks de-aggregate). Not all 
shops can afford that.

Network operations workshops abound where we teach about de-aggregation, 
when it can be necessary, and why it should generally be avoided unless 
in the most extreme of circumstances. However, in real life, even 
engineers that have been through the workshop ringer tend to prefer to 
de-aggregate without caution to the FIB state of other autonomous 
systems. That said, I do agree that, perhaps, network operations 
workshops could emphasize the reluctance to unnecessarily de-aggregate 
in light of the increasing cost of having to maintain FIB's.

Mark.


More information about the NANOG mailing list