maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

hello,

I believe, ISPs should also allow ipv4 prefixes with length between 
/25-/27 instead of limiting maximum length to /24..


I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are 
sufficient for most of the small and medium sized organizations and also 
home office workers like youtubers, and professional gamers and webmasters!


It is because BGP research and experiment networks can not get /24 due 
to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in 
IPv4 world.


What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do 
full-table-routing also use multi-core routers with lots of RAM? those 
would probably handle /27s and while small networks mostly use default 
routing, it should be reasonable to allow /25-/27?


Thanks for reading, regards..

Re: maximum ipv4 bgp prefix length of /24 ?

[Jon Lewis]

On Fri, 29 Sep 2023, VOLKAN SALİH wrote:


I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
instead of limiting maximum length to /24..

I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient 
for most of the
small and medium sized organizations and also home office workers like 
youtubers, and professional gamers and webmasters!

It is because BGP research and experiment networks can not get /24 due to high 
IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world.

What do you think about this?


Not going to happen any time soon (if at all).

#show ip route summary | i Source|---|bgp
   Route SourceNumber Of Routes
- -
   bgp   925809

Think about how much network gear is out there that is straining under the 
current size of the global table.  Opening the flood gates to many more 
prefixes with /25-/27 routes in the global table would mean lots of gear 
needs to be upgraded/replaced sooner rather than later.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: maximum ipv4 bgp prefix length of /24 ?

[Joe Hamelin]

Wasn't it about 1997 or so when we ran into deployed Cisco gear (5500s back
then) running out of memory for BGP routes?  Been there, done that. -Joe

On Thu, Sep 28, 2023 at 7:41 PM Jon Lewis  wrote:

> On Fri, 29 Sep 2023, VOLKAN SALİH wrote:
>
> > I believe, ISPs should also allow ipv4 prefixes with length between
> /25-/27 instead of limiting maximum length to /24..
> >
> > I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4
> address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are
> sufficient for most of the
> > small and medium sized organizations and also home office workers like
> youtubers, and professional gamers and webmasters!
> >
> > It is because BGP research and experiment networks can not get /24 due
> to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in
> IPv4 world.
> >
> > What do you think about this?
>
> Not going to happen any time soon (if at all).
>
> #show ip route summary | i Source|---|bgp
> Route SourceNumber Of Routes
> - -
> bgp   925809
>
> Think about how much network gear is out there that is straining under the
> current size of the global table.  Opening the flood gates to many more
> prefixes with /25-/27 routes in the global table would mean lots of gear
> needs to be upgraded/replaced sooner rather than later.
>
> --
>   Jon Lewis, MCP :)   |  I route
>   StackPath, Sr. Neteng   |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>


-- 
--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

Wouldn’t /48s be a better solution to this need?

Owen


> On Sep 28, 2023, at 14:25, VOLKAN SALİH  wrote:
> 
> hello,
> 
> I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
> instead of limiting maximum length to /24..
> 
> I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
> address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient 
> for most of the small and medium sized organizations and also home office 
> workers like youtubers, and professional gamers and webmasters!
> 
> It is because BGP research and experiment networks can not get /24 due to 
> high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 
> world.
> 
> What do you think about this?
> 
> What could be done here?
> 
> Is it unacceptable; considering most big networks that do full-table-routing 
> also use multi-core routers with lots of RAM? those would probably handle 
> /27s and while small networks mostly use default routing, it should be 
> reasonable to allow /25-/27?
> 
> Thanks for reading, regards..
> 

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

CIDR and aggregation in the early 1990s was developed in response to AGS+ 
routers falling over under
the strain of the global size back then. Since then, IPv4 has been a 
progressive loosing proposition and
only gets worse every year. This proposal could certainly accelerate the rate 
at which it continues to get worse.


Owen


> On Sep 28, 2023, at 19:56, Joe Hamelin  wrote:
> 
> Wasn't it about 1997 or so when we ran into deployed Cisco gear (5500s back 
> then) running out of memory for BGP routes?  Been there, done that. -Joe
> 
> On Thu, Sep 28, 2023 at 7:41 PM Jon Lewis  > wrote:
>> On Fri, 29 Sep 2023, VOLKAN SALİH wrote:
>> 
>> > I believe, ISPs should also allow ipv4 prefixes with length between 
>> > /25-/27 instead of limiting maximum length to /24..
>> > 
>> > I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
>> > address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are 
>> > sufficient for most of the
>> > small and medium sized organizations and also home office workers like 
>> > youtubers, and professional gamers and webmasters!
>> > 
>> > It is because BGP research and experiment networks can not get /24 due to 
>> > high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 
>> > world.
>> > 
>> > What do you think about this?
>> 
>> Not going to happen any time soon (if at all).
>> 
>> #show ip route summary | i Source|---|bgp
>> Route SourceNumber Of Routes
>> - -
>> bgp   925809
>> 
>> Think about how much network gear is out there that is straining under the 
>> current size of the global table.  Opening the flood gates to many more 
>> prefixes with /25-/27 routes in the global table would mean lots of gear 
>> needs to be upgraded/replaced sooner rather than later.
>> 
>> --
>>   Jon Lewis, MCP :)   |  I route
>>   StackPath, Sr. Neteng   |  therefore you are
>> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
> 
> 
> -- 
> --
> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Thu, Sep 28, 2023 at 2:25 PM VOLKAN SALİH  wrote:
> I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
> instead of limiting maximum length to /24..
>
> It is because BGP research and experiment networks can not get /24 due to 
> high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 
> world.

Hello,

Each BGP route advertised into the global table is expensive. Not for
the advertiser... for everyone else. See
https://bill.herrin.us/network/bgpcost.html
Caveat that the document is based on 2008 data. The numbers (though
probably not their shape) have changed.


> What do you think about this?

I think you'll convince the IETF to release the Class-E space before
you convince the ISPs to broadly honor sub-/24 prefixes.


> What could be done here?

In principle, a company could make a business out of announcing a
large block from a bunch of peering points and then tunneling (vpn)
parts of it back to customers with sub-/24 assignments. With a broad
enough selection of peering points, the routing would not be too
inefficient. And it would divorce the IP addresses from the last-mile
Internet infrastructure, allowing you to take your addresses with you
as long as you kept paying the tunnel company.

In practice... there's not enough money in it. If you could ante up
the cost, you could find a way to qualify for and acquire a full /24.


> Is it unacceptable; considering most big networks that do full-table-routing 
> also use multi-core routers with lots of RAM?

You're thinking of DRAM. But that's not the way it works. Some routers
use heavily parallel routing engines, each of which need enough dram
to hold the full forwarding information base and which can suffer from
CPU cache exhaustion even then. Others use an expensive kind of memory
called a TCAM that's very fast but both expensive and power hungry, so
generally not sized for huge numbers of tiny routes.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

> On Sep 28, 2023, at 21:14, VOLKAN SALİH  wrote:
> 
> IMO, No. ipv4 is not dead yet. we need to raise it, a bit.
> 

Agree to disagree… We need to put the final stake through its heart and move on.

> EINAT solutions are OK
> 

I presume you mean CGNAT? Otherwise, not sure what EINAT is and couldn’t find
a reference with a quick google search.

Again agree to disagree. NAT is bad and more NAT is just worse.
> The future will come very quickly, right now.
> 
One can hope, but it seems to be taking a long time so far.
> We just need to invest in the internet.
> 
Yes, but let’s focus that investment where it makes sense. IPv4 isn’t that.

Owen

> 
> 29.09.2023 07:11 tarihinde Owen DeLong yazdı:
>> Wouldn’t /48s be a better solution to this need?
>> 
>> Owen
>> 
>> 
>>> On Sep 28, 2023, at 14:25, VOLKAN SALİH  
>>>  wrote:
>>> 
>>> hello,
>>> 
>>> I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
>>> instead of limiting maximum length to /24..
>>> 
>>> I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
>>> address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are 
>>> sufficient for most of the small and medium sized organizations and also 
>>> home office workers like youtubers, and professional gamers and webmasters!
>>> 
>>> It is because BGP research and experiment networks can not get /24 due to 
>>> high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 
>>> world.
>>> 
>>> What do you think about this?
>>> 
>>> What could be done here?
>>> 
>>> Is it unacceptable; considering most big networks that do 
>>> full-table-routing also use multi-core routers with lots of RAM? those 
>>> would probably handle /27s and while small networks mostly use default 
>>> routing, it should be reasonable to allow /25-/27?
>>> 
>>> Thanks for reading, regards..
>>> 
>> 

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Thu, Sep 28, 2023 at 9:50 PM VOLKAN SALİH  wrote:
> multi-homed networks could also do default routing just packet-mark incoming 
> interface and then route packets out via same interface..

Take that to its logical conclusion and you'll invent MPLS.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

> 
> In principle, a company could make a business out of announcing a
> large block from a bunch of peering points and then tunneling (vpn)
> parts of it back to customers with sub-/24 assignments. With a broad
> enough selection of peering points, the routing would not be too
> inefficient. And it would divorce the IP addresses from the last-mile
> Internet infrastructure, allowing you to take your addresses with you
> as long as you kept paying the tunnel company.

Actually, such a service would be much easier to stand up as a bunch
of virtual routers running on VPS instances in various cloud providers.
Simple as standing up a VPS running Debian 12 and FRR, then sell
routed blocks to people.

Personally, I think that’s fairly hideous, but someone can probably find a
way to make money doing it.

I know that there are companies charging $ridiculous for “SDN” solutions
that are literally not much more than a tunnel running between two
AWS nodes.

> In practice... there's not enough money in it. If you could ante up
> the cost, you could find a way to qualify for and acquire a full /24.

Given what some of the SDN providers out there are charging, I’m not
so sure that’s true. YMMV.

>> Is it unacceptable; considering most big networks that do full-table-routing 
>> also use multi-core routers with lots of RAM?
> 
> You're thinking of DRAM. But that's not the way it works. Some routers
> use heavily parallel routing engines, each of which need enough dram
> to hold the full forwarding information base and which can suffer from
> CPU cache exhaustion even then. Others use an expensive kind of memory
> called a TCAM that's very fast but both expensive and power hungry, so
> generally not sized for huge numbers of tiny routes.

Trio and Later generations of Juniper MX line cards (which are getting fairly
long in the tooth these days) can handle more than 5M routes in the FIB.
Even the old (now ancient) DPCs can handle ~1.5M routes if you don’t
need a boatload of access lists. (Basically you have to steel FIB memory
from the Access List memory partition, but that’s a simple software
command and a reboot of the line card).

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Thu, Sep 28, 2023 at 9:54 PM Owen DeLong  wrote:
> > In principle, a company could make a business out of announcing a
> > large block from a bunch of peering points and then tunneling (vpn)
> > parts of it back to customers with sub-/24 assignments. With a broad
> > enough selection of peering points, the routing would not be too
> > inefficient. And it would divorce the IP addresses from the last-mile
> > Internet infrastructure, allowing you to take your addresses with you
> > as long as you kept paying the tunnel company.
>
> Actually, such a service would be much easier to stand up as a bunch
> of virtual routers running on VPS instances in various cloud providers.
> Simple as standing up a VPS running Debian 12 and FRR, then sell
> routed blocks to people.

Sure, depending on the data rates. I do something similar with my own network.

It would be a challenge to push multiple gbps of data this way. Just
because a user's demand for IP addresses is small doesn't mean their
demand for bandwidth is.



> > You're thinking of DRAM. But that's not the way it works. Some routers
> > use heavily parallel routing engines, each of which need enough dram
> > to hold the full forwarding information base and which can suffer from
> > CPU cache exhaustion even then. Others use an expensive kind of memory
> > called a TCAM that's very fast but both expensive and power hungry, so
> > generally not sized for huge numbers of tiny routes.
>
> Trio and Later generations of Juniper MX line cards (which are getting fairly
> long in the tooth these days) can handle more than 5M routes in the FIB.

Maybe. That's where my comment about CPU cache starvation comes into
play. I haven't delved into the Juniper line cards recently so I could
easily be wrong, but if the number of routes being actively used
pushes past the CPU data cache, the cache miss rate will go way up and
it'll start thrashing main memory. The net result is that the
achievable PPS drops by at least an order of magnitude.

No free lunch I'm afraid. The exact characteristics differ, but both
approaches grow rapidly in expense with the size of the forwarding
information base (FIB).

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Saku Ytti]

On Fri, 29 Sept 2023 at 08:24, William Herrin  wrote:

> Maybe. That's where my comment about CPU cache starvation comes into
> play. I haven't delved into the Juniper line cards recently so I could
> easily be wrong, but if the number of routes being actively used
> pushes past the CPU data cache, the cache miss rate will go way up and
> it'll start thrashing main memory. The net result is that the
> achievable PPS drops by at least an order of magnitude.

When you say, you've not delved into the Juniper line cards recently,
to which specific Juniper linecard your comment applies to?

-- 
  ++ytti

ODP: maximum ipv4 bgp prefix length of /24 ?

[Marcin Gondek]

Hi,

For testing/research take a look on dn42.net.

Thanks,

--
Marcin Gondek / Drixter
http://fido.e-utp.net/
AS56662

Od: NANOG  w imieniu użytkownika 
VOLKAN SALİH 
Wysłane: czwartek, 28 września 2023 23:25
Do: nanog@nanog.org 
Temat: maximum ipv4 bgp prefix length of /24 ?


hello,

I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
instead of limiting maximum length to /24..

I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient 
for most of the small and medium sized organizations and also home office 
workers like youtubers, and professional gamers and webmasters!

It is because BGP research and experiment networks can not get /24 due to high 
IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world.

What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do full-table-routing 
also use multi-core routers with lots of RAM? those would probably handle /27s 
and while small networks mostly use default routing, it should be reasonable to 
allow /25-/27?

Thanks for reading, regards..

RE: maximum ipv4 bgp prefix length of /24 ?

[Vasilenko Eduard via NANOG]

Well, it depends.
The question below was evidently related to business.
IPv6 does not have yet a normal way of multihoming for PA prefixes.
If IETF (and some OTTs) would win blocking NAT66,
Then /48 propoisiton is the proposition for PA (to support multihoming).
Unfortunately, it is at least a 10M global routing table as it has been shown 
by Brian Carpenter.
Reminder, The IPv6 scale on all routers is 2x smaller (if people would use DHCP 
and longer than/64 then the scale would drop 2x additionally).
Hence, /48 proposition may become 20x worse for scale than proposed initially 
in this thread.
Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Owen DeLong via NANOG
Sent: Friday, September 29, 2023 7:11 AM
To: VOLKAN SALİH 
Cc: nanog@nanog.org
Subject: Re: maximum ipv4 bgp prefix length of /24 ?

Wouldn’t /48s be a better solution to this need?

Owen



On Sep 28, 2023, at 14:25, VOLKAN SALİH 
mailto:volkan.salih...@gmail.com>> wrote:


hello,

I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
instead of limiting maximum length to /24..

I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient 
for most of the small and medium sized organizations and also home office 
workers like youtubers, and professional gamers and webmasters!

It is because BGP research and experiment networks can not get /24 due to high 
IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world.

What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do full-table-routing 
also use multi-core routers with lots of RAM? those would probably handle /27s 
and while small networks mostly use default routing, it should be reasonable to 
allow /25-/27?

Thanks for reading, regards..

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Tinka]

On 9/28/23 23:25, VOLKAN SALİH wrote:


hello,

I believe, ISPs should also allow ipv4 prefixes with length between 
/25-/27 instead of limiting maximum length to /24..


I also believe that RIRs and LIRs should allocate /27s which has 32 
IPv4 address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s 
are sufficient for most of the small and medium sized organizations 
and also home office workers like youtubers, and professional gamers 
and webmasters!


It is because BGP research and experiment networks can not get /24 due 
to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP 
in IPv4 world.


What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do 
full-table-routing also use multi-core routers with lots of RAM? those 
would probably handle /27s and while small networks mostly use default 
routing, it should be reasonable to allow /25-/27?




RAM is not the issue... it's FIB.

If you pay me for FIB slots, I'm happy to install /32's to your heart's 
content :-).


Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

>
> > Maybe. That's where my comment about CPU cache starvation comes into
> > play. I haven't delved into the Juniper line cards recently so I could
> > easily be wrong, but if the number of routes being actively used
> > pushes past the CPU data cache, the cache miss rate will go way up and
> > it'll start thrashing main memory. The net result is that the
> > achievable PPS drops by at least an order of magnitude.
>
> When you say, you've not delved into the Juniper line cards recently,
> to which specific Juniper linecard your comment applies to?
>

Excellent question.

On Fri, Sep 29, 2023 at 1:30 AM Saku Ytti  wrote:

> On Fri, 29 Sept 2023 at 08:24, William Herrin  wrote:
>
> > Maybe. That's where my comment about CPU cache starvation comes into
> > play. I haven't delved into the Juniper line cards recently so I could
> > easily be wrong, but if the number of routes being actively used
> > pushes past the CPU data cache, the cache miss rate will go way up and
> > it'll start thrashing main memory. The net result is that the
> > achievable PPS drops by at least an order of magnitude.
>
> When you say, you've not delved into the Juniper line cards recently,
> to which specific Juniper linecard your comment applies to?
>
> --
>   ++ytti
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

> On Sep 28, 2023, at 22:29, Saku Ytti  wrote:
> 
> On Fri, 29 Sept 2023 at 08:24, William Herrin  wrote:
> 
>> Maybe. That's where my comment about CPU cache starvation comes into
>> play. I haven't delved into the Juniper line cards recently so I could
>> easily be wrong, but if the number of routes being actively used
>> pushes past the CPU data cache, the cache miss rate will go way up and
>> it'll start thrashing main memory. The net result is that the
>> achievable PPS drops by at least an order of magnitude.
> 

For that to be an issue, packets would need to be CPU switched which isn’t the 
case on the MX platform. 

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

IMO, No. ipv4 is not dead yet. we need to raise it, a bit.

EINAT solutions are OK

The future will come very quickly, right now.

We just need to invest in the internet.


29.09.2023 07:11 tarihinde Owen DeLong yazdı:

Wouldn’t /48s be a better solution to this need?

Owen


On Sep 28, 2023, at 14:25, VOLKAN SALİH  
wrote:


hello,

I believe, ISPs should also allow ipv4 prefixes with length between 
/25-/27 instead of limiting maximum length to /24..


I also believe that RIRs and LIRs should allocate /27s which has 32 
IPv4 address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s 
are sufficient for most of the small and medium sized organizations 
and also home office workers like youtubers, and professional gamers 
and webmasters!


It is because BGP research and experiment networks can not get /24 
due to high IPv4 prices, but they have to get an IPv4 prefix to learn 
BGP in IPv4 world.


What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do 
full-table-routing also use multi-core routers with lots of RAM? 
those would probably handle /27s and while small networks mostly use 
default routing, it should be reasonable to allow /25-/27?


Thanks for reading, regards..

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

Thanks for sharing ideas. I respect them all.


29.09.2023 07:31 tarihinde William Herrin yazdı:

I think you'll convince the IETF to release the Class-E space before
you convince the ISPs to broadly honor sub-/24 prefixes.

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

how would you route 800 Gigabit-ethernet that will soon be released as 
IEEE standart?


we were paying 1 usd per megabit several years ago. now it is as low as 
4 usd cent.


As i said before, the future is coming just now. There must be ways to 
increase CPU caches and memories of routers.


It is also about wholesale. When you buy cheaper routers, powerful 
routers stay expensive.


But when everybody upgrades, memory and processor unit prices decrease.. 
Vendors gain from demand.



29.09.2023 07:31 tarihinde William Herrin yazdı:

Others use an expensive kind of memory
called a TCAM that's very fast but both expensive and power hungry, so
generally not sized for huge numbers of tiny routes.

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

Also keep in mind;

single-homed networks never need full-table..

multi-homed networks could also do default routing just packet-mark 
incoming interface and then route packets out via same interface..


I do not see gain in running BGP full-table, _*excluding*_ networks 
using Intelligent routing optimizers that run jitter and ping tests..


but these are just my ideas.., i respect all ideas.. we are here to 
discuss..


There are people running full-table of v4 and v6 _*just for fun*_... I 
guess it makes them happy when they look thousands of routes available 
on single interface!


I am pretty sure Tier-1 and Tier-2 networks have enough money for 
upgrades. But i may be wrong. What do you think?


Thanks and regards


29.09.2023 07:43 tarihinde VOLKAN SALİH yazdı:


how would you route 800 Gigabit-ethernet that will soon be released as 
IEEE standart?


we were paying 1 usd per megabit several years ago. now it is as low 
as 4 usd cent.


As i said before, the future is coming just now. There must be ways to 
increase CPU caches and memories of routers.


It is also about wholesale. When you buy cheaper routers, powerful 
routers stay expensive.


But when everybody upgrades, memory and processor unit prices 
decrease.. Vendors gain from demand.



29.09.2023 07:31 tarihinde William Herrin yazdı:

Others use an expensive kind of memory
called a TCAM that's very fast but both expensive and power hungry, so
generally not sized for huge numbers of tiny routes.

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

CGNAT is not worse any more, IMHO.

with Endpoint-independent-NAT you can accept incoming connections, as 
soon as you open the port automatically by sending packet to any host. 
Then any host can start connection to your host? thats perfect for 
gamers, streamers, webmasters.. etc.. Allows P2P connections..


for server setups, how many common ports you need to forward? five or 
ten, maybe. not that bad. if it is scripted, then it is automated. if 
its automated then it is not headache for network administrator..


There are just about 50 major NSP networks on the Earth, that needs to 
use BGP full-table.


I presume there would be another 50 big ASNs that belong to CDNs. And I 
am pretty sure those top 100 networks can invest in gear to support /25-/27.


I would suggest Tier3 eyeballs to mark connection depending on incoming 
interface (transit provider). Then route outgoing traffic of connections 
via same interface (TP). Thats all they need to do. if they do not 
optimize BGP based on packetloss rate and latency (performance).


Please Correct me if i am wrong.

Thanks and regards


29.09.2023 07:48 tarihinde Owen DeLong yazdı:
I presume you mean CGNAT? Otherwise, not sure what EINAT is and 
couldn’t find

a reference with a quick google search.

Again agree to disagree. NAT is bad and more NAT is just worse.

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

Can we get single-homed and dual-homed ASN counts worldwide by somebody 
here?


Checking, https://bgp.he.net/country/US , more than half of networks are 
either single-homed or dual-homed.


single-homed networks do not need full-table, for sure. Dual homed 
networks need to buy partial transit from the notorious tier-1.5 network 
that has "NO" (close the doors) peering policy, that you know their 
name.. Then route other traffic via cheapest second Transit Provider..


/BTW, Thanks Mr. M.Leber for shitting in the world-wide IPv6 internet 
(causing segmentation in the IPv6 world), I guess he thinks FREE means 
FEELESS while it means mostly freedom../


/It seems like Mr. M.Leber believes dictatorship instead of freedom. 
Wake up, Nobody have to do peer with you for free (settlement-free), but 
you can negotiate the price/mbps./



29.09.2023 08:01 tarihinde VOLKAN SALİH yazdı:


CGNAT is not worse any more, IMHO.

with Endpoint-independent-NAT you can accept incoming connections, as 
soon as you open the port automatically by sending packet to any host. 
Then any host can start connection to your host? thats perfect for 
gamers, streamers, webmasters.. etc.. Allows P2P connections..


for server setups, how many common ports you need to forward? five or 
ten, maybe. not that bad. if it is scripted, then it is automated. if 
its automated then it is not headache for network administrator..


There are just about 50 major NSP networks on the Earth, that needs to 
use BGP full-table.


I presume there would be another 50 big ASNs that belong to CDNs. And 
I am pretty sure those top 100 networks can invest in gear to support 
/25-/27.


I would suggest Tier3 eyeballs to mark connection depending on 
incoming interface (transit provider). Then route outgoing traffic of 
connections via same interface (TP). Thats all they need to do. if 
they do not optimize BGP based on packetloss rate and latency 
(performance).


Please Correct me if i am wrong.

Thanks and regards


29.09.2023 07:48 tarihinde Owen DeLong yazdı:
I presume you mean CGNAT? Otherwise, not sure what EINAT is and 
couldn’t find

a reference with a quick google search.

Again agree to disagree. NAT is bad and more NAT is just worse.

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

Many people from big companies/networks are either member of NANOG or 
following/reading NANOG from archives.


I was also going to ask if anyone / any company can sponsor (feeless) 
IPv4 /24 prefix for my educational research network? (as209395)


We do not do or allow SPAM/spoofing and other illegal stuff, we have 
RPKI records and check RPKI of BGP peers.


We also consider to have BGP session with HE.net and CogentCo in the 
future, so we can re-announce their single-homed prefixes to each other, 
as charity. For the good of everyone on the internet..


Mr. M.Leber from He.net also stopped feeless BGP tunnel service, as he 
has not seen financial benefit, while still talking about 
community-give-back?! And he still seeks feeless peering from CogentCo, 
you get what you give.whatever goes around comes around


Thanks for reading, best regards and wishes


29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı:


Well, it depends.

The question below was evidently related to business.

IPv6 does not have yet a normal way of multihoming for PA prefixes.

If IETF (and some OTTs) would win blocking NAT66,

Then /48 propoisiton is the proposition for PA (to support multihoming).

Unfortunately, it is at least a 10M global routing table as it has 
been shown by Brian Carpenter.


Reminder, The IPv6 scale on all routers is 2x smaller (if people would 
use DHCP and longer than/64 then the scale would drop 2x additionally).


Hence, /48 proposition may become 20x worse for scale than proposed 
initially in this thread.


Eduard

*From:*NANOG 
[mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] *On 
Behalf Of *Owen DeLong via NANOG

*Sent:* Friday, September 29, 2023 7:11 AM
*To:* VOLKAN SALİH 
*Cc:* nanog@nanog.org
*Subject:* Re: maximum ipv4 bgp prefix length of /24 ?

Wouldn’t /48s be a better solution to this need?

Owen



On Sep 28, 2023, at 14:25, VOLKAN SALİH
 wrote:

hello,

I believe, ISPs should also allow ipv4 prefixes with length
between /25-/27 instead of limiting maximum length to /24..

I also believe that RIRs and LIRs should allocate /27s which has
32 IPv4 address. considering IPv4 world is now mostly NAT'ed, 32
IPv4s are sufficient for most of the small and medium sized
organizations and also home office workers like youtubers, and
professional gamers and webmasters!

It is because BGP research and experiment networks can not get /24
due to high IPv4 prices, but they have to get an IPv4 prefix to
learn BGP in IPv4 world.

What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do
full-table-routing also use multi-core routers with lots of RAM?
those would probably handle /27s and while small networks mostly
use default routing, it should be reasonable to allow /25-/27?

Thanks for reading, regards..

Re: maximum ipv4 bgp prefix length of /24 ?

[Elmar K. Bins]

Volkan,

you are confusing routing and forwarding.

Elmar.

volkan.salih...@gmail.com (VOLKAN SALİH) wrote:

> how would you route 800 Gigabit-ethernet that will soon be released as IEEE
> standart?
>
> we were paying 1 usd per megabit several years ago. now it is as low as 4
> usd cent.
>
> As i said before, the future is coming just now. There must be ways to
> increase CPU caches and memories of routers.
>
> It is also about wholesale. When you buy cheaper routers, powerful routers
> stay expensive.
>
> But when everybody upgrades, memory and processor unit prices decrease..
> Vendors gain from demand.
>
>
> 29.09.2023 07:31 tarihinde William Herrin yazdı:
> > Others use an expensive kind of memory
> > called a TCAM that's very fast but both expensive and power hungry, so
> > generally not sized for huge numbers of tiny routes.

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

>
>
> As i said before, the future is coming just now. There must be ways to
> increase CPU caches and memories of routers.
>
You continue to misstate and misunderstand the issue. I would suggest you
refresh your understanding of the differences between the RIB and FIB in
network devices.


On Fri, Sep 29, 2023 at 12:35 PM VOLKAN SALİH 
wrote:

> how would you route 800 Gigabit-ethernet that will soon be released as
> IEEE standart?
>
> we were paying 1 usd per megabit several years ago. now it is as low as 4
> usd cent.
>
> As i said before, the future is coming just now. There must be ways to
> increase CPU caches and memories of routers.
>
> It is also about wholesale. When you buy cheaper routers, powerful routers
> stay expensive.
>
> But when everybody upgrades, memory and processor unit prices decrease..
> Vendors gain from demand.
>
>
> 29.09.2023 07:31 tarihinde William Herrin yazdı:
>
> Others use an expensive kind of memory
> called a TCAM that's very fast but both expensive and power hungry, so
> generally not sized for huge numbers of tiny routes.
>
>

RE: maximum ipv4 bgp prefix length of /24 ?

[Jason Baugher]

Let me see if I can summarize, tell me where I’m wrong…

You: Give me this for free, give me that for free, sponsor me, why isn’t HE 
giving me something for free, everyone else should spend money to upgrade 
infrastructure to handle my request for /27, but I shouldn’t have to pay for 
anything…

Jason

From: NANOG  On Behalf Of 
VOLKAN SALIH
Sent: Friday, September 29, 2023 2:45 AM
To: Vasilenko Eduard ; Owen DeLong 

Cc: nanog@nanog.org
Subject: Re: maximum ipv4 bgp prefix length of /24 ?

CAUTION: This email is from OUTSIDE our organization.
Please do not open/download any attachment or click any link unless you know 
it's safe.

Many people from big companies/networks are either member of NANOG or 
following/reading NANOG from archives.

I was also going to ask if anyone / any company can sponsor (feeless) IPv4 /24 
prefix for my educational research network? (as209395)

We do not do or allow SPAM/spoofing and other illegal stuff, we have RPKI 
records and check RPKI of BGP peers.

We also consider to have BGP session with HE.net and CogentCo in the future, so 
we can re-announce their single-homed prefixes to each other, as charity. For 
the good of everyone on the internet..

Mr. M.Leber from He.net also stopped feeless BGP tunnel service, as he has not 
seen financial benefit, while still talking about community-give-back?! And he 
still seeks feeless peering from CogentCo, you get what you give.whatever goes 
around comes around

Thanks for reading, best regards and wishes


29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı:
Well, it depends.
The question below was evidently related to business.
IPv6 does not have yet a normal way of multihoming for PA prefixes.
If IETF (and some OTTs) would win blocking NAT66,
Then /48 propoisiton is the proposition for PA (to support multihoming).
Unfortunately, it is at least a 10M global routing table as it has been shown 
by Brian Carpenter.
Reminder, The IPv6 scale on all routers is 2x smaller (if people would use DHCP 
and longer than/64 then the scale would drop 2x additionally).
Hence, /48 proposition may become 20x worse for scale than proposed initially 
in this thread.
Eduard
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Owen DeLong via NANOG
Sent: Friday, September 29, 2023 7:11 AM
To: VOLKAN SALİH <mailto:volkan.salih...@gmail.com>
Cc: nanog@nanog.org<mailto:nanog@nanog.org>
Subject: Re: maximum ipv4 bgp prefix length of /24 ?

Wouldn’t /48s be a better solution to this need?

Owen




On Sep 28, 2023, at 14:25, VOLKAN SALİH 
mailto:volkan.salih...@gmail.com>> wrote:


hello,

I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
instead of limiting maximum length to /24..

I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient 
for most of the small and medium sized organizations and also home office 
workers like youtubers, and professional gamers and webmasters!

It is because BGP research and experiment networks can not get /24 due to high 
IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 world.

What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do full-table-routing 
also use multi-core routers with lots of RAM? those would probably handle /27s 
and while small networks mostly use default routing, it should be reasonable to 
allow /25-/27?

Thanks for reading, regards..


Jason Baugher, Network Operations Manager
405 Emminga Road | PO Box 217 | Golden, IL 62339-0217
P (217) 696-4411 | F (217) 696-4811 | www.adams.net<http://www.adams.net/>
[Adams-Logo]<http://adams.net/>

The information contained in this email message is PRIVILEGED AND CONFIDENTIAL, 
and is intended for the use of the addressee and no one else. If you are not 
the intended recipient, please do not read, distribute, reproduce or use this 
email message (or the attachments) and notify the sender of the mistaken 
transmission. Thank you.

Re: maximum ipv4 bgp prefix length of /24 ?

[Mike Lyon]

Cogent can go fuck themselves. They deserve no charity from Mr. Leber (or 
anyone else, for that matter).

Cogent was the basis for multiple peering wars over the last 20+ years because 
of their greediness.

Cogent illegally scraped ARIN’s records for contact information for their sales 
teams.

Cogent sales reps are the scum of the earth and use relentless sales tactics. 

I refuse to use their services, even they gave it to me free, and ive told them 
that.

Cogent can eat a dick.

-Mike

> On Sep 29, 2023, at 09:44, VOLKAN SALİH  wrote:
> 
> 
> Can we get single-homed and dual-homed ASN counts worldwide by somebody here?
> 
> Checking, https://bgp.he.net/country/US , more than half of networks are 
> either single-homed or dual-homed.
> 
> single-homed networks do not need full-table, for sure. Dual homed networks 
> need to buy partial transit from the notorious tier-1.5 network that has "NO" 
> (close the doors) peering policy, that you know their name.. Then route other 
> traffic via cheapest second Transit Provider..
> 
> BTW, Thanks Mr. M.Leber for shitting in the world-wide IPv6 internet (causing 
> segmentation in the IPv6 world), I guess he thinks FREE means FEELESS while 
> it means mostly freedom..
> 
> It seems like Mr. M.Leber believes dictatorship instead of freedom. Wake up, 
> Nobody have to do peer with you for free (settlement-free), but you can 
> negotiate the price/mbps.
> 
> 
> 
> 29.09.2023 08:01 tarihinde VOLKAN SALİH yazdı:
>> CGNAT is not worse any more, IMHO. 
>> 
>> with Endpoint-independent-NAT you can accept incoming connections, as soon 
>> as you open the port automatically by sending packet to any host. Then any 
>> host can start connection to your host? thats perfect for gamers, streamers, 
>> webmasters.. etc.. Allows P2P connections..
>> 
>> for server setups, how many common ports you need to forward? five or ten, 
>> maybe. not that bad. if it is scripted, then it is automated. if its 
>> automated then it is not headache for network administrator..
>> 
>> There are just about 50 major NSP networks on the Earth, that needs to use 
>> BGP full-table.
>> 
>> I presume there would be another 50 big ASNs that belong to CDNs. And I am 
>> pretty sure those top 100 networks can invest in gear to support /25-/27.
>> 
>> I would suggest Tier3 eyeballs to mark connection depending on incoming 
>> interface (transit provider). Then route outgoing traffic of connections via 
>> same interface (TP). Thats all they need to do. if they do not optimize BGP 
>> based on packetloss rate and latency (performance).
>> 
>> Please Correct me if i am wrong.
>> 
>> Thanks and regards
>> 
>> 
>> 
>> 29.09.2023 07:48 tarihinde Owen DeLong yazdı:
>>> I presume you mean CGNAT? Otherwise, not sure what EINAT is and couldn’t 
>>> find
>>> a reference with a quick google search.
>>> 
>>> Again agree to disagree. NAT is bad and more NAT is just worse.

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

I dont even have money for food/living.

i am working poor.

poverty line is 40 thousands turkish liras here..

but for a green card, I can carve mr leber or mr schaeffer settlement-free!

_*JK!*_

lucifer told me to ask for green card, too.. ;P

you guys become rich this way.. by playing penny pincher.

I asked global firms like Huawei, not some local company called ADAMS!

RIB, FIB doesnt matter, internet is our future, so lets invest in it.


29.09.2023 20:13 tarihinde Jason Baugher yazdı:


Let me see if I can summarize, tell me where I’m wrong…

You: Give me this for free, give me that for free, sponsor me, why 
isn’t HE giving me something for free, everyone else should spend 
money to upgrade infrastructure to handle my request for /27, but I 
shouldn’t have to pay for anything…


Jason

*From:*NANOG  *On 
Behalf Of *VOLKAN SALIH

*Sent:* Friday, September 29, 2023 2:45 AM
*To:* Vasilenko Eduard ; Owen DeLong 


*Cc:* nanog@nanog.org
*Subject:* Re: maximum ipv4 bgp prefix length of /24 ?

CAUTION: This email is from *OUTSIDE* our organization.
Please do not open/download any attachment or click any link unless 
you know it's safe.


Many people from big companies/networks are either member of NANOG or 
following/reading NANOG from archives.


I was also going to ask if anyone / any company can sponsor (feeless) 
IPv4 /24 prefix for my educational research network? (as209395)


We do not do or allow SPAM/spoofing and other illegal stuff, we have 
RPKI records and check RPKI of BGP peers.


We also consider to have BGP session with HE.net and CogentCo in the 
future, so we can re-announce their single-homed prefixes to each 
other, as charity. For the good of everyone on the internet..


Mr. M.Leber from He.net also stopped feeless BGP tunnel service, as he 
has not seen financial benefit, while still talking about 
community-give-back?! And he still seeks feeless peering from 
CogentCo, you get what you give.whatever goes around comes around


Thanks for reading, best regards and wishes

29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı:

Well, it depends.

The question below was evidently related to business.

IPv6 does not have yet a normal way of multihoming for PA prefixes.

If IETF (and some OTTs) would win blocking NAT66,

Then /48 propoisiton is the proposition for PA (to support
multihoming).

Unfortunately, it is at least a 10M global routing table as it has
been shown by Brian Carpenter.

Reminder, The IPv6 scale on all routers is 2x smaller (if people
would use DHCP and longer than/64 then the scale would drop 2x
additionally).

Hence, /48 proposition may become 20x worse for scale than
proposed initially in this thread.

Eduard

*From:*NANOG
[mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org
<mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org>] *On
Behalf Of *Owen DeLong via NANOG
*Sent:* Friday, September 29, 2023 7:11 AM
*To:* VOLKAN SALİH 
<mailto:volkan.salih...@gmail.com>
*Cc:* nanog@nanog.org
    *Subject:* Re: maximum ipv4 bgp prefix length of /24 ?

Wouldn’t /48s be a better solution to this need?

Owen




On Sep 28, 2023, at 14:25, VOLKAN SALİH
 wrote:

hello,

I believe, ISPs should also allow ipv4 prefixes with length
between /25-/27 instead of limiting maximum length to /24..

I also believe that RIRs and LIRs should allocate /27s which
has 32 IPv4 address. considering IPv4 world is now mostly
NAT'ed, 32 IPv4s are sufficient for most of the small and
medium sized organizations and also home office workers like
youtubers, and professional gamers and webmasters!

It is because BGP research and experiment networks can not get
/24 due to high IPv4 prices, but they have to get an IPv4
prefix to learn BGP in IPv4 world.

What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do
full-table-routing also use multi-core routers with lots of
RAM? those would probably handle /27s and while small networks
mostly use default routing, it should be reasonable to allow
/25-/27?

Thanks for reading, regards..


*Jason Baugher, Network Operations Manager*
405 Emminga Road | PO Box 217 | Golden, IL 62339-0217
P (217) 696-4411 | F (217) 696-4811 | *www.adams.net* 
<http://www.adams.net/>

Adams-Logo <http://adams.net/>

The information contained in this email message is PRIVILEGED AND 
CONFIDENTIAL, and is intended for the use of the addressee and no one 
else. If you are not the intended recipient, please do not read, 
distribute, reproduce or use this email message (or the attachments) 
and notify the sender of the mistaken transmission. Thank you.

Re: maximum ipv4 bgp prefix length of /24 ?

[Matthew Petach]

On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH 
wrote:

> [...]
>
> I presume there would be another 50 big ASNs that belong to CDNs. And I am
> pretty sure those top 100 networks can invest in gear to support /25-/27.
>

Volkan,

So far, you haven't presented any good financial reason those top 100
networks should spend millions of dollars to upgrade their networks just so
your /27 can be multihomed.

Sure, they *can* invest in gear to support /25-/27; but they won't, because
there's no financial benefit for them to do so.

I know from *your* side of the table, it would make your life better if
everyone would accept /27 prefixes--multihoming for the masses, yay!

Try standing in their shoes for a minute, though.
You need to spend tens of millions of dollars on a multi-year refresh cycle
to upgrade hundreds of routers in your global backbone, tying up network
engineering resources on upgrades that at the end, will bring you exactly
$0 in additional revenue.

Imagine you're the COO or CTO of a Fortune 500 network, and you're meeting
with your CFO to pitch this idea.
You know your CFO is going to ask one question right off the bat "what's
the timeframe for us to recoup the cost of
this upgrade?" (hint, he's looking for a number less than 40 months).
If your answer is "well, we're never going to recoup the cost.  It won't
bring us any additional customers, it won't bring us any additional
revenue, and it won't make our existing customers any happier with us.  But
it will make it easier for some of our smaller compeitors to sign up new
customers." I can pretty much guarantee your meeting with the CFO will end
right there.

If you want networks to do this, you need to figure out a way for it to
make financial sense for them to do it.

So far, you haven't presented anything that would make it a win-win
scenario for the ISPs and CDNs that would need to upgrade to support this.


ON a separate note--NANOG mailing list admins, I'm noting that Vokan's
emails just arrived a few minutes ago in my gmail inbox.
However,  I saw replies to his messages from others on the list yesterday,
a day before they made it to the general list.
Is there a backed up queue somewhere in the NANOG list processing that is
delaying some messages sent to the list by up to a full day?
If not, I'll just blame gmail for selectively delaying portions of NANOG
for 18+ hours.   ^_^;

Thanks!

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[Robert Blayzor via NANOG]

Trolling NANOG on this subject?

Let me get my popcorn...

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/


On 9/28/23 17:25, VOLKAN SALİH wrote:

hello,

I believe, ISPs should also allow ipv4 prefixes with length between 
/25-/27 instead of limiting maximum length to /24..

Re: maximum ipv4 bgp prefix length of /24 ?

[Ryan Hamel]

Matt,

It's not just you or Google, I just got those emails to my Office 365 at the 
same time. My guess is that the list admins/moderators got the emails and just 
responded without approving the moderated emails.

Ryan


From: NANOG  on behalf of Matthew 
Petach 
Sent: Friday, September 29, 2023 10:31 AM
To: VOLKAN SALİH 
Cc: nanog list 
Subject: Re: maximum ipv4 bgp prefix length of /24 ?

Caution: This is an external email and may be malicious. Please take care when 
clicking links or opening attachments.



On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH 
mailto:volkan.salih...@gmail.com>> wrote:

[...]

I presume there would be another 50 big ASNs that belong to CDNs. And I am 
pretty sure those top 100 networks can invest in gear to support /25-/27.

Volkan,

So far, you haven't presented any good financial reason those top 100 networks 
should spend millions of dollars to upgrade their networks just so your /27 can 
be multihomed.

Sure, they *can* invest in gear to support /25-/27; but they won't, because 
there's no financial benefit for them to do so.

I know from *your* side of the table, it would make your life better if 
everyone would accept /27 prefixes--multihoming for the masses, yay!

Try standing in their shoes for a minute, though.
You need to spend tens of millions of dollars on a multi-year refresh cycle to 
upgrade hundreds of routers in your global backbone, tying up network 
engineering resources on upgrades that at the end, will bring you exactly $0 in 
additional revenue.

Imagine you're the COO or CTO of a Fortune 500 network, and you're meeting with 
your CFO to pitch this idea.
You know your CFO is going to ask one question right off the bat "what's the 
timeframe for us to recoup the cost of
this upgrade?" (hint, he's looking for a number less than 40 months).
If your answer is "well, we're never going to recoup the cost.  It won't bring 
us any additional customers, it won't bring us any additional revenue, and it 
won't make our existing customers any happier with us.  But it will make it 
easier for some of our smaller compeitors to sign up new customers." I can 
pretty much guarantee your meeting with the CFO will end right there.

If you want networks to do this, you need to figure out a way for it to make 
financial sense for them to do it.

So far, you haven't presented anything that would make it a win-win scenario 
for the ISPs and CDNs that would need to upgrade to support this.


ON a separate note--NANOG mailing list admins, I'm noting that Vokan's emails 
just arrived a few minutes ago in my gmail inbox.
However,  I saw replies to his messages from others on the list yesterday, a 
day before they made it to the general list.
Is there a backed up queue somewhere in the NANOG list processing that is 
delaying some messages sent to the list by up to a full day?
If not, I'll just blame gmail for selectively delaying portions of NANOG for 
18+ hours.   ^_^;

Thanks!

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[Valerie Wittkop]

There is one person that reviews the moderation queue of the NANOG list. My 
morning was rather hectic, and I didn’t get to the queue until just before 
12:30 EDT today. 

Apologies to all for the delay in the messages of this thread. Please note  I 
try to check the queue a few times throughout the day, and one last time again 
before I shut down for the night. 


Valerie Wittkop
Program Director
vwitt...@nanog.org | +1 734-730-0225 (mobile) | www.nanog.org
NANOG | 305 E. Eisenhower Pkwy, Suite 100 | Ann Arbor, MI 48108, USA
ASN 19230

> On Sep 29, 2023, at 13:36, Ryan Hamel  wrote:
> 
> Matt,
> 
> It's not just you or Google, I just got those emails to my Office 365 at the 
> same time. My guess is that the list admins/moderators got the emails and 
> just responded without approving the moderated emails.
> 
> Ryan
> 
> From: NANOG  <mailto:nanog-bounces+ryan=rkhtech@nanog.org>> on behalf of Matthew 
> Petach mailto:mpet...@netflight.com>>
> Sent: Friday, September 29, 2023 10:31 AM
> To: VOLKAN SALİH  <mailto:volkan.salih...@gmail.com>>
> Cc: nanog list mailto:nanog@nanog.org>>
> Subject: Re: maximum ipv4 bgp prefix length of /24 ?
>  
> Caution: This is an external email and may be malicious. Please take care 
> when clicking links or opening attachments.
> 
> 
> 
> On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH  <mailto:volkan.salih...@gmail.com>> wrote:
> [...]
> I presume there would be another 50 big ASNs that belong to CDNs. And I am 
> pretty sure those top 100 networks can invest in gear to support /25-/27.
> 
> Volkan,
> 
> So far, you haven't presented any good financial reason those top 100 
> networks should spend millions of dollars to upgrade their networks just so 
> your /27 can be multihomed.
> 
> Sure, they *can* invest in gear to support /25-/27; but they won't, because 
> there's no financial benefit for them to do so.
> 
> I know from *your* side of the table, it would make your life better if 
> everyone would accept /27 prefixes--multihoming for the masses, yay!
> 
> Try standing in their shoes for a minute, though. 
> You need to spend tens of millions of dollars on a multi-year refresh cycle 
> to upgrade hundreds of routers in your global backbone, tying up network 
> engineering resources on upgrades that at the end, will bring you exactly $0 
> in additional revenue.
> 
> Imagine you're the COO or CTO of a Fortune 500 network, and you're meeting 
> with your CFO to pitch this idea.
> You know your CFO is going to ask one question right off the bat "what's the 
> timeframe for us to recoup the cost of
> this upgrade?" (hint, he's looking for a number less than 40 months).
> If your answer is "well, we're never going to recoup the cost.  It won't 
> bring us any additional customers, it won't bring us any additional revenue, 
> and it won't make our existing customers any happier with us.  But it will 
> make it easier for some of our smaller compeitors to sign up new customers." 
> I can pretty much guarantee your meeting with the CFO will end right there.
> 
> If you want networks to do this, you need to figure out a way for it to make 
> financial sense for them to do it.
> 
> So far, you haven't presented anything that would make it a win-win scenario 
> for the ISPs and CDNs that would need to upgrade to support this.
> 
> 
> ON a separate note--NANOG mailing list admins, I'm noting that Vokan's emails 
> just arrived a few minutes ago in my gmail inbox.
> However,  I saw replies to his messages from others on the list yesterday, a 
> day before they made it to the general list.
> Is there a backed up queue somewhere in the NANOG list processing that is 
> delaying some messages sent to the list by up to a full day?
> If not, I'll just blame gmail for selectively delaying portions of NANOG for 
> 18+ hours.   ^_^;
> 
> Thanks!
> 
> Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

thanks for your response. Honestly thanks for everyones reponses.

comunism is the future. IMO.

tier-1 network count is decreasing. competition is always good. while 
monopoly, duopoly, triopoly is not.. I dream an earth with 1000 tier-1 
networks..


capitalism give people more money than they can spend in their lifetime 
with their families, but it doesnt give people happiness and health..


for example, if i were level3 or telia CEO or should I have been major 
stakeholder? I would like to see 50 or 1000 more tier-1 networks 
competing with us.


Money is not everything. After some time capitalist bourgeois realize 
that they could not "earn" health or happiness and start spending their 
pennies to charities,


because if we wouldnt believe heaven and hell and purgatory, what else 
we could believe? Should we believe that after death nothing left from 
the earth, we worked for nothing, we laughed for nothing, we cried for 
nothing, and we married for nothing?


NOPE.

Everyone is equal, in the god's/lord's/creator's vision. You need to 
work on comunism instead of capitalism..


I do not care what CFO/CTO/CEO/CXO thinks! they are more miserable than 
me..! I am healthy and happy. They are not. They can not be. I just 
expressed my opinions, finalized them with a bad joke. ;D


You can continue your feasibility reports, net profit margin , return of 
investment calculations, but the god doesnt care IMO, and you will not 
care after you are 70-80 years.old.


Best regards and wishes for you all

I guess i made myself clear.

Development is the only way. in all aspects.

29.09.2023 20:31 tarihinde Matthew Petach yazdı:



On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH 
 wrote:


[...]

I presume there would be another 50 big ASNs that belong to CDNs.
And I am pretty sure those top 100 networks can invest in gear to
support /25-/27.


Volkan,

So far, you haven't presented any good financial reason those top 100 
networks should spend millions of dollars to upgrade their networks 
just so your /27 can be multihomed.


Sure, they *can* invest in gear to support /25-/27; but they won't, 
because there's no financial benefit for them to do so.


I know from *your* side of the table, it would make your life better 
if everyone would accept /27 prefixes--multihoming for the masses, yay!


Try standing in their shoes for a minute, though.
You need to spend tens of millions of dollars on a multi-year refresh 
cycle to upgrade hundreds of routers in your global backbone, tying up 
network engineering resources on upgrades that at the end, will bring 
you exactly $0 in additional revenue.


Imagine you're the COO or CTO of a Fortune 500 network, and you're 
meeting with your CFO to pitch this idea.
You know your CFO is going to ask one question right off the bat 
"what's the timeframe for us to recoup the cost of

this upgrade?" (hint, he's looking for a number less than 40 months).
If your answer is "well, we're never going to recoup the cost.  It 
won't bring us any additional customers, it won't bring us any 
additional revenue, and it won't make our existing customers any 
happier with us.  But it will make it easier for some of our smaller 
compeitors to sign up new customers." I can pretty much guarantee your 
meeting with the CFO will end right there.


If you want networks to do this, you need to figure out a way for it 
to make financial sense for them to do it.


So far, you haven't presented anything that would make it a win-win 
scenario for the ISPs and CDNs that would need to upgrade to support this.



ON a separate note--NANOG mailing list admins, I'm noting that Vokan's 
emails just arrived a few minutes ago in my gmail inbox.
However,  I saw replies to his messages from others on the list 
yesterday, a day before they made it to the general list.
Is there a backed up queue somewhere in the NANOG list processing that 
is delaying some messages sent to the list by up to a full day?
If not, I'll just blame gmail for selectively delaying portions of 
NANOG for 18+ hours.   ^_^;


Thanks!

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

>
> RIB, FIB doesnt matter, internet is our future, so lets invest in it.
>

Uh, ok.

On Fri, Sep 29, 2023 at 1:25 PM VOLKAN SALİH 
wrote:

> I dont even have money for food/living.
>
> i am working poor.
>
> poverty line is 40 thousands turkish liras here..
>
> but for a green card, I can carve mr leber or mr schaeffer settlement-free!
>
> *JK!*
>
> lucifer told me to ask for green card, too.. ;P
>
> you guys become rich this way.. by playing penny pincher.
>
> I asked global firms like Huawei, not some local company called ADAMS!
>
> RIB, FIB doesnt matter, internet is our future, so lets invest in it.
>
>
> 29.09.2023 20:13 tarihinde Jason Baugher yazdı:
>
> Let me see if I can summarize, tell me where I’m wrong…
>
>
>
> You: Give me this for free, give me that for free, sponsor me, why isn’t
> HE giving me something for free, everyone else should spend money to
> upgrade infrastructure to handle my request for /27, but I shouldn’t have
> to pay for anything…
>
>
>
> Jason
>
>
>
> *From:* NANOG 
>  *On Behalf Of *VOLKAN
> SALIH
> *Sent:* Friday, September 29, 2023 2:45 AM
> *To:* Vasilenko Eduard 
> ; Owen DeLong 
> 
> *Cc:* nanog@nanog.org
> *Subject:* Re: maximum ipv4 bgp prefix length of /24 ?
>
>
>
> CAUTION: This email is from *OUTSIDE* our organization.
> Please do not open/download any attachment or click any link unless you
> know it's safe.
>
> Many people from big companies/networks are either member of NANOG or
> following/reading NANOG from archives.
>
> I was also going to ask if anyone / any company can sponsor (feeless) IPv4
> /24 prefix for my educational research network? (as209395)
>
> We do not do or allow SPAM/spoofing and other illegal stuff, we have RPKI
> records and check RPKI of BGP peers.
>
> We also consider to have BGP session with HE.net and CogentCo in the
> future, so we can re-announce their single-homed prefixes to each other, as
> charity. For the good of everyone on the internet..
>
> Mr. M.Leber from He.net also stopped feeless BGP tunnel service, as he has
> not seen financial benefit, while still talking about community-give-back?!
> And he still seeks feeless peering from CogentCo, you get what you
> give.whatever goes around comes around
>
> Thanks for reading, best regards and wishes
>
>
>
> 29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı:
>
> Well, it depends.
>
> The question below was evidently related to business.
>
> IPv6 does not have yet a normal way of multihoming for PA prefixes.
>
> If IETF (and some OTTs) would win blocking NAT66,
>
> Then /48 propoisiton is the proposition for PA (to support multihoming).
>
> Unfortunately, it is at least a 10M global routing table as it has been
> shown by Brian Carpenter.
>
> Reminder, The IPv6 scale on all routers is 2x smaller (if people would use
> DHCP and longer than/64 then the scale would drop 2x additionally).
>
> Hence, /48 proposition may become 20x worse for scale than proposed
> initially in this thread.
>
> Eduard
>
> *From:* NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org
> ] *On Behalf Of *Owen
> DeLong via NANOG
> *Sent:* Friday, September 29, 2023 7:11 AM
> *To:* VOLKAN SALİH  
> *Cc:* nanog@nanog.org
> *Subject:* Re: maximum ipv4 bgp prefix length of /24 ?
>
>
>
> Wouldn’t /48s be a better solution to this need?
>
>
>
> Owen
>
>
>
>
>
>
> On Sep 28, 2023, at 14:25, VOLKAN SALİH  wrote:
>
>
>
> hello,
>
> I believe, ISPs should also allow ipv4 prefixes with length between
> /25-/27 instead of limiting maximum length to /24..
>
> I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4
> address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are
> sufficient for most of the small and medium sized organizations and also
> home office workers like youtubers, and professional gamers and webmasters!
>
> It is because BGP research and experiment networks can not get /24 due to
> high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4
> world.
>
> What do you think about this?
>
> What could be done here?
>
> Is it unacceptable; considering most big networks that do
> full-table-routing also use multi-core routers with lots of RAM? those
> would probably handle /27s and while small networks mostly use default
> routing, it should be reasonable to allow /25-/27?
>
> Thanks for reading, regards..
>
>
>
>
> *Jason Baugher, Network Operations Manager*
> 405 Emminga Road | PO Box 217 | Golden, IL 62339-0217
> P (217) 696-4411 | F (217) 696-4811 | *www.adams.net*
> <http://www.adams.net/>
> [image: Adams-Logo] <http://adams.net/>
> --
> The information contained in this email message is PRIVILEGED AND
> CONFIDENTIAL, and is intended for the use of the addressee and no one else.
> If you are not the intended recipient, please do not read, distribute,
> reproduce or use this email message (or the attachments) and notify the
> sender of the mistaken transmission. Thank you.
>
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

>
> word salad


None of this has anything to do with why the IPv4 /24 limit is what it is.

Good luck with your endeavors, whatever they may be.

On Fri, Sep 29, 2023 at 1:46 PM VOLKAN SALİH 
wrote:

> thanks for your response. Honestly thanks for everyones reponses.
>
> comunism is the future. IMO.
>
> tier-1 network count is decreasing. competition is always good. while
> monopoly, duopoly, triopoly is not.. I dream an earth with 1000 tier-1
> networks..
>
> capitalism give people more money than they can spend in their lifetime
> with their families, but it doesnt give people happiness and health..
>
> for example, if i were level3 or telia CEO or should I have been major
> stakeholder? I would like to see 50 or 1000 more tier-1 networks competing
> with us.
>
> Money is not everything. After some time capitalist bourgeois realize that
> they could not "earn" health or happiness and start spending their pennies
> to charities,
>
> because if we wouldnt believe heaven and hell and purgatory, what else we
> could believe? Should we believe that after death nothing left from the
> earth, we worked for nothing, we laughed for nothing, we cried for nothing,
> and we married for nothing?
>
> NOPE.
>
> Everyone is equal, in the god's/lord's/creator's vision. You need to work
> on comunism instead of capitalism..
>
> I do not care what CFO/CTO/CEO/CXO thinks! they are more miserable than
> me..! I am healthy and happy. They are not. They can not be. I just
> expressed my opinions, finalized them with a bad joke. ;D
>
> You can continue your feasibility reports, net profit margin , return of
> investment calculations, but the god doesnt care IMO, and you will not care
> after you are 70-80 years.old.
>
> Best regards and wishes for you all
>
> I guess i made myself clear.
>
> Development is the only way. in all aspects.
> 29.09.2023 20:31 tarihinde Matthew Petach yazdı:
>
>
>
> On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH 
> wrote:
>
>> [...]
>>
>> I presume there would be another 50 big ASNs that belong to CDNs. And I
>> am pretty sure those top 100 networks can invest in gear to support /25-/27.
>>
>
> Volkan,
>
> So far, you haven't presented any good financial reason those top 100
> networks should spend millions of dollars to upgrade their networks just so
> your /27 can be multihomed.
>
> Sure, they *can* invest in gear to support /25-/27; but they won't,
> because there's no financial benefit for them to do so.
>
> I know from *your* side of the table, it would make your life better if
> everyone would accept /27 prefixes--multihoming for the masses, yay!
>
> Try standing in their shoes for a minute, though.
> You need to spend tens of millions of dollars on a multi-year refresh
> cycle to upgrade hundreds of routers in your global backbone, tying up
> network engineering resources on upgrades that at the end, will bring you
> exactly $0 in additional revenue.
>
> Imagine you're the COO or CTO of a Fortune 500 network, and you're meeting
> with your CFO to pitch this idea.
> You know your CFO is going to ask one question right off the bat "what's
> the timeframe for us to recoup the cost of
> this upgrade?" (hint, he's looking for a number less than 40 months).
> If your answer is "well, we're never going to recoup the cost.  It won't
> bring us any additional customers, it won't bring us any additional
> revenue, and it won't make our existing customers any happier with us.  But
> it will make it easier for some of our smaller compeitors to sign up new
> customers." I can pretty much guarantee your meeting with the CFO will end
> right there.
>
> If you want networks to do this, you need to figure out a way for it to
> make financial sense for them to do it.
>
> So far, you haven't presented anything that would make it a win-win
> scenario for the ISPs and CDNs that would need to upgrade to support this.
>
>
> ON a separate note--NANOG mailing list admins, I'm noting that Vokan's
> emails just arrived a few minutes ago in my gmail inbox.
> However,  I saw replies to his messages from others on the list yesterday,
> a day before they made it to the general list.
> Is there a backed up queue somewhere in the NANOG list processing that is
> delaying some messages sent to the list by up to a full day?
> If not, I'll just blame gmail for selectively delaying portions of NANOG
> for 18+ hours.   ^_^;
>
> Thanks!
>
> Matt
>
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Mike Lyon]

Apparently i ruffled some feathers with my reply about Cogent.My apologies to the list for my blunt reply…Y’all have a good weekend now.-MikeOn Sep 29, 2023, at 10:43, Valerie Wittkop  wrote:There is one person that reviews the moderation queue of the NANOG list. My morning was rather hectic, and I didn’t get to the queue until just before 12:30 EDT today. Apologies to all for the delay in the messages of this thread. Please note  I try to check the queue a few times throughout the day, and one last time again before I shut down for the night. 
Valerie WittkopProgram Directorvwitt...@nanog.org | +1 734-730-0225 (mobile) | www.nanog.orgNANOG | 305 E. Eisenhower Pkwy, Suite 100 | Ann Arbor, MI 48108, USAASN 19230

On Sep 29, 2023, at 13:36, Ryan Hamel  wrote:Matt,It's not just you or Google, I just got those emails to my Office 365 at the same time. My guess is that the list admins/moderators got the emails and just responded without approving the moderated emails.RyanFrom: NANOG <nanog-bounces+ryan=rkhtech@nanog.org> on behalf of Matthew Petach <mpet...@netflight.com>Sent: Friday, September 29, 2023 10:31 AMTo: VOLKAN SALİH <volkan.salih...@gmail.com>Cc: nanog list <nanog@nanog.org>Subject: Re: maximum ipv4 bgp prefix length of /24 ? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH <volkan.salih...@gmail.com> wrote:[...]I presume there would be another 50 big ASNs that belong to CDNs. And I am pretty sure those top 100 networks can invest in gear to support /25-/27.Volkan,So far, you haven't presented any good financial reason those top 100 networks should spend millions of dollars to upgrade their networks just so your /27 can be multihomed.Sure, they *can* invest in gear to support /25-/27; but they won't, because there's no financial benefit for them to do so.I know from *your* side of the table, it would make your life better if everyone would accept /27 prefixes--multihoming for the masses, yay!Try standing in their shoes for a minute, though. You need to spend tens of millions of dollars on a multi-year refresh cycle to upgrade hundreds of routers in your global backbone, tying up network engineering resources on upgrades that at the end, will bring you exactly $0 in additional revenue.Imagine you're the COO or CTO of a Fortune 500 network, and you're meeting with your CFO to pitch this idea.You know your CFO is going to ask one question right off the bat "what's the timeframe for us to recoup the cost ofthis upgrade?" (hint, he's looking for a number less than 40 months).If your answer is "well, we're never going to recoup the cost.  It won't bring us any additional customers, it won't bring us any additional revenue, and it won't make our existing customers any happier with us.  But it will make it easier for some of our smaller compeitors to sign up new customers." I can pretty much guarantee your meeting with the CFO will end right there.If you want networks to do this, you need to figure out a way for it to make financial sense for them to do it.So far, you haven't presented anything that would make it a win-win scenario for the ISPs and CDNs that would need to upgrade to support this.ON a separate note--NANOG mailing list admins, I'm noting that Vokan's emails just arrived a few minutes ago in my gmail inbox.However,  I saw replies to his messages from others on the list yesterday, a day before they made it to the general list.Is there a backed up queue somewhere in the NANOG list processing that is delaying some messages sent to the list by up to a full day?If not, I'll just blame gmail for selectively delaying portions of NANOG for 18+ hours.   ^_^;Thanks!Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[Matthew Petach]

On Fri, Sep 29, 2023 at 10:42 AM Valerie Wittkop  wrote:

> There is one person that reviews the moderation queue of the NANOG list.
> My morning was rather hectic, and I didn’t get to the queue until just
> before 12:30 EDT today.
>
> Apologies to all for the delay in the messages of this thread. Please note
>  I try to check the queue a few times throughout the day, and one last time
> again before I shut down for the night.
>


Ah, no worries, Valerie--I know how challenging it can be handling a task
like that.
Thank you for all your hard work on it!

I'm just curious how Owen was able to see and respond to the messages in
the thread before they were sent out to the rest of the list.  ^_^;

Perhaps he's got some super-sekret backdoor access?  Or is this a case
where interacting with Discourse gives one a leg up on the rest of the list?
(I notice I can see messages showing up in the Discourse mirror well before
they make it to my inbox).

Thank you again for the quick reply, and all the great work you do for the
community, Valerie--you totally ROCK!  :)

Thanks!

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[VOLKAN SALİH]

word salad?

example; russia decided that they are powerful enough, they are not now 
eating UA. They will never stop, coz Thats how world wars start.


Now big network operators decided that they can destroy small 
competitors by mergers, acquitions, restrictive or "NO" peering 
policies.. and ofc price wars. You can think that We talk Network 
operators aspect of world war in telecommunications.


example; some tier-1 acquires some tier-2. and  FCC withdraws net 
neutrality rules. IMO; you all are done, as you accepted their decisions 
and didnt question them?!.. If i were in your country i would send you 
best calculator available on stores for your HAPPINESS!


and you tell me to shut up! I didnt not. IMO, Everyone understood me. 
Competition is good. Even if hungry people like you thinks BAD for just 
yourself.


byé byé


29.09.2023 20:50 tarihinde Tom Beecher yazdı:


word salad 



None of this has anything to do with why the IPv4 /24 limit is what it 
is.


Good luck with your endeavors, whatever they may be.

On Fri, Sep 29, 2023 at 1:46 PM VOLKAN SALİH 
 wrote:


thanks for your response. Honestly thanks for everyones reponses.

comunism is the future. IMO.

tier-1 network count is decreasing. competition is always good.
while monopoly, duopoly, triopoly is not.. I dream an earth with
1000 tier-1 networks..

capitalism give people more money than they can spend in their
lifetime with their families, but it doesnt give people happiness
and health..

for example, if i were level3 or telia CEO or should I have been
major stakeholder? I would like to see 50 or 1000 more tier-1
networks competing with us.

Money is not everything. After some time capitalist bourgeois
realize that they could not "earn" health or happiness and start
spending their pennies to charities,

because if we wouldnt believe heaven and hell and purgatory, what
else we could believe? Should we believe that after death nothing
left from the earth, we worked for nothing, we laughed for
nothing, we cried for nothing, and we married for nothing?

NOPE.

Everyone is equal, in the god's/lord's/creator's vision. You need
to work on comunism instead of capitalism..

I do not care what CFO/CTO/CEO/CXO thinks! they are more miserable
than me..! I am healthy and happy. They are not. They can not be.
I just expressed my opinions, finalized them with a bad joke. ;D

You can continue your feasibility reports, net profit margin ,
return of investment calculations, but the god doesnt care IMO,
and you will not care after you are 70-80 years.old.

Best regards and wishes for you all

I guess i made myself clear.

Development is the only way. in all aspects.

29.09.2023 20:31 tarihinde Matthew Petach yazdı:



On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH
 wrote:

[...]

I presume there would be another 50 big ASNs that belong to
CDNs. And I am pretty sure those top 100 networks can invest
in gear to support /25-/27.


Volkan,

So far, you haven't presented any good financial reason those top
100 networks should spend millions of dollars to upgrade their
networks just so your /27 can be multihomed.

Sure, they *can* invest in gear to support /25-/27; but they
won't, because there's no financial benefit for them to do so.

I know from *your* side of the table, it would make your life
better if everyone would accept /27 prefixes--multihoming for the
masses, yay!

Try standing in their shoes for a minute, though.
You need to spend tens of millions of dollars on a multi-year
refresh cycle to upgrade hundreds of routers in your global
backbone, tying up network engineering resources on upgrades that
at the end, will bring you exactly $0 in additional revenue.

Imagine you're the COO or CTO of a Fortune 500 network, and
you're meeting with your CFO to pitch this idea.
You know your CFO is going to ask one question right off the bat
"what's the timeframe for us to recoup the cost of
this upgrade?" (hint, he's looking for a number less than 40 months).
If your answer is "well, we're never going to recoup the cost. 
It won't bring us any additional customers, it won't bring us any
additional revenue, and it won't make our existing customers any
happier with us.  But it will make it easier for some of our
smaller compeitors to sign up new customers." I can pretty much
guarantee your meeting with the CFO will end right there.

If you want networks to do this, you need to figure out a way for
it to make financial sense for them to do it.

So far, you haven't presented anything that would make it a
win-win scenario for the ISPs and CDNs that would need to upgrade
to support this.


ON a separate note--NANOG mailing list admins, I'm noting that
Vokan's emails just arriv

RE: maximum ipv4 bgp prefix length of /24 ?

[Dominik Dobrowolski (dodobrow) via NANOG]

Please, let’s keep politics out of nanog…



Kind Regards
Dominik

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/cisco_email_sigs_08.jpg]
Dominik Dobrowolski
Technical Consulting Engineer
dodob...@cisco.com<mailto:dodob...@cisco.com>
Tel: +48 12 321 29 03
Cisco Systems Poland Sp. z o. o.
Poland
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Update 
Profile<%20https:/www.cisco.com/c/en/us/about/help/login-account-help.html#~profile>
 - Privacy<http://www.cisco.com/web/siteassets/legal/privacy.html>
Please click 
here<http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html>
 for Company Registration

From: NANOG  On Behalf Of VOLKAN 
SALIH
Sent: Friday, September 29, 2023 7:59 PM
To: Tom Beecher 
Cc: nanog list 
Subject: Re: maximum ipv4 bgp prefix length of /24 ?


word salad?

example; russia decided that they are powerful enough, they are not now eating 
UA. They will never stop, coz Thats how world wars start.

Now big network operators decided that they can destroy small competitors by 
mergers, acquitions, restrictive or "NO" peering policies.. and ofc price wars. 
You can think that We talk Network operators aspect of world war in 
telecommunications.

example; some tier-1 acquires some tier-2. and  FCC withdraws net neutrality 
rules. IMO; you all are done, as you accepted their decisions and didnt 
question them?!.. If i were in your country i would send you best calculator 
available on stores for your HAPPINESS!

and you tell me to shut up! I didnt not. IMO, Everyone understood me. 
Competition is good. Even if hungry people like you thinks BAD for just 
yourself.

byé byé


29.09.2023 20:50 tarihinde Tom Beecher yazdı:
word salad

None of this has anything to do with why the IPv4 /24 limit is what it is.

Good luck with your endeavors, whatever they may be.

On Fri, Sep 29, 2023 at 1:46 PM VOLKAN SALİH 
mailto:volkan.salih...@gmail.com>> wrote:

thanks for your response. Honestly thanks for everyones reponses.

comunism is the future. IMO.

tier-1 network count is decreasing. competition is always good. while monopoly, 
duopoly, triopoly is not.. I dream an earth with 1000 tier-1 networks..

capitalism give people more money than they can spend in their lifetime with 
their families, but it doesnt give people happiness and health..

for example, if i were level3 or telia CEO or should I have been major 
stakeholder? I would like to see 50 or 1000 more tier-1 networks competing with 
us.

Money is not everything. After some time capitalist bourgeois realize that they 
could not "earn" health or happiness and start spending their pennies to 
charities,

because if we wouldnt believe heaven and hell and purgatory, what else we could 
believe? Should we believe that after death nothing left from the earth, we 
worked for nothing, we laughed for nothing, we cried for nothing, and we 
married for nothing?

NOPE.

Everyone is equal, in the god's/lord's/creator's vision. You need to work on 
comunism instead of capitalism..

I do not care what CFO/CTO/CEO/CXO thinks! they are more miserable than me..! I 
am healthy and happy. They are not. They can not be. I just expressed my 
opinions, finalized them with a bad joke. ;D

You can continue your feasibility reports, net profit margin , return of 
investment calculations, but the god doesnt care IMO, and you will not care 
after you are 70-80 years.old.

Best regards and wishes for you all

I guess i made myself clear.

Development is the only way. in all aspects.
29.09.2023 20:31 tarihinde Matthew Petach yazdı:


On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH 
mailto:volkan.salih...@gmail.com>> wrote:

[...]

I presume there would be another 50 big ASNs that belong to CDNs. And I am 
pretty sure those top 100 networks can invest in gear to support /25-/27.

Volkan,

So far, you haven't presented any good financial reason those top 100 networks 
should spend millions of dollars to upgrade their networks just so your /27 can 
be multihomed.

Sure, they *can* invest in gear to support /25-/27; but they won't, because 
there's no financial benefit for them to do so.

I know from *your* side of the table, it would make your life better if 
everyone would accept /27 prefixes--multihoming for the masses, yay!

Try standing in their shoes for a minute, though.
You need to spend tens of millions of dollars on a multi-year refresh cycle to 
upgrade hundreds of routers in your global backbone, tying up network 
engineering resources on upgrades that at the end, will bring you exactly $0 in 
a

Re: maximum ipv4 bgp prefix length of /24 ?

[Robert Blayzor via NANOG]

On 9/29/23 03:34, Mark Tinka wrote:

RAM is not the issue... it's FIB.

If you pay me for FIB slots, I'm happy to install /32's to your heart's 
content 🙂.



And convergence times to process all that extra noise...

The line in the sand has been drawn; just say no to >/24 ...

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Re: maximum ipv4 bgp prefix length of /24 ?

[Matthew Petach]

On Fri, Sep 29, 2023 at 10:43 AM VOLKAN SALİH 
wrote:

> thanks for your response. Honestly thanks for everyones reponses.
>
> comunism is the future. IMO.
>
> tier-1 network count is decreasing. competition is always good. while
> monopoly, duopoly, triopoly is not.. I dream an earth with 1000 tier-1
> networks..
>
> capitalism give people more money than they can spend in their lifetime
> with their families, but it doesnt give people happiness and health..
>
> for example, if i were level3 or telia CEO or should I have been major
> stakeholder? I would like to see 50 or 1000 more tier-1 networks competing
> with us.
>
> Money is not everything. After some time capitalist bourgeois realize that
> they could not "earn" health or happiness and start spending their pennies
> to charities,
>

Volkan,

You make a good point here.   I asked you to come up with a win-win
scenario that would persuade the financial people at the top 100 networks
why they should spend money to upgrade their networks for you.

I hadn't considered the charity option.

If you can organize your work as a non-profit charity, you may find there
are entities that will sponsor the number resource needs of your non-profit
charity.
That would be one way to achieve what you're looking for without having to
make a revenue-based pitch to 100 different CFOs.


> because if we wouldnt believe heaven and hell and purgatory, what else we
> could believe? Should we believe that after death nothing left from the
> earth, we worked for nothing, we laughed for nothing, we cried for nothing,
> and we married for nothing?
>
> NOPE.
>
> Everyone is equal, in the god's/lord's/creator's vision. You need to work
> on comunism instead of capitalism..
>
> I do not care what CFO/CTO/CEO/CXO thinks! they are more miserable than
> me..! I am healthy and happy. They are not. They can not be. I just
> expressed my opinions, finalized them with a bad joke. ;D
>
> You can continue your feasibility reports, net profit margin , return of
> investment calculations, but the god doesnt care IMO, and you will not care
> after you are 70-80 years.old.
>

I think the CFO would be quite happy if god were to show up and explain the
cost-benefit analysis of performing the network upgrades you are asking for.

...not so much because of what it would mean for the company's quarterly
numbers, but what it would mean for them on the daytime television circuit.
I mean, you can't *buy* that level of publicity!

"Today on The Talk--the CFO that met god...and lived to tell about it!"

Heck, after a meeting like that, I'd just retire from finance, and rake in
the money from the talk show appearances.  ;)


On a slightly more serious note--communism doesn't work when it comes to
network upgrades.  *someone* has to buy the router upgrades, and Juniper
doesn't accept "the will of the people" as a valid form of payment.

Like it or not, money makes the (networking) world go around, and without
it, new hardware isn't just going to show up on your doorstep.


Now, if you want, we can have a more serious discussion about *why*
backbone routers cost so much, and why quadrupling the size of the
forwarding table really makes such a big impact on the cost of a router.
But to have that discussion, I'm afraid we're going to have to leave god
out of it, and instead invite Mssrs Newton, Bernoulli, and Euler to the
table to go into some serious math about air flow, heat transfer, and
thermodynamics.   ^_^;

Thanks!

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[Seth Mattinen via NANOG]

On 9/29/23 10:24, VOLKAN SALİH wrote:


you guys become rich this way.. by playing penny pincher.

I asked global firms like Huawei, not some local company called ADAMS!




You joined the wrong mailing list then. This is NANOG, which has 
companies of all sizes and private individuals operating networks. This 
is not a "global firms" mailing list.

Re: maximum ipv4 bgp prefix length of /24 ?

[Collider]

This thread is utter amateur hour. I too would rather /32s be valid in the DFZ 
- but they're not, for good reason (worstcase scenario = circa 4 bln. routing 
table entries - no BGP hwaccel can swing that!).

Le 29 septembre 2023 19:51:29 UTC, Seth Mattinen via NANOG  a 
écrit :
>On 9/29/23 10:24, VOLKAN SALİH wrote:
>> 
>> you guys become rich this way.. by playing penny pincher.
>> 
>> I asked global firms like Huawei, not some local company called ADAMS!
>> 
>
>
>You joined the wrong mailing list then. This is NANOG, which has companies of 
>all sizes and private individuals operating networks. This is not a "global 
>firms" mailing list.
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Thu, Sep 28, 2023 at 10:29 PM Saku Ytti  wrote:
> On Fri, 29 Sept 2023 at 08:24, William Herrin  wrote:
> > Maybe. That's where my comment about CPU cache starvation comes into
> > play. I haven't delved into the Juniper line cards recently so I could
> > easily be wrong, but if the number of routes being actively used
> > pushes past the CPU data cache, the cache miss rate will go way up and
> > it'll start thrashing main memory. The net result is that the
> > achievable PPS drops by at least an order of magnitude.
>
> When you say, you've not delved into the Juniper line cards recently,
> to which specific Juniper linecard your comment applies to?

Howdy,

My understanding of Juniper's approach to the problem is that instead
of employing TCAMs for next-hop lookup, they use general purpose CPUs
operating on a radix tree, exactly as you would for an all-software
router. This makes each lookup much slower than a TCAM can achieve.
However, that doesn't matter much: the lookup delays are much shorter
than the transmission delays so it's not noticeable to the user. To
achieve an -aggregate- lookup speed comparable to a TCAM, they
implement a bunch of these lookup engines as dedicated parallel
subprocessors rather than using the router's primary compute engine.

A TCAM lookup is approximately O(1) while a radix tree lookup is
approximately O(log n). (Neither description is strictly correct but
it's close enough to understand the running time.) Log n is pretty
small so it doesn't take much parallelism for the practical run time
to catch up to the TCAM.

Feel free to correct me if I'm mistaken or fill in any important
details I've glossed over.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

> On Sep 28, 2023, at 23:57, Vasilenko Eduard  
> wrote:
> 
> Well, it depends.
> The question below was evidently related to business.
> IPv6 does not have yet a normal way of multihoming for PA prefixes.

The normal way for IETF (which is, IMHO, borked to put it mildly) is to use 
multiple
prefixes and leave source address selection as an exercise for the victim^wend
user.

The obviously better approach is for anyone who cares about such a thing to get
a /48 and an ASN from their friendly neighborhood RIR and move on.

> If IETF (and some OTTs) would win blocking NAT66,

This is an expansion of the problem, not a solution.

> Then /48 propoisiton is the proposition for PA (to support multihoming).

If you’re using a /48, why use PA?

> Unfortunately, it is at least a 10M global routing table as it has been shown 
> by Brian Carpenter.

Not right away and this is an eventuality we will need to face sooner or later 
anyway.

> Reminder, The IPv6 scale on all routers is 2x smaller (if people would use 
> DHCP and longer than/64 then the scale would drop 2x additionally).

Which remains a bad idea for so many other reasons in addition to this one.

> Hence, /48 proposition may become 20x worse for scale than proposed initially 
> in this thread.

I don’t see it that way.

Routing tables are going to continue to grow regardless of what we do in terms 
of end site addressing.
Router vendors will build what is needed. The ability to handle a 10M route 
table is known technology at
this point, and its just a matter of the cost of the line cards.

Owen

> Eduard
> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
> Behalf Of Owen DeLong via NANOG
> Sent: Friday, September 29, 2023 7:11 AM
> To: VOLKAN SALİH 
> Cc: nanog@nanog.org
> Subject: Re: maximum ipv4 bgp prefix length of /24 ?
>  
> Wouldn’t /48s be a better solution to this need?
>  
> Owen
>  
> 
> 
> On Sep 28, 2023, at 14:25, VOLKAN SALİH  <mailto:volkan.salih...@gmail.com>> wrote:
>  
> hello,
> 
> I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
> instead of limiting maximum length to /24..
> 
> I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
> address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are sufficient 
> for most of the small and medium sized organizations and also home office 
> workers like youtubers, and professional gamers and webmasters!
> 
> It is because BGP research and experiment networks can not get /24 due to 
> high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 
> world.
> 
> What do you think about this?
> 
> What could be done here?
> 
> Is it unacceptable; considering most big networks that do full-table-routing 
> also use multi-core routers with lots of RAM? those would probably handle 
> /27s and while small networks mostly use default routing, it should be 
> reasonable to allow /25-/27?
> 
> Thanks for reading, regards..
> 

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

I have known Mike for many years. I have my disagreements with him and my 
criticisms of him.

However, HE decided to stop their free bop tunnel services due to problems with 
abuse. A free service
which becomes a magnet for problems isn’t long for this world. It’s 
unfortunate, but boils down to the
usual fact that vandals are the reason the rest of us can’t have nice things. I 
have trouble seeing how
one can blame Mike for that.

HE has continued to operate their free tunnel service in general and still 
provides a very large number
of free tunnels. They also provide a number of other services for free and at 
very reasonable prices.
I don’t see very many major providers giving back to the community to the 
extent that HE does.

At this point, if anyone should pay for IPv6 transit between Cogent and HE, 
Cogent should be the
one paying as they have the (significantly) smaller and less connected IPv6 
network. Mike is willing
to peer with Cogent for free, just like any other ISP out there. He’s not 
asking Cogent for free
transit. Cogent is the one with the selective peering policy.

Owen

Full disclosure, yes, I worked for HE for several years and I am a current HE 
customer.
I am the person behind the (in)famous IPv6 Peering Cake.



> On Sep 29, 2023, at 00:44, VOLKAN SALİH  wrote:
> 
> Many people from big companies/networks are either member of NANOG or 
> following/reading NANOG from archives.
> 
> I was also going to ask if anyone / any company can sponsor (feeless) IPv4 
> /24 prefix for my educational research network? (as209395)
> 
> We do not do or allow SPAM/spoofing and other illegal stuff, we have RPKI 
> records and check RPKI of BGP peers.
> 
> We also consider to have BGP session with HE.net <http://he.net/> and 
> CogentCo in the future, so we can re-announce their single-homed prefixes to 
> each other, as charity. For the good of everyone on the internet..
> 
> Mr. M.Leber from He.net <http://he.net/> also stopped feeless BGP tunnel 
> service, as he has not seen financial benefit, while still talking about 
> community-give-back?! And he still seeks feeless peering from CogentCo, you 
> get what you give.whatever goes around comes around
> 
> Thanks for reading, best regards and wishes
> 
> 
> 
> 29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı:
>> Well, it depends.
>> The question below was evidently related to business.
>> IPv6 does not have yet a normal way of multihoming for PA prefixes.
>> If IETF (and some OTTs) would win blocking NAT66,
>> Then /48 propoisiton is the proposition for PA (to support multihoming).
>> Unfortunately, it is at least a 10M global routing table as it has been 
>> shown by Brian Carpenter.
>> Reminder, The IPv6 scale on all routers is 2x smaller (if people would use 
>> DHCP and longer than/64 then the scale would drop 2x additionally).
>> Hence, /48 proposition may become 20x worse for scale than proposed 
>> initially in this thread.
>> Eduard
>> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
>> Behalf Of Owen DeLong via NANOG
>> Sent: Friday, September 29, 2023 7:11 AM
>> To: VOLKAN SALİH  
>> <mailto:volkan.salih...@gmail.com>
>> Cc: nanog@nanog.org <mailto:nanog@nanog.org>
>> Subject: Re: maximum ipv4 bgp prefix length of /24 ?
>>  
>> Wouldn’t /48s be a better solution to this need?
>>  
>> Owen
>>  
>> 
>> 
>> On Sep 28, 2023, at 14:25, VOLKAN SALİH > <mailto:volkan.salih...@gmail.com>> wrote:
>>  
>> hello,
>> 
>> I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
>> instead of limiting maximum length to /24..
>> 
>> I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
>> address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are 
>> sufficient for most of the small and medium sized organizations and also 
>> home office workers like youtubers, and professional gamers and webmasters!
>> 
>> It is because BGP research and experiment networks can not get /24 due to 
>> high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 
>> world.
>> 
>> What do you think about this?
>> 
>> What could be done here?
>> 
>> Is it unacceptable; considering most big networks that do full-table-routing 
>> also use multi-core routers with lots of RAM? those would probably handle 
>> /27s and while small networks mostly use default routing, it should be 
>> reasonable to allow /25-/27?
>> 
>> Thanks for reading, regards..
>> 

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Fri, Sep 29, 2023 at 12:54 PM Collider  wrote:
> This thread is utter amateur hour. I too would rather /32s be valid in the 
> DFZ - but they're not, for good reason (worstcase scenario = circa 4 bln. 
> routing table entries - no BGP hwaccel can swing that!).

Howdy,

Actually, BGP can swing that. Routing involves two distinct
components: the routing information base (RIB) and the forwarding
information base (FIB). BGP is part of the RIB portion of that
process. It's always implemented in software (no hardware
acceleration). It's not consulted per-packet, so as long as the update
rate is slow enough for the CPU to keep up and there's enough DRAM
(which is cheap and plentiful these days) to hold the entire thing,
there's no particular upper bound to the number of routes.

The router then processes all of the RIBs for all of the routing
protocols used on the router to find the best routes for any given
destination and match them to the next hops to which packets should be
sent. The results are stored in the FIB. This FIB is what's consulted
for each packet passing through the router.

The limiting factor is the FIB. The FIB is what is implemented with
hardware acceleration on high-end routers in order to achieve large
packet-per-second (PPS) numbers. It relies on storage hardware which
is both faster and more expensive than DRAM. Consequently it has much
less capacity to store information than DRAM. Currently shipping
equipment intended for BGP backbone use can manage 1M to 2M routes in
the hardware-accelerated FIB regardless of the amount of DRAM on the
machine.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Collider]

Peering cake... :-)

i think i was a puppy when that happened and only heard about it way after the 
fact

did anyone eat the cake? was it tasty?

Le 29 septembre 2023 20:55:00 UTC, Owen DeLong via NANOG  a 
écrit :
>I have known Mike for many years. I have my disagreements with him and my 
>criticisms of him.
>
>However, HE decided to stop their free bop tunnel services due to problems 
>with abuse. A free service
>which becomes a magnet for problems isn’t long for this world. It’s 
>unfortunate, but boils down to the
>usual fact that vandals are the reason the rest of us can’t have nice things. 
>I have trouble seeing how
>one can blame Mike for that.
>
>HE has continued to operate their free tunnel service in general and still 
>provides a very large number
>of free tunnels. They also provide a number of other services for free and at 
>very reasonable prices.
>I don’t see very many major providers giving back to the community to the 
>extent that HE does.
>
>At this point, if anyone should pay for IPv6 transit between Cogent and HE, 
>Cogent should be the
>one paying as they have the (significantly) smaller and less connected IPv6 
>network. Mike is willing
>to peer with Cogent for free, just like any other ISP out there. He’s not 
>asking Cogent for free
>transit. Cogent is the one with the selective peering policy.
>
>Owen
>
>Full disclosure, yes, I worked for HE for several years and I am a current HE 
>customer.
>I am the person behind the (in)famous IPv6 Peering Cake.
>
>
>
>> On Sep 29, 2023, at 00:44, VOLKAN SALİH  wrote:
>> 
>> Many people from big companies/networks are either member of NANOG or 
>> following/reading NANOG from archives.
>> 
>> I was also going to ask if anyone / any company can sponsor (feeless) IPv4 
>> /24 prefix for my educational research network? (as209395)
>> 
>> We do not do or allow SPAM/spoofing and other illegal stuff, we have RPKI 
>> records and check RPKI of BGP peers.
>> 
>> We also consider to have BGP session with HE.net <http://he.net/> and 
>> CogentCo in the future, so we can re-announce their single-homed prefixes to 
>> each other, as charity. For the good of everyone on the internet..
>> 
>> Mr. M.Leber from He.net <http://he.net/> also stopped feeless BGP tunnel 
>> service, as he has not seen financial benefit, while still talking about 
>> community-give-back?! And he still seeks feeless peering from CogentCo, you 
>> get what you give.whatever goes around comes around
>> 
>> Thanks for reading, best regards and wishes
>> 
>> 
>> 
>> 29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı:
>>> Well, it depends.
>>> The question below was evidently related to business.
>>> IPv6 does not have yet a normal way of multihoming for PA prefixes.
>>> If IETF (and some OTTs) would win blocking NAT66,
>>> Then /48 propoisiton is the proposition for PA (to support multihoming).
>>> Unfortunately, it is at least a 10M global routing table as it has been 
>>> shown by Brian Carpenter.
>>> Reminder, The IPv6 scale on all routers is 2x smaller (if people would use 
>>> DHCP and longer than/64 then the scale would drop 2x additionally).
>>> Hence, /48 proposition may become 20x worse for scale than proposed 
>>> initially in this thread.
>>> Eduard
>>> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
>>> Behalf Of Owen DeLong via NANOG
>>> Sent: Friday, September 29, 2023 7:11 AM
>>> To: VOLKAN SALİH  
>>> <mailto:volkan.salih...@gmail.com>
>>> Cc: nanog@nanog.org <mailto:nanog@nanog.org>
>>> Subject: Re: maximum ipv4 bgp prefix length of /24 ?
>>>  
>>> Wouldn’t /48s be a better solution to this need?
>>>  
>>> Owen
>>>  
>>> 
>>> 
>>> On Sep 28, 2023, at 14:25, VOLKAN SALİH >> <mailto:volkan.salih...@gmail.com>> wrote:
>>>  
>>> hello,
>>> 
>>> I believe, ISPs should also allow ipv4 prefixes with length between /25-/27 
>>> instead of limiting maximum length to /24..
>>> 
>>> I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4 
>>> address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are 
>>> sufficient for most of the small and medium sized organizations and also 
>>> home office workers like youtubers, and professional gamers and webmasters!
>>> 
>>> It is because BGP research and experiment networks can not get /24 due to 
>>> high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in IPv4 
>>> world.
>>> 
>>> What do you think about this?
>>> 
>>> What could be done here?
>>> 
>>> Is it unacceptable; considering most big networks that do 
>>> full-table-routing also use multi-core routers with lots of RAM? those 
>>> would probably handle /27s and while small networks mostly use default 
>>> routing, it should be reasonable to allow /25-/27?
>>> 
>>> Thanks for reading, regards..
>>> 
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

/32s are perfectly valid in the DMS, but there is currently an IETF limit of 
~500M of them (the other 3.5B are not yet released to the RIRs, only 2000::/3).

Owen


> On Sep 29, 2023, at 12:54, Collider  wrote:
> 
> This thread is utter amateur hour. I too would rather /32s be valid in the 
> DFZ - but they're not, for good reason (worstcase scenario = circa 4 bln. 
> routing table entries - no BGP hwaccel can swing that!).
> 
> 
> Le 29 septembre 2023 19:51:29 UTC, Seth Mattinen via NANOG  
> a écrit :
>> On 9/29/23 10:24, VOLKAN SALİH wrote:
>>> 
>>> you guys become rich this way.. by playing penny pincher.
>>> 
>>> I asked global firms like Huawei, not some local company called ADAMS!
>>> 
>> 
>> 
>> You joined the wrong mailing list then. This is NANOG, which has companies 
>> of all sizes and private individuals operating networks. This is not a 
>> "global firms" mailing list.
>> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

>
> My understanding of Juniper's approach to the problem is that instead
> of employing TCAMs for next-hop lookup, they use general purpose CPUs
> operating on a radix tree, exactly as you would for an all-software
> router.
>

Absolutely are not doing that with "general purpose CPUs".

The LU block on early gen Trios was a dedicated ASIC (LU by itself, then
consolidated slightly) , then later gen Trio put everything on a
single chip, but again dedicated ASIC.

To
> achieve an -aggregate- lookup speed comparable to a TCAM, they
> implement a bunch of these lookup engines as dedicated parallel
> subprocessors rather than using the router's primary compute engine.
>

You're correct that there is parallelism in the LU functions , but I still
think you're kinda smushing a bunch of stuff that's happening in different
places together.

On Fri, Sep 29, 2023 at 4:44 PM William Herrin  wrote:

> On Thu, Sep 28, 2023 at 10:29 PM Saku Ytti  wrote:
> > On Fri, 29 Sept 2023 at 08:24, William Herrin  wrote:
> > > Maybe. That's where my comment about CPU cache starvation comes into
> > > play. I haven't delved into the Juniper line cards recently so I could
> > > easily be wrong, but if the number of routes being actively used
> > > pushes past the CPU data cache, the cache miss rate will go way up and
> > > it'll start thrashing main memory. The net result is that the
> > > achievable PPS drops by at least an order of magnitude.
> >
> > When you say, you've not delved into the Juniper line cards recently,
> > to which specific Juniper linecard your comment applies to?
>
> Howdy,
>
> My understanding of Juniper's approach to the problem is that instead
> of employing TCAMs for next-hop lookup, they use general purpose CPUs
> operating on a radix tree, exactly as you would for an all-software
> router. This makes each lookup much slower than a TCAM can achieve.
> However, that doesn't matter much: the lookup delays are much shorter
> than the transmission delays so it's not noticeable to the user. To
> achieve an -aggregate- lookup speed comparable to a TCAM, they
> implement a bunch of these lookup engines as dedicated parallel
> subprocessors rather than using the router's primary compute engine.
>
> A TCAM lookup is approximately O(1) while a radix tree lookup is
> approximately O(log n). (Neither description is strictly correct but
> it's close enough to understand the running time.) Log n is pretty
> small so it doesn't take much parallelism for the practical run time
> to catch up to the TCAM.
>
> Feel free to correct me if I'm mistaken or fill in any important
> details I've glossed over.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

> On Sep 29, 2023, at 13:43, William Herrin  wrote:
> 
> On Thu, Sep 28, 2023 at 10:29 PM Saku Ytti  wrote:
>> On Fri, 29 Sept 2023 at 08:24, William Herrin  wrote:
>>> Maybe. That's where my comment about CPU cache starvation comes into
>>> play. I haven't delved into the Juniper line cards recently so I could
>>> easily be wrong, but if the number of routes being actively used
>>> pushes past the CPU data cache, the cache miss rate will go way up and
>>> it'll start thrashing main memory. The net result is that the
>>> achievable PPS drops by at least an order of magnitude.
>> 
>> When you say, you've not delved into the Juniper line cards recently,
>> to which specific Juniper linecard your comment applies to?
> 
> Howdy,
> 
> My understanding of Juniper's approach to the problem is that instead
> of employing TCAMs for next-hop lookup, they use general purpose CPUs
> operating on a radix tree, exactly as you would for an all-software
> router. This makes each lookup much slower than a TCAM can achieve.
> However, that doesn't matter much: the lookup delays are much shorter
> than the transmission delays so it's not noticeable to the user. To
> achieve an -aggregate- lookup speed comparable to a TCAM, they
> implement a bunch of these lookup engines as dedicated parallel
> subprocessors rather than using the router's primary compute engine.

In their lower-end hardware, yes. The MX uses ASICs traversing the
tree, if I understood the explanation correctly, but there’s essentially
a copy of the compiled/condensed tree on every line card and many
of the line cards have more than one PFE per line card.

> A TCAM lookup is approximately O(1) while a radix tree lookup is
> approximately O(log n). (Neither description is strictly correct but
> it's close enough to understand the running time.) Log n is pretty
> small so it doesn't take much parallelism for the practical run time
> to catch up to the TCAM.

The only difference, I believe, is that it’s ASICs against RAM rather
than CPUs against CPU Cache, but otherwise, yes, you’ve got the
correct general idea. However, since you brought CPU Cache into
the discussion, that difference seemed worthy of addressing.

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

s/DMS/DFZ/ — Not sure how autocrrect did that without me noticing, apologies.


> On Sep 29, 2023, at 14:11, Owen DeLong via NANOG  wrote:
> 
> /32s are perfectly valid in the DMS, but there is currently an IETF limit of 
> ~500M of them (the other 3.5B are not yet released to the RIRs, only 
> 2000::/3).
> 
> Owen
> 
> 
>> On Sep 29, 2023, at 12:54, Collider  wrote:
>> 
>> This thread is utter amateur hour. I too would rather /32s be valid in the 
>> DFZ - but they're not, for good reason (worstcase scenario = circa 4 bln. 
>> routing table entries - no BGP hwaccel can swing that!).
>> 
>> 
>> Le 29 septembre 2023 19:51:29 UTC, Seth Mattinen via NANOG  
>> a écrit :
>>> On 9/29/23 10:24, VOLKAN SALİH wrote:
 
 you guys become rich this way.. by playing penny pincher.
 
 I asked global firms like Huawei, not some local company called ADAMS!
 
>>> 
>>> 
>>> You joined the wrong mailing list then. This is NANOG, which has companies 
>>> of all sizes and private individuals operating networks. This is not a 
>>> "global firms" mailing list.
>>> 
>> 
>> -- 
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

Several people ate the cake. I received numerous positive comments on it and 
some
of them are about the flavor of the cake.

Owen


> On Sep 29, 2023, at 14:11, Collider  wrote:
> 
> Peering cake... :-)
> 
> i think i was a puppy when that happened and only heard about it way after 
> the fact
> 
> did anyone eat the cake? was it tasty?
> 
> 
> Le 29 septembre 2023 20:55:00 UTC, Owen DeLong via NANOG  a 
> écrit :
>> I have known Mike for many years. I have my disagreements with him and my 
>> criticisms of him.
>> 
>> However, HE decided to stop their free bop tunnel services due to problems 
>> with abuse. A free service
>> which becomes a magnet for problems isn’t long for this world. It’s 
>> unfortunate, but boils down to the
>> usual fact that vandals are the reason the rest of us can’t have nice 
>> things. I have trouble seeing how
>> one can blame Mike for that.
>> 
>> HE has continued to operate their free tunnel service in general and still 
>> provides a very large number
>> of free tunnels. They also provide a number of other services for free and 
>> at very reasonable prices.
>> I don’t see very many major providers giving back to the community to the 
>> extent that HE does.
>> 
>> At this point, if anyone should pay for IPv6 transit between Cogent and HE, 
>> Cogent should be the
>> one paying as they have the (significantly) smaller and less connected IPv6 
>> network. Mike is willing
>> to peer with Cogent for free, just like any other ISP out there. He’s not 
>> asking Cogent for free
>> transit. Cogent is the one with the selective peering policy.
>> 
>> Owen
>> 
>> Full disclosure, yes, I worked for HE for several years and I am a current 
>> HE customer.
>> I am the person behind the (in)famous IPv6 Peering Cake.
>> 
>> 
>> 
>>> On Sep 29, 2023, at 00:44, VOLKAN SALİH  wrote:
>>> 
>>> Many people from big companies/networks are either member of NANOG or 
>>> following/reading NANOG from archives.
>>> 
>>> I was also going to ask if anyone / any company can sponsor (feeless) IPv4 
>>> /24 prefix for my educational research network? (as209395)
>>> 
>>> We do not do or allow SPAM/spoofing and other illegal stuff, we have RPKI 
>>> records and check RPKI of BGP peers.
>>> 
>>> We also consider to have BGP session with HE.net <http://he.net/> and 
>>> CogentCo in the future, so we can re-announce their single-homed prefixes 
>>> to each other, as charity. For the good of everyone on the internet..
>>> 
>>> Mr. M.Leber from He.net <http://he.net/> also stopped feeless BGP tunnel 
>>> service, as he has not seen financial benefit, while still talking about 
>>> community-give-back?! And he still seeks feeless peering from CogentCo, you 
>>> get what you give.whatever goes around comes around
>>> 
>>> Thanks for reading, best regards and wishes
>>> 
>>> 
>>> 
>>> 29.09.2023 09:57 tarihinde Vasilenko Eduard yazdı:
>>>> Well, it depends.
>>>> The question below was evidently related to business.
>>>> IPv6 does not have yet a normal way of multihoming for PA prefixes.
>>>> If IETF (and some OTTs) would win blocking NAT66,
>>>> Then /48 propoisiton is the proposition for PA (to support multihoming).
>>>> Unfortunately, it is at least a 10M global routing table as it has been 
>>>> shown by Brian Carpenter.
>>>> Reminder, The IPv6 scale on all routers is 2x smaller (if people would use 
>>>> DHCP and longer than/64 then the scale would drop 2x additionally).
>>>> Hence, /48 proposition may become 20x worse for scale than proposed 
>>>> initially in this thread.
>>>> Eduard
>>>> From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] 
>>>> On Behalf Of Owen DeLong via NANOG
>>>> Sent: Friday, September 29, 2023 7:11 AM
>>>> To: VOLKAN SALİH  
>>>> <mailto:volkan.salih...@gmail.com>
>>>> Cc: nanog@nanog.org <mailto:nanog@nanog.org>
>>>> Subject: Re: maximum ipv4 bgp prefix length of /24 ?
>>>>  
>>>> Wouldn’t /48s be a better solution to this need?
>>>>  
>>>> Owen
>>>>  
>>>> 
>>>> 
>>>> On Sep 28, 2023, at 14:25, VOLKAN SALİH >>> <mailto:volkan.salih...@gmail.com>> wrote:
>>>>  
>>>> hello,
>>>> 
>>>> I believe

Re: maximum ipv4 bgp prefix length of /24 ?

[Daniel Corbe]

On 9/29/2023 5:25 PM, Owen DeLong via NANOG wrote:
Several people ate the cake. I received numerous positive comments on it 
and some

of them are about the flavor of the cake.


The question is did anyone from Cogent eat it?  Did they have their cake 
and eat it too?





OpenPGP_0x8E96B69A30C1993B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher  wrote:
>> My understanding of Juniper's approach to the problem is that instead
>> of employing TCAMs for next-hop lookup, they use general purpose CPUs
>> operating on a radix tree, exactly as you would for an all-software
>> router.
>
> Absolutely are not doing that with "general purpose CPUs".
>
> The LU block on early gen Trios was a dedicated ASIC (LU by itself, then 
> consolidated slightly) , then later gen Trio put everything on a single chip, 
> but again dedicated ASIC.

Hi Tom,

For clarity, general purpose CPU refers to an architecture not an
implementation. It's capable of running arbitrary computer software
and has the typical functions like loading and saving registers, an
adder, bit shifts, etc. The CPU in a Raspberry Pi is also part of a
dedicated ASIC that does wifi, packet switching and a bunch of other
stuff. It's still a CPU. Compare to a TCAM which is purpose built to
match input bit patterns and is capable of nothing else.

I suppose the PPEs in the Trio are more like GPUs than CPUs - more
limited instruction sets but higher parallelism. However, they still
follow the cache pattern where the frequently used parts of the FIB
tree are in a fast SRAM cache and the remainder is in slower DRAM
where it can be loaded into SRAM at the occasional need. The FIB size
limit before cache thrashing sets in and cuts the PPS is softer than
the limit with a TCAM but it's still there.

Compare to a TCAM which uses a tristate ram rather than the normal
two-state sram.

Yes?

Regards,
Bill Herrin



--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

General Purpose CPU : Can run Doom.
Trio ASIC : Cannot run Doom.

Have a good weekend Bill.

On Fri, Sep 29, 2023 at 5:48 PM William Herrin  wrote:

> On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher  wrote:
> >> My understanding of Juniper's approach to the problem is that instead
> >> of employing TCAMs for next-hop lookup, they use general purpose CPUs
> >> operating on a radix tree, exactly as you would for an all-software
> >> router.
> >
> > Absolutely are not doing that with "general purpose CPUs".
> >
> > The LU block on early gen Trios was a dedicated ASIC (LU by itself, then
> consolidated slightly) , then later gen Trio put everything on a single
> chip, but again dedicated ASIC.
>
> Hi Tom,
>
> For clarity, general purpose CPU refers to an architecture not an
> implementation. It's capable of running arbitrary computer software
> and has the typical functions like loading and saving registers, an
> adder, bit shifts, etc. The CPU in a Raspberry Pi is also part of a
> dedicated ASIC that does wifi, packet switching and a bunch of other
> stuff. It's still a CPU. Compare to a TCAM which is purpose built to
> match input bit patterns and is capable of nothing else.
>
> I suppose the PPEs in the Trio are more like GPUs than CPUs - more
> limited instruction sets but higher parallelism. However, they still
> follow the cache pattern where the frequently used parts of the FIB
> tree are in a fast SRAM cache and the remainder is in slower DRAM
> where it can be loaded into SRAM at the occasional need. The FIB size
> limit before cache thrashing sets in and cuts the PPS is softer than
> the limit with a TCAM but it's still there.
>
> Compare to a TCAM which uses a tristate ram rather than the normal
> two-state sram.
>
> Yes?
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

RE: maximum ipv4 bgp prefix length of /24 ?

[Tony Wicks]

I am reminded of something I “saw” many years ago of a Quake server running on 
a Juniper M160, it wasn’t fast but oh the connectivity.

 

From: NANOG  On Behalf Of Tom Beecher
Sent: Saturday, September 30, 2023 11:03 AM
To: William Herrin 
Cc: nanog@nanog.org
Subject: Re: maximum ipv4 bgp prefix length of /24 ?

 

General Purpose CPU : Can run Doom.

Trio ASIC : Cannot run Doom.

 

Have a good weekend Bill. 

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

> On Sep 29, 2023, at 14:48, William Herrin  wrote:
> 
> On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher  wrote:
>>> My understanding of Juniper's approach to the problem is that instead
>>> of employing TCAMs for next-hop lookup, they use general purpose CPUs
>>> operating on a radix tree, exactly as you would for an all-software
>>> router.
>> 
>> Absolutely are not doing that with "general purpose CPUs".
>> 
>> The LU block on early gen Trios was a dedicated ASIC (LU by itself, then 
>> consolidated slightly) , then later gen Trio put everything on a single 
>> chip, but again dedicated ASIC.
> 
> Hi Tom,
> 
> For clarity, general purpose CPU refers to an architecture not an
> implementation. It's capable of running arbitrary computer software
> and has the typical functions like loading and saving registers, an
> adder, bit shifts, etc. The CPU in a Raspberry Pi is also part of a
> dedicated ASIC that does wifi, packet switching and a bunch of other
> stuff. It's still a CPU. Compare to a TCAM which is purpose built to
> match input bit patterns and is capable of nothing else.
> 
> I suppose the PPEs in the Trio are more like GPUs than CPUs - more
> limited instruction sets but higher parallelism. However, they still
> follow the cache pattern where the frequently used parts of the FIB
> tree are in a fast SRAM cache and the remainder is in slower DRAM
> where it can be loaded into SRAM at the occasional need. The FIB size
> limit before cache thrashing sets in and cuts the PPS is softer than
> the limit with a TCAM but it's still there.

You continue to assume that there is a fast SRAM cache. I’m not sure
that is true. I think that all of the FIB RAM on the line cards is fast SRAM
and no cache.

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong  wrote:
> You continue to assume that there is a fast SRAM cache. I’m not sure
> that is true. I think that all of the FIB RAM on the line cards is fast SRAM
> and no cache.

Hi Owen,

I'm less assuming it and more reading it from this SIGCOMM paper:
https://people.csail.mit.edu/ghobadi/papers/trio_sigcomm_2022.pdf

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

>
> I'm less assuming it and more reading it from this SIGCOMM paper:
> https://people.csail.mit.edu/ghobadi/papers/trio_sigcomm_2022.pdf


Which doesn't cover the subject at hand. Owen is correct here.

The LU block has separate reduced latency RAM that holds the data it uses.
(The FIB). Other memory in the chip is used for the other non-lookup
functions.



On Fri, Sep 29, 2023 at 6:14 PM William Herrin  wrote:

> On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong  wrote:
> > You continue to assume that there is a fast SRAM cache. I’m not sure
> > that is true. I think that all of the FIB RAM on the line cards is fast
> SRAM
> > and no cache.
>
> Hi Owen,
>
> I'm less assuming it and more reading it from this SIGCOMM paper:
> https://people.csail.mit.edu/ghobadi/papers/trio_sigcomm_2022.pdf
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Fri, Sep 29, 2023 at 3:03 PM Tom Beecher  wrote:
> General Purpose CPU : Can run Doom.
> Trio ASIC : Cannot run Doom.

Cute. False. But cute. At the risk of pedantry, the ATMega chip in the
Arduino can't run Doom either, nor does it have any DRAM, only SRAM
and flash ram. Nevertheless, it implements all the functionality
necessary to be a general purpose CPU.

Still, I thank you for the pointers. I know more about Juniper's
architecture now than I did a few hours ago. Based on what I've
learned I'd characterize it as sharing more in common with a GPU than
a general purpose CPU. Architecturally I mean. Obviously it's
optimized for a different task than a GPU.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

> On Sep 29, 2023, at 15:14, William Herrin  wrote:
> 
> On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong  wrote:
>> You continue to assume that there is a fast SRAM cache. I’m not sure
>> that is true. I think that all of the FIB RAM on the line cards is fast SRAM
>> and no cache.
> 
> Hi Owen,
> 
> I'm less assuming it and more reading it from this SIGCOMM paper:
> https://people.csail.mit.edu/ghobadi/papers/trio_sigcomm_2022.pdf

Fair enough, but interestingly, I think that the compiled line-card forwarding
table probably always fits in the cache.

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Fri, Sep 29, 2023 at 3:26 PM Owen DeLong  wrote:
> > On Sep 29, 2023, at 15:14, William Herrin  wrote:
> > I'm less assuming it and more reading it from this SIGCOMM paper:
> > https://people.csail.mit.edu/ghobadi/papers/trio_sigcomm_2022.pdf
>
> Fair enough, but interestingly, I think that the compiled line-card forwarding
> table probably always fits in the cache.

If I were designing the product, I'd size the SRAM with that in mind.
I'd also keep two full copies of the FIB in the outer DRAM so that the
PPEs could locklessly access the active one while the standby one gets
updated with changes from the RIB. But I'd design the router to
gracefully fail if the FIB exceeded what the SRAM could hold.

When a TCAM fills, the shortest prefixes are ejected to the router's
main CPU. That fails pretty hard since the shortest prefixes tend to
be among the most commonly used. By comparison, an SRAM cache tends to
retain the most commonly used prefixes as an inherent part of how
caches work, regardless of prefix length. It can operate close to full
speed until the actively used routes no longer fit in the cache.

Regards,
Bill Herrin



--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Jakob Heitz (jheitz) via NANOG]

Each unit of mask length increase doubles the size of the table theoretically.
About 60% of the table is /24 routes.
Just going to /25 will probably double the table size.
Not sure I'd like to extrapolate the estimate out to /27.

Kind Regards,
Jakob

-
Date: Fri, 29 Sep 2023 00:25:55 +0300
From: VOLKAN SAL?H 
To: nanog@nanog.org

hello,

I believe, ISPs should also allow ipv4 prefixes with length between
/25-/27 instead of limiting maximum length to /24..

I also believe that RIRs and LIRs should allocate /27s which has 32 IPv4
address. considering IPv4 world is now mostly NAT'ed, 32 IPv4s are
sufficient for most of the small and medium sized organizations and also
home office workers like youtubers, and professional gamers and webmasters!

It is because BGP research and experiment networks can not get /24 due
to high IPv4 prices, but they have to get an IPv4 prefix to learn BGP in
IPv4 world.

What do you think about this?

What could be done here?

Is it unacceptable; considering most big networks that do
full-table-routing also use multi-core routers with lots of RAM? those
would probably handle /27s and while small networks mostly use default
routing, it should be reasonable to allow /25-/27?

Thanks for reading, regards..

Re: maximum ipv4 bgp prefix length of /24 ?

[Saku Ytti]

On Fri, 29 Sept 2023 at 23:43, William Herrin  wrote:

> My understanding of Juniper's approach to the problem is that instead
> of employing TCAMs for next-hop lookup, they use general purpose CPUs
> operating on a radix tree, exactly as you would for an all-software

They use proprietary NPUs, with proprietary IA. Which is called 'Trio'.

Single Trio can have hundreds of PPEs, packet processing engines,
these are all identical.

Packets are sprayed to PPEs, PPEs do not run constant time, so
reordering occurs always.

Juniper is a pioneer in FIB in DRAM, and has patente gated it to a
degree. So it takes a very very long time to get an answer from
memory.

To amortise this, PPEs have a lot of threads, and while waiting for
memory, another packet is worked on. But there is no pre-emption,
there is no kind of moving register/memory around or cache-misses here
as a function of FIB size. PPE does all the work it has, then it
requests an answer from memory, then goes to sleep, then comes back
when the answer arrives and does all the work it has, never
pre-empted.

But there is a lot more complexity here, memory used to be in the
original Trio RLDRAM which was a fairly simple setup. Once they
changed to HMC, they added a cache in front of memory, a proprietary
chip called CAE. IFLs were dynamically allocated one of multiple CAEs
they'd use to access memory. Single CAE wouldn't have 'wire rate'
performance. So if you had pathological setup, like 2 IFL, and you'd
get unlucky, you'd get both IFLs in some boots assigned to same CAE,
instead of spread to two CAEs, you would on some boots see lower PPS
performance than other boots, because you were hot-banking the CAE.
This is only type of cache problem I can recall related to Juniper.

But these devices are entirely proprietary and things move relatively
fast and complexity increases all the time.

> router. This makes each lookup much slower than a TCAM can achieve.
> However, that doesn't matter much: the lookup delays are much shorter
> than the transmission delays so it's not noticeable to the user. To

In DRAM lookups, like what Juniper does, most of the time you're
waiting for the memory. With DRAM, FIB size is trivial engineering
problem, memory bandwidth and latency is the hard problem. Juniper
does not do TC AMs on it's service provider class devices.



-- 
  ++ytti

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Tinka]

On 9/29/23 06:43, VOLKAN SALİH wrote:

But when everybody upgrades, memory and processor unit prices 
decrease.. Vendors gain from demand.




I am yet to see that trend...

Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

[Saku Ytti]

On Sat, 30 Sept 2023 at 09:42, Mark Tinka  wrote:

> > But when everybody upgrades, memory and processor unit prices
> > decrease.. Vendors gain from demand.
> >
> I am yet to see that trend...

Indeed. If you look like 10k/10q for Juniper their business is fairly
stable in revenue and ports sold. so 1GE port costs the ~same as 1TE
port, not more, not less. If there was reduction in port prices over
time, then revenue would have to go down or ports sold up.
Of course all this makes perfect sense, the sand order doesn't affect
the sand price, all the cost is in people thinking how sand should be
ordered and then designing machines which put the sand together.


-- 
  ++ytti

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Tinka]

On 9/29/23 22:56, William Herrin wrote:


Actually, BGP can swing that. Routing involves two distinct
components: the routing information base (RIB) and the forwarding
information base (FIB). BGP is part of the RIB portion of that
process. It's always implemented in software (no hardware
acceleration). It's not consulted per-packet, so as long as the update
rate is slow enough for the CPU to keep up and there's enough DRAM
(which is cheap and plentiful these days) to hold the entire thing,
there's no particular upper bound to the number of routes.


Not unless you are running BGP Add-Paths in its extreme guise to 
consider all available paths, and then there is the chance you could 
push your RAM and CPU into unknown territory, depending on the platform, 
code and control plane you've got.




The limiting factor is the FIB. The FIB is what is implemented with
hardware acceleration on high-end routers in order to achieve large
packet-per-second (PPS) numbers. It relies on storage hardware which
is both faster and more expensive than DRAM. Consequently it has much
less capacity to store information than DRAM. Currently shipping
equipment intended for BGP backbone use can manage 1M to 2M routes in
the hardware-accelerated FIB regardless of the amount of DRAM on the
machine.


There are line cards out there today that are able to hold 10 million 
routes in FIB.


Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Tinka]

On 9/30/23 01:36, William Herrin wrote:


If I were designing the product, I'd size the SRAM with that in mind.
I'd also keep two full copies of the FIB in the outer DRAM so that the
PPEs could locklessly access the active one while the standby one gets
updated with changes from the RIB. But I'd design the router to
gracefully fail if the FIB exceeded what the SRAM could hold.

When a TCAM fills, the shortest prefixes are ejected to the router's
main CPU. That fails pretty hard since the shortest prefixes tend to
be among the most commonly used. By comparison, an SRAM cache tends to
retain the most commonly used prefixes as an inherent part of how
caches work, regardless of prefix length. It can operate close to full
speed until the actively used routes no longer fit in the cache.


Well, not sure if you're aware, but starting Junos 21.2, Juniper are 
implementing FIB Compression on the PTX routers running Express 4 and 
Junos EVO.


We have some of these boxes in our network (PTX10001), and I have asked 
Juniper to provide a knob to allow us to turn it off, as it is currently 
going to ship as a default-on feature. I'd rather not be part of the 
potential mess that is going to come with the experimentation of that 
over the next decade.


Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

[Randy Bush]

> About 60% of the table is /24 routes.
> Just going to /25 will probably double the table size.

or maybe just add 60%, not 100%.  and it would take time.

agree it would be quite painful.  would rather not go there.  sad to
say, i suspect some degree of lengthening is inevitable.  we have
ourselves to blame; but blame does not move packets.

randy, who was in the danvers cabal for the /19 agreement

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

Not sure why you think FIB compression is a risk or will be a mess. It’s a 
pretty straightforward task. 

Owen


> On Sep 30, 2023, at 00:03, Mark Tinka  wrote:
> 
>  
> 
>> On 9/30/23 01:36, William Herrin wrote:
>> 
>> 
>>  If I were designing the product, I'd size the SRAM with that in mind.
>> I'd also keep two full copies of the FIB in the outer DRAM so that the
>> PPEs could locklessly access the active one while the standby one gets
>> updated with changes from the RIB. But I'd design the router to
>> gracefully fail if the FIB exceeded what the SRAM could hold.
>> 
>> When a TCAM fills, the shortest prefixes are ejected to the router's
>> main CPU. That fails pretty hard since the shortest prefixes tend to
>> be among the most commonly used. By comparison, an SRAM cache tends to
>> retain the most commonly used prefixes as an inherent part of how
>> caches work, regardless of prefix length. It can operate close to full
>> speed until the actively used routes no longer fit in the cache.
> 
> Well, not sure if you're aware, but starting Junos 21.2, Juniper are 
> implementing FIB Compression on the PTX routers running Express 4 and Junos 
> EVO.
> 
> We have some of these boxes in our network (PTX10001), and I have asked 
> Juniper to provide a knob to allow us to turn it off, as it is currently 
> going to ship as a default-on feature. I'd rather not be part of the 
> potential mess that is going to come with the experimentation of that over 
> the next decade.
> 
> Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

[Saku Ytti]

On Sun, 1 Oct 2023 at 06:07, Owen DeLong via NANOG  wrote:

> Not sure why you think FIB compression is a risk or will be a mess. It’s a 
> pretty straightforward task.

Also people falsely assume that the parts they don't know about, are
risk free and simple.

While in reality there are tons of proprietary engineering choices to
make devices perform in expected environments, not arbitrary
environments. So already today you could in many cases construct
specific FIB, which exposes these compromises and makes devices not
perform. There are dragons everywhere, but we can remain largely
ignorant of them, as these engineering choices tend to be reasonable.
Sometimes they are abused by shops like EANTC and Miercom for
marketing reasons for ostensibly 'independent' tests.

I think this compression is part of this continuum, magic inside the
box I hope works because I can't begin to have a comprehensive
understanding exactly how much risk I am carrying.

Pretty much all performant boxes no longer have bandwidth to store all
packets in memory (partial buffering), many of them have 'hot' and
'cold' prefixes. You just gotta hope, you're not gonna be able to
prove anything, and by trying to do so, you're more likely to increase
your costs due to false positives than you are to find an actionable
problem. Most problems don't matter, figuring out which problem needs
to be fixed is hard.

-- 
  ++ytti

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Sat, Sep 30, 2023 at 8:04 PM Owen DeLong via NANOG  wrote:
> Not sure why you think FIB compression is a risk or will be a mess. It’s a 
> pretty straightforward task.

Hi Owen,

There are multiple levels of FIB compression. The simplest version
merely aggregates adjacent routes with the same next hop.
Straightforward, as you say.

However, there are more advanced versions of FIB compression as well.
Routers have an implicit default route to a drop-and-report target.
Pragmatically, though, the user doesn't really care what happens to
unroutable packets: they can't reach a destination regardless. If you
replace that implicit default route with a "don't care," you can roll
up the entire address space into a set of "send everything to this
next hop with these exceptions." And you can build on that recursively
to get extraordinary FIB compression.

This latter version, however, is not straightforward. Bugs that escape
QC are quite a bit more likely.

Will Juniper stop with the simplest version of FIB compression where
not much can go wrong? Not if it works and customers like it.

Regards,
Bill Herrin



--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Matthew Petach]

On Sun, Oct 1, 2023 at 1:03 AM Saku Ytti  wrote:

> On Sun, 1 Oct 2023 at 06:07, Owen DeLong via NANOG 
> wrote:
>
> > Not sure why you think FIB compression is a risk or will be a mess. It’s
> a pretty straightforward task.
>
> Also people falsely assume that the parts they don't know about, are
> risk free and simple.
>
> While in reality there are tons of proprietary engineering choices to
> make devices perform in expected environments, not arbitrary
> environments. So already today you could in many cases construct
> specific FIB, which exposes these compromises and makes devices not
> perform.


I would go a step further; for any system of compression hoping to gain a
net positive space savings,
Godel's incompleteness theorem guarantees that there is at least one input
to the system that will result in no space savings whatsoever.

If your device is counting on FIB compression to deliver sufficient space
savings to allow a FIB of size > SRAM to fit into SRAM,
it really should have a reasonable, sane fallback mode for when the next
routing update happens to result in a FIB that is incompressible.

Unfortunately, many coders today have not read Godel, Escher, Bach: An
Eternal Golden Braid,
and like the unfortunate Crab, consider their FIB compression algorithms to
be unbreakable[0].

As I discovered many years ago, at web scale, even seemingly
highly-improbable sequences of bits end up happening frequently enough to
become problematic.

In short: if you count on FIB compression working at a compression ratio
greater than 1 in order for your network to function, you had better have a
good plan for what to do when your phone rings at 3am because your FIB has
just become incompressible.   ^_^;

Matt

[0]. https://genius.com/Douglas-hofstadter-contracrostipunctus-annotated

Re: maximum ipv4 bgp prefix length of /24 ?

[Seth David Schoen]

Matthew Petach writes:

> I would go a step further; for any system of compression hoping to gain a
> net positive space savings,
> Godel's incompleteness theorem guarantees that there is at least one input
> to the system that will result in no space savings whatsoever.

This is rather the Pigeonhole Principle that guarantees this.

https://en.wikipedia.org/wiki/Lossless_compression#Limitations

Re: maximum ipv4 bgp prefix length of /24 ?

[Matthew Petach]

On Sun, Oct 1, 2023 at 11:25 AM Seth David Schoen 
wrote:

> Matthew Petach writes:
>
> > I would go a step further; for any system of compression hoping to gain a
> > net positive space savings,
> > Godel's incompleteness theorem guarantees that there is at least one
> input
> > to the system that will result in no space savings whatsoever.
>
> This is rather the Pigeonhole Principle that guarantees this.
>
> https://en.wikipedia.org/wiki/Lossless_compression#Limitations


Ah, thank you for the more specific pointer--a good read, though slightly
less entertaining than Hofstadter.  ^_^

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[Jakob Heitz (jheitz) via NANOG]

Among the issues:
Suppose the FIB has all the /24 components to make a /20, so it programs a /20.
Then one of the /24's changes nexthop. It now has to undo all that compression
by reinstalling some of the routes and figuring out the minimum set of /21, 
/22, /23, /24
to make it happen. Then to avoid a transient, it needs to make before break.
Quite a bit of FIB programming needs to happen just to modify a single /24.
Then the next /24 in the set also modifies its nexthop. and so on for 10 
routes.
All because a peer link flapped.
Affecting convergence.
Then you need to buy a line card that can hold all the individual routes, 
because you
can't always compress, because not all the routes in your compressed set have 
the
same nexthop during a transient.
Finally, it's all nicely compressed.
Now what? You have lots of empty slots in your FIB.
I'm sure lots of nerds can come up with transient reduction algorithms, but I'd 
rather not.

Kind Regards,
Jakob

---
Date: Sat, 30 Sep 2023 20:04:29 -0700
From: Owen DeLong 

Not sure why you think FIB compression is a risk or will be a mess. It?s a 
pretty straightforward task.

Owen

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Sun, Oct 1, 2023 at 5:40 PM Jakob Heitz (jheitz) via NANOG
 wrote:
> Among the issues:
> Suppose the FIB has all the /24 components to make a /20, so it programs a 
> /20.
> Then one of the /24's changes nexthop. It now has to undo all that compression

Yeah... all this stuff is on the same level of complexity as
implementing a B-Tree. Standard task on the road to an undergraduate
computer science degree. Compared to decoding a BGP update message,
where nearly everything is variable length and you have to nibble away
at the current field to find the start of the next field, this is a
cakewalk.

It doesn't actually get complicated until you want to do more than
just joining adjacent address blocks.

Regards,
Bill Herrin




-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Jakob Heitz (jheitz) via NANOG]

While I did allude to some of the complexity, my main point
is that FIB compression does not allow you to install a FIB with less memory.
Because you must be prepared for transients during which the FIB needs to store
mostly uncompressed anyway.
All it does is to increase convergence time.

Kind Regards,
Jakob


From: William Herrin 
Date: Sunday, October 1, 2023 at 6:32 PM
To: Jakob Heitz (jheitz) 
Cc: nanog@nanog.org 
Subject: Re: maximum ipv4 bgp prefix length of /24 ?
On Sun, Oct 1, 2023 at 5:40 PM Jakob Heitz (jheitz) via NANOG
 wrote:
> Among the issues:
> Suppose the FIB has all the /24 components to make a /20, so it programs a 
> /20.
> Then one of the /24's changes nexthop. It now has to undo all that compression

Yeah... all this stuff is on the same level of complexity as
implementing a B-Tree. Standard task on the road to an undergraduate
computer science degree. Compared to decoding a BGP update message,
where nearly everything is variable length and you have to nibble away
at the current field to find the start of the next field, this is a
cakewalk.

It doesn't actually get complicated until you want to do more than
just joining adjacent address blocks.

Regards,
Bill Herrin




--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Sun, Oct 1, 2023 at 9:55 PM Jakob Heitz (jheitz)  wrote:
> my main point
> is that FIB compression does not allow you to install a FIB with less memory.

Hi Jakob,

The math disagrees. It's called "oversubscription," and we use it all
over the place in network engineering.

There are only a handful of route patterns that'd result in no
compression at all. They'd have to be intentionally created, and
that'd be a hacking challenge in and of itself. The patterns in
question don't align with the distribution of addresses on the
Internet.

If you're at 80% FIB after compression, a compression transient could
plausibly bump you to 85%. The odds of a natural transient bumping you
to 100% are infinitesimal. If you try to run at 95% after
compression... well, I'm sure someone will try it, but that's PEBKAC
not compression's fault.

FIB compression ranges from 30% in simple core scenarios to more than
90% in edge scenarios with advanced compression. Even keeping
reasonable slack for transients, you're going to get some bang for
your buck. All it means is that you have to keep an eye on your FIB
size as well, since it's no longer the same as your RIB size.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Saku Ytti]

On Sun, 1 Oct 2023 at 21:19, Matthew Petach  wrote:

> Unfortunately, many coders today have not read Godel, Escher, Bach: An 
> Eternal Golden Braid,
> and like the unfortunate Crab, consider their FIB compression algorithms to 
> be unbreakable[0].
>
> In short: if you count on FIB compression working at a compression ratio 
> greater than 1 in order for your network to function, you had better have a 
> good plan for what to do when your phone rings at 3am because your FIB has 
> just become incompressible.   ^_^;

I think if we make the argument 'devices must always work' no device
satisfies it today. There are already a lot of assumptions and
compromises which cause them to work 'highly likely in most practical
scenarios'. Certainly if we were to try to formally prove, we could
prove that everything is terrible, PPS under the worst-case situation
is beyond useless on devices people intuitively consider 'wire speed'.

I fully agree fundamentally FIB compression is not safe, but also that
ship has sailed, nothing we do is safe. But is it marketable? Likely
answer is resoundingly yes.

I do feel that often people underestimate the amount of risk they
carry, and overestimate the importance of the risks they understand.
Since the vast majority of risks are carried without understanding
them. But intuitively we like to think we have good visibility into
our risks and any recognised risk therefore automatically is an
important risk.

-- 
  ++ytti

Re: maximum ipv4 bgp prefix length of /24 ?

[Nick Hilliard]

William Herrin wrote on 02/10/2023 08:56:

All it means is that you have to keep an eye on your FIB
size as well, since it's no longer the same as your RIB size.


the point Jacob is making is is that when using FIB compression, the FIB 
size depends on both RIB size and RIB complexity.  I.e. what was 
previously a deterministic 1:1 ratio between RIB and FIB - which is 
straightforward to handle from an operational point of view - becomes 
non-deterministic. The difficulty with this is that if you end up with a 
FIB overflow, your router will no longer route.


That said, there are cases where FIB compression makes a lot of sense, 
e.g. leaf sites, etc. Conversely, it's not a generally appropriate 
technology for a dense dfz core device.  It's a tool in the toolbox, one 
of many.


Nick

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Mon, Oct 2, 2023 at 1:18 AM Nick Hilliard  wrote:
> The difficulty with this is that if you end up with a
> FIB overflow, your router will no longer route.

Hi Nick,

That depends. When the FIB gets too big, routers don't immediately
die. Instead, their performance degrades. Just like what happens with
oversubscription elsewhere in the system.

With a TCAM-based router, the least specific routes get pushed off the
TCAM (out of the fast path) up to the main CPU. As a result, the PPS
(packets per second) degrades really fast.

With a DRAM+SRAM cache system, the least used routes fall out of the
cache. They haven't actually been pushed out of the fast path, but the
fast path gets a little bit slower. The PPS degrades, but not as
sharply as with a TCAM-based router.


> That said, there are cases where FIB compression makes a lot of sense,
> e.g. leaf sites, etc. Conversely, it's not a generally appropriate
> technology for a dense dfz core device.  It's a tool in the toolbox, one
> of many.

The case for FIB compression deep in the core is... not as obvious as
the case near the edge for sure. But I wouldn't discount it on any
installation that has a reasonably defined notion of "upstream," as
opposed to installations where the only sorts of interfaces are either
lateral or downstream.

Look at it this way: here are some numbers from last Friday's BGP report:

BGP routing table entries examined:  930281
Prefixes after maximum aggregation (per Origin AS):  353509
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  453312

Obviously adjacent routes to the same AS aren't always going to have
the same next hop. But I'll bet you that they do more often than not,
even deep in the core. Even if only half the adjacent routes from the
same AS have the same next hop when found deep in the core, according
to these numbers that's still a 30% compression. If you keep a 10%
slack for transients, you still have a 20% net gain in your
equipment's capability versus no compression.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Jon Lewis]

On Mon, 2 Oct 2023, Jakob Heitz (jheitz) via NANOG wrote:


While I did allude to some of the complexity, my main point

is that FIB compression does not allow you to install a FIB with less memory.

Because you must be prepared for transients during which the FIB needs to store

mostly uncompressed anyway.

All it does is to increase convergence time.


In my experience, that's incorrect.  FIB compression allows you to run 
with full tables on devices that can no longer accommodate full 
[uncompressed] tables in whatever is used to store FIB.  Obviously, it 
does require more RAM due to the complexities of keeping track of more 
state.  But RAM is typically far more easily upgraded (cheaply) than TCAM.


Even if it does increase convergence time, that's a compromise many 
are willing to make if the alternative is toss your current gear and 
replace it with newer gear years sooner.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

>
> That depends. When the FIB gets too big, routers don't immediately
> die. Instead, their performance degrades. Just like what happens with
> oversubscription elsewhere in the system.
>

If you consider blackholing traffic because the relevant next-hops aren't
present in the FIB to be looked up as "degradation" I guess?

 If you keep a 10%
> slack for transients, you still have a 20% net gain in your
> equipment's capability versus no compression.
>

This ignores whatever % of something else you have up to get effective
compression.

On Mon, Oct 2, 2023 at 4:41 AM William Herrin  wrote:

> On Mon, Oct 2, 2023 at 1:18 AM Nick Hilliard  wrote:
> > The difficulty with this is that if you end up with a
> > FIB overflow, your router will no longer route.
>
> Hi Nick,
>
> That depends. When the FIB gets too big, routers don't immediately
> die. Instead, their performance degrades. Just like what happens with
> oversubscription elsewhere in the system.
>
> With a TCAM-based router, the least specific routes get pushed off the
> TCAM (out of the fast path) up to the main CPU. As a result, the PPS
> (packets per second) degrades really fast.
>
> With a DRAM+SRAM cache system, the least used routes fall out of the
> cache. They haven't actually been pushed out of the fast path, but the
> fast path gets a little bit slower. The PPS degrades, but not as
> sharply as with a TCAM-based router.
>
>
> > That said, there are cases where FIB compression makes a lot of sense,
> > e.g. leaf sites, etc. Conversely, it's not a generally appropriate
> > technology for a dense dfz core device.  It's a tool in the toolbox, one
> > of many.
>
> The case for FIB compression deep in the core is... not as obvious as
> the case near the edge for sure. But I wouldn't discount it on any
> installation that has a reasonably defined notion of "upstream," as
> opposed to installations where the only sorts of interfaces are either
> lateral or downstream.
>
> Look at it this way: here are some numbers from last Friday's BGP report:
>
> BGP routing table entries examined:  930281
> Prefixes after maximum aggregation (per Origin AS):  353509
> Deaggregation factor:  2.63
> Unique aggregates announced (without unneeded subnets):  453312
>
> Obviously adjacent routes to the same AS aren't always going to have
> the same next hop. But I'll bet you that they do more often than not,
> even deep in the core. Even if only half the adjacent routes from the
> same AS have the same next hop when found deep in the core, according
> to these numbers that's still a 30% compression. If you keep a 10%
> slack for transients, you still have a 20% net gain in your
> equipment's capability versus no compression.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: maximum ipv4 bgp prefix length of /24 ?

[t...@pelican.org]

On Monday, 2 October, 2023 09:39, "William Herrin"  said:

> That depends. When the FIB gets too big, routers don't immediately
> die. Instead, their performance degrades. Just like what happens with
> oversubscription elsewhere in the system.
> 
> With a TCAM-based router, the least specific routes get pushed off the
> TCAM (out of the fast path) up to the main CPU. As a result, the PPS
> (packets per second) degrades really fast.
> 
> With a DRAM+SRAM cache system, the least used routes fall out of the
> cache. They haven't actually been pushed out of the fast path, but the
> fast path gets a little bit slower. The PPS degrades, but not as
> sharply as with a TCAM-based router.

Spit-balling here, is there a possible design for not-Tier-1 providers where 
routing optimality (which is probably not a word) degrades rather than 
packet-shifting performance?

If the FIB is full, can we start making controlled and/or smart decisions about 
what to install, rather than either of the simple overflow conditions?

For starters, as long as you have *somewhere* you can point a default at in the 
worst case, even if it's far from the *best* route, you make damn sure you 
always install a default.

Then you could have knobs for what other routes you discard when you run out of 
space.  Receiving a covering /16?  Maybe you can drop the /24s, even if they 
have a different next hop - routing will be sub-optimal, but it will work.   (I 
know, previous discussions around traffic engineering and whether the 
originating network must / does do that in practice...)

Understand which routes your customers care about / where most of your traffic 
goes?  Set the "FIB-preference" on those routes as you receive them, to give 
them the greatest chance of getting installed.

Not a hardware designer, I have little idea as to how feasible this is - I 
suspect it depends on the rate of churn, complexity of FIB updates, etc.  But 
it feels like there could be a way to build something other than "shortest -> 
punt to CPU" or "LRU -> punt to CPU".

Or is everyone who could make use of this already doing the same filtering at 
the RIB level, and not trying to fit a quart RIB into a pint FIB in the first 
place?

Thanks,
Tim.

Re: maximum ipv4 bgp prefix length of /24 ?

[Joshua Miller]

Seems like we've reached the limits of apriori speculation. At this point
I'd like to see data demonstrating that it's at least viable from a
statistical perspective.

If someone is motivated to demonstrate this, a "backtest" against
historical data would be the next step. Later, one could design the study
to reveal "transient degradation" (loops, drops, etc.) and their
probability, though the duration would be more a function of the
implementation. It would be best to "backtest" the status quo as a control
because it too has transient degradation, for a more apples-to-apples
comparison.

I'm not sufficiently motivated (nor knowledgeable in statistics) to take
this on. I see this more in the domain of vendors to determine the best
approach for their implementation.

On Mon, Oct 2, 2023 at 9:21 AM t...@pelican.org  wrote:

> On Monday, 2 October, 2023 09:39, "William Herrin"  said:
>
> > That depends. When the FIB gets too big, routers don't immediately
> > die. Instead, their performance degrades. Just like what happens with
> > oversubscription elsewhere in the system.
> >
> > With a TCAM-based router, the least specific routes get pushed off the
> > TCAM (out of the fast path) up to the main CPU. As a result, the PPS
> > (packets per second) degrades really fast.
> >
> > With a DRAM+SRAM cache system, the least used routes fall out of the
> > cache. They haven't actually been pushed out of the fast path, but the
> > fast path gets a little bit slower. The PPS degrades, but not as
> > sharply as with a TCAM-based router.
>
> Spit-balling here, is there a possible design for not-Tier-1 providers
> where routing optimality (which is probably not a word) degrades rather
> than packet-shifting performance?
>
> If the FIB is full, can we start making controlled and/or smart decisions
> about what to install, rather than either of the simple overflow conditions?
>
> For starters, as long as you have *somewhere* you can point a default at
> in the worst case, even if it's far from the *best* route, you make damn
> sure you always install a default.
>
> Then you could have knobs for what other routes you discard when you run
> out of space.  Receiving a covering /16?  Maybe you can drop the /24s, even
> if they have a different next hop - routing will be sub-optimal, but it
> will work.   (I know, previous discussions around traffic engineering and
> whether the originating network must / does do that in practice...)
>
> Understand which routes your customers care about / where most of your
> traffic goes?  Set the "FIB-preference" on those routes as you receive
> them, to give them the greatest chance of getting installed.
>
> Not a hardware designer, I have little idea as to how feasible this is - I
> suspect it depends on the rate of churn, complexity of FIB updates, etc.
> But it feels like there could be a way to build something other than
> "shortest -> punt to CPU" or "LRU -> punt to CPU".
>
> Or is everyone who could make use of this already doing the same filtering
> at the RIB level, and not trying to fit a quart RIB into a pint FIB in the
> first place?
>
> Thanks,
> Tim.
>
>
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

>
> Then you could have knobs for what other routes you discard when you run
> out of space.  Receiving a covering /16?  Maybe you can drop the /24s, even
> if they have a different next hop - routing will be sub-optimal, but it
> will work.   (I know, previous discussions around traffic engineering and
> whether the originating network must / does do that in practice...)
>

What you are describing is exactly what the /24 convention is doing
already, just with different mask lengths.

By and large, RIB/FIB size can be effectively managed today by thoughtful
use of policies. If a point is reached that doesn't work anymore, it's
_probably_ time to re-evaluate the hardware or the design.

On Mon, Oct 2, 2023 at 9:20 AM t...@pelican.org  wrote:

> On Monday, 2 October, 2023 09:39, "William Herrin"  said:
>
> > That depends. When the FIB gets too big, routers don't immediately
> > die. Instead, their performance degrades. Just like what happens with
> > oversubscription elsewhere in the system.
> >
> > With a TCAM-based router, the least specific routes get pushed off the
> > TCAM (out of the fast path) up to the main CPU. As a result, the PPS
> > (packets per second) degrades really fast.
> >
> > With a DRAM+SRAM cache system, the least used routes fall out of the
> > cache. They haven't actually been pushed out of the fast path, but the
> > fast path gets a little bit slower. The PPS degrades, but not as
> > sharply as with a TCAM-based router.
>
> Spit-balling here, is there a possible design for not-Tier-1 providers
> where routing optimality (which is probably not a word) degrades rather
> than packet-shifting performance?
>
> If the FIB is full, can we start making controlled and/or smart decisions
> about what to install, rather than either of the simple overflow conditions?
>
> For starters, as long as you have *somewhere* you can point a default at
> in the worst case, even if it's far from the *best* route, you make damn
> sure you always install a default.
>
> Then you could have knobs for what other routes you discard when you run
> out of space.  Receiving a covering /16?  Maybe you can drop the /24s, even
> if they have a different next hop - routing will be sub-optimal, but it
> will work.   (I know, previous discussions around traffic engineering and
> whether the originating network must / does do that in practice...)
>
> Understand which routes your customers care about / where most of your
> traffic goes?  Set the "FIB-preference" on those routes as you receive
> them, to give them the greatest chance of getting installed.
>
> Not a hardware designer, I have little idea as to how feasible this is - I
> suspect it depends on the rate of churn, complexity of FIB updates, etc.
> But it feels like there could be a way to build something other than
> "shortest -> punt to CPU" or "LRU -> punt to CPU".
>
> Or is everyone who could make use of this already doing the same filtering
> at the RIB level, and not trying to fit a quart RIB into a pint FIB in the
> first place?
>
> Thanks,
> Tim.
>
>
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

First, no, a transient where all route disaggregating disappears from the 
global table is extraordinarily unlikely. 

Second, as I understand it, each update cycle results in rebuilding the fib 
from scratch rather than figuring out how to splice and dice it, so the 
computation required to cope with that single /24 change isn’t exactly as 
described. 

Finally, unless that /24 change ends up changing the exit interface or next-hop 
on the exit interface (which decreases in probability with topological 
distance), it wouldn’t actually change the fib content. 

The process of downloading a new fib to line cards from the RE is very fast. 
Break before make may be tolerable risk. It won’t lose a statistically 
significant number of packets in a single event. If events are occurring 
frequently enough to be an issue, then I think the route flapping is a bigger 
problem than the lost packets. 

YMMV

Owen


> On Oct 1, 2023, at 21:55, Jakob Heitz (jheitz) via NANOG  
> wrote:
> 
> 
> While I did allude to some of the complexity, my main point
> is that FIB compression does not allow you to install a FIB with less memory.
> Because you must be prepared for transients during which the FIB needs to 
> store
> mostly uncompressed anyway.
> All it does is to increase convergence time.
>  
> Kind Regards,
> Jakob
>  
>  
> From: William Herrin 
> Date: Sunday, October 1, 2023 at 6:32 PM
> To: Jakob Heitz (jheitz) 
> Cc: nanog@nanog.org 
> Subject: Re: maximum ipv4 bgp prefix length of /24 ?
> 
> On Sun, Oct 1, 2023 at 5:40 PM Jakob Heitz (jheitz) via NANOG
>  wrote:
> > Among the issues:
> > Suppose the FIB has all the /24 components to make a /20, so it programs a 
> > /20.
> > Then one of the /24's changes nexthop. It now has to undo all that 
> > compression
> 
> Yeah... all this stuff is on the same level of complexity as
> implementing a B-Tree. Standard task on the road to an undergraduate
> computer science degree. Compared to decoding a BGP update message,
> where nearly everything is variable length and you have to nibble away
> at the current field to find the start of the next field, this is a
> cakewalk.
> 
> It doesn't actually get complicated until you want to do more than
> just joining adjacent address blocks.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

> On Oct 2, 2023, at 01:18, Nick Hilliard  wrote:
> 
> William Herrin wrote on 02/10/2023 08:56:
>> All it means is that you have to keep an eye on your FIB
>> size as well, since it's no longer the same as your RIB size.
> 
> the point Jacob is making is is that when using FIB compression, the FIB size 
> depends on both RIB size and RIB complexity.  I.e. what was previously a 
> deterministic 1:1 ratio between RIB and FIB - which is straightforward to 
> handle from an operational point of view - becomes non-deterministic. The 
> difficulty with this is that if you end up with a FIB overflow, your router 
> will no longer route.

It was never 1:1 if you have more than one path for any route. The FIB only 
contains the chosen path(s) to any destination even without fib compression. 

> 
> That said, there are cases where FIB compression makes a lot of sense, e.g. 
> leaf sites, etc. Conversely, it's not a generally appropriate technology for 
> a dense dfz core device.  It's a tool in the toolbox, one of many.

Even at a dense DFZ core device, there are a large number of single-origin 
consecutive /24s in the table which can be fib compressed with no loss. For a 
long time, someone was teaching up and coming operators in Asia that they 
should always announce everything as disaggregated /24s to guard against route 
hijacking. This unfortunate practice persists still, making FIB compression 
quite practical even at core nodes. 

Owen

> 
> Nick

Re: maximum ipv4 bgp prefix length of /24 ?

[Owen DeLong via NANOG]

Isn’t that pretty much what Geoff Huston has done with the weekly reports William quoted earlier in this thread?Sure, that’s from a limited set of perspectives, but it probably represents the minimum achievable compression in most circumstances. OwenOn Oct 2, 2023, at 06:41, Joshua Miller  wrote:Seems like we've reached the limits of apriori speculation. At this point I'd like to see data demonstrating that it's at least viable from a statistical perspective. If someone is motivated to demonstrate this, a "backtest" against historical data would be the next step. Later, one could design the study to reveal "transient degradation" (loops, drops, etc.) and their probability, though the duration would be more a function of the implementation. It would be best to "backtest" the status quo as a control because it too has transient degradation, for a more apples-to-apples comparison.I'm not sufficiently motivated (nor knowledgeable in statistics) to take this on. I see this more in the domain of vendors to determine the best approach for their implementation.On Mon, Oct 2, 2023 at 9:21 AM t...@pelican.org  wrote:On Monday, 2 October, 2023 09:39, "William Herrin"  said:

> That depends. When the FIB gets too big, routers don't immediately
> die. Instead, their performance degrades. Just like what happens with
> oversubscription elsewhere in the system.
> 
> With a TCAM-based router, the least specific routes get pushed off the
> TCAM (out of the fast path) up to the main CPU. As a result, the PPS
> (packets per second) degrades really fast.
> 
> With a DRAM+SRAM cache system, the least used routes fall out of the
> cache. They haven't actually been pushed out of the fast path, but the
> fast path gets a little bit slower. The PPS degrades, but not as
> sharply as with a TCAM-based router.

Spit-balling here, is there a possible design for not-Tier-1 providers where routing optimality (which is probably not a word) degrades rather than packet-shifting performance?

If the FIB is full, can we start making controlled and/or smart decisions about what to install, rather than either of the simple overflow conditions?

For starters, as long as you have *somewhere* you can point a default at in the worst case, even if it's far from the *best* route, you make damn sure you always install a default.

Then you could have knobs for what other routes you discard when you run out of space.  Receiving a covering /16?  Maybe you can drop the /24s, even if they have a different next hop - routing will be sub-optimal, but it will work.   (I know, previous discussions around traffic engineering and whether the originating network must / does do that in practice...)

Understand which routes your customers care about / where most of your traffic goes?  Set the "FIB-preference" on those routes as you receive them, to give them the greatest chance of getting installed.

Not a hardware designer, I have little idea as to how feasible this is - I suspect it depends on the rate of churn, complexity of FIB updates, etc.  But it feels like there could be a way to build something other than "shortest -> punt to CPU" or "LRU -> punt to CPU".

Or is everyone who could make use of this already doing the same filtering at the RIB level, and not trying to fit a quart RIB into a pint FIB in the first place?

Thanks,
Tim.

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Mon, Oct 2, 2023 at 6:40 AM Joshua Miller  wrote:
> At this point I'd like to see data demonstrating that it's at least viable 
> from a statistical perspective.

https://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p111.pdf
https://yangtonghome.github.io/uploads/MAoFIBC.pdf

More where those came from if you google "BGP FIB compression paper."

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Mon, Oct 2, 2023 at 6:05 AM Tom Beecher  wrote:
>> That depends. When the FIB gets too big, routers don't immediately
>> die. Instead, their performance degrades. Just like what happens with
>> oversubscription elsewhere in the system.
>
> If you consider blackholing traffic because the relevant next-hops aren't 
> present in the FIB to be looked up as "degradation" I guess?

Come on man, go re-read the post. The two paragraphs you cut literally
explained what happens -instead of- routes dropping out of the FIB or
being black holed.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Matthew Petach]

On Mon, Oct 2, 2023 at 6:21 AM t...@pelican.org  wrote:

> On Monday, 2 October, 2023 09:39, "William Herrin"  said:
>
> > That depends. When the FIB gets too big, routers don't immediately
> > die. Instead, their performance degrades. Just like what happens with
> > oversubscription elsewhere in the system.
> >
> > With a TCAM-based router, the least specific routes get pushed off the
> > TCAM (out of the fast path) up to the main CPU. As a result, the PPS
> > (packets per second) degrades really fast.
> >
> > With a DRAM+SRAM cache system, the least used routes fall out of the
> > cache. They haven't actually been pushed out of the fast path, but the
> > fast path gets a little bit slower. The PPS degrades, but not as
> > sharply as with a TCAM-based router.
>
> Spit-balling here, is there a possible design for not-Tier-1 providers
> where routing optimality (which is probably not a word) degrades rather
> than packet-shifting performance?
>
> If the FIB is full, can we start making controlled and/or smart decisions
> about what to install, rather than either of the simple overflow conditions?
>
> For starters, as long as you have *somewhere* you can point a default at
> in the worst case, even if it's far from the *best* route, you make damn
> sure you always install a default.
>
> Then you could have knobs for what other routes you discard when you run
> out of space.  Receiving a covering /16?  Maybe you can drop the /24s, even
> if they have a different next hop - routing will be sub-optimal, but it
> will work.   (I know, previous discussions around traffic engineering and
> whether the originating network must / does do that in practice...)
>

The problem with this approach is you now have non-deterministic routing.

Depending on the state of FIB compression, packets *may* flow out
interfaces that are not what the RIB thinks they will be.
This can be a good recipe for routing micro-loops that come and go as your
FIB compression size ebbs and flows.

Taking your example:RTR-A--RTR-B-RTR-C
RTR-A is announcing a /16 to RTR-B
RTR-C is announcing a /24 from within the /16 to RTR-B, which is passing it
along to RTR-A

If RTR-B's FIB compression fills up, and falls back to "drop the /24, since
I see a /16", packets destined to the /24 arriving from RTR-A will reach
RTR-B,
which will check its FIB, and send them back towards RTR-Awhich will
send them back to RTR-B, until TTL is exceeded.

BTW, this scenario holds true even when it's a default route coming from
RTR-A, so saying "well, OK, but we can do FIB compression easily as long as
we have a default route to fall back on" still leads to packet-ping-ponging
on your upstream interface towards your default if you ever drop a more
specific from your FIB that is destined downstream of you.

You're better off doing the filtering at the RIB end of things, so that
RTR-B no longer passes the /24 to RTR-A; sure, routing breaks at that
point, but at least you haven't filled up the RTR-A to RTR-B link with
packets ping-ponging back and forth.

Your routing protocols *depend* on packets being forwarded along the
interfaces the RIB thinks they'll be going out in order for loop-free
routing to occur.
If the FIB decisions are made independent of the RIB state, your routing
protocols might as well just give up and go home, because no matter how
many times they run Dijkstra, the path to the destination isn't going to
match where the packets ultimately end up going.

You could of course fix this issue by propagating the decisions made by the
FIB compression algorithm back up into the RIB; at least then, the network
engineer being paged at 3am to figure out why a link is full will instead
be paged to figure out why routes aren't showing up in the routing table
that policy *says* should be showing up.

Understand which routes your customers care about / where most of your
> traffic goes?  Set the "FIB-preference" on those routes as you receive
> them, to give them the greatest chance of getting installed.
>
> Not a hardware designer, I have little idea as to how feasible this is - I
> suspect it depends on the rate of churn, complexity of FIB updates, etc.
> But it feels like there could be a way to build something other than
> "shortest -> punt to CPU" or "LRU -> punt to CPU".
>
> Or is everyone who could make use of this already doing the same filtering
> at the RIB level, and not trying to fit a quart RIB into a pint FIB in the
> first place?
>

The sane ones who care about the sanity of their network engineers
certainly do.   ^_^;



> Thanks,
> Tim.
>


Thanks!

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[Tom Beecher]

>
> Come on man, go re-read the post. The two paragraphs you cut literally
> explained what happens -instead of- routes dropping out of the FIB or
> being black holed.
>

Ok

On Mon, Oct 2, 2023 at 2:03 PM William Herrin  wrote:

> On Mon, Oct 2, 2023 at 6:05 AM Tom Beecher  wrote:
> >> That depends. When the FIB gets too big, routers don't immediately
> >> die. Instead, their performance degrades. Just like what happens with
> >> oversubscription elsewhere in the system.
> >
> > If you consider blackholing traffic because the relevant next-hops
> aren't present in the FIB to be looked up as "degradation" I guess?
>
> Come on man, go re-read the post. The two paragraphs you cut literally
> explained what happens -instead of- routes dropping out of the FIB or
> being black holed.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: maximum ipv4 bgp prefix length of /24 ?

[Tim Franklin]

On 02/10/2023 19:24, Matthew Petach wrote:


The problem with this approach is you now have non-deterministic routing.

Depending on the state of FIB compression, packets *may* flow out 
interfaces that are not what the RIB thinks they will be.
This can be a good recipe for routing micro-loops that come and go as 
your FIB compression size ebbs and flows.


Had NOT considered the looping - that's what you get for writing in 
public without thinking it all the way through *blush*.


Thanks for poking holes appropriately,
Tim.

Re: maximum ipv4 bgp prefix length of /24 ?

[Mark Tinka]

On 10/2/23 20:44, Tim Franklin wrote:

Had NOT considered the looping - that's what you get for writing in 
public without thinking it all the way through *blush*.


Thanks for poking holes appropriately,



Like I said, it's going to be a messy experiment - for probably a 
decade, at least.


As Saku has highlighted as well, vendors are likely to find a lot of 
sludge in this experiment that they will never be able to share with 
us... likely because it will be too complicated for us to understand in 
a coherent way, or likely because the experiment changes so rapidly it 
makes no sense to tell us about issues which will quickly become obsolete.


Many lessons will be learned, but ultimately, one would be naive to 
think this black box will just work.


All I want is a "set routing-options fib-compression disable" present 
for Christmas.


Mark.

Re: maximum ipv4 bgp prefix length of /24 ?

[Matthew Petach]

On Mon, Oct 2, 2023 at 11:46 AM Tim Franklin  wrote:

> On 02/10/2023 19:24, Matthew Petach wrote:
>
> The problem with this approach is you now have non-deterministic routing.
>
> Depending on the state of FIB compression, packets *may* flow out
> interfaces that are not what the RIB thinks they will be.
> This can be a good recipe for routing micro-loops that come and go as your
> FIB compression size ebbs and flows.
>
> Had NOT considered the looping - that's what you get for writing in public
> without thinking it all the way through *blush*.
>
> Thanks for poking holes appropriately,
> Tim.
>

No worries--if this were easy, we would have been doing it decades ago
without thinking twice.

To William's point to Tom--we are perhaps using the term "compression" in
incompatible ways at times during this conversation.

There is a difference between what the papers Williams cited are doing,
which is finding more optimal ways of storing the full structure in memory
with what I think the general thread here is talking about, which is
'proxy-aggregation' of a form--reducing the actual number of entries in the
forwarding table, regardless of the *method* of storage.

"FIB compression" of the form talked about in the papers William cited is
already being done; we don't store whole string representations of the
routing table in memory, and look them up sequentially, we store them in
binary tries, which are faster and take up less space (e, compressed), but
they still encode and represent the *whole* set of prefixes in the
forwarding table.

"FIB-count-reduction" would be a more accurate term for what we're tossing
about here, and that's where dragons lie, because that's where your FIB and
RIB no longer represent the same set of information.  And while Jon is
right, it can help struggling ISPs stave off expensive upgrades, it does so
at the cost of potentially increased troubleshooting nightmares when
packets stop going where the RIB expects them to go, and network engineers
are left scratching their heads trying to figure out why.   ^_^;

As Mark just said--sane ISPs push their vendor for a knob to disable it, so
that they can return back the land of deterministic lookups for the sanity
of their engineers.  ;)

Thanks!

Matt

Re: maximum ipv4 bgp prefix length of /24 ?

[William Herrin]

On Mon, Oct 2, 2023 at 12:27 PM Matthew Petach  wrote:
> There is a difference between what the papers William cited are doing, which 
> is finding more optimal ways of storing the full structure in memory with 
> what I think the general thread here is talking about, which is 
> 'proxy-aggregation' of a form--reducing the actual number of entries in the 
> forwarding table, regardless of the *method* of storage.
>
> "FIB compression" of the form talked about in the papers William cited is 
> already being done; we don't store whole string representations of the 
> routing table in memory, and look them up sequentially, we store them in 
> binary tries, which are faster and take up less space (e, compressed), but 
> they still encode and represent the *whole* set of prefixes in the forwarding 
> table.


Hi Matthew,

Either you're misreading the papers or I quoted the wrong ones.
Apologies if it's the latter.

The RIB is stored in a trie (a radix tree) in essentially all router
implementations. From there it's processed into a FIB whose design
depends on the hardware implementing it. For a software implementation
that's another trie, sometimes with hash-based cache of current
activity. For a TCAM, it's an array ordered from most specific to
least specific. (TCAMs are special hardware that processes every array
element simultaneously instead of linearly.) These structures don't
change with FIB compression. What changes is the number of routes
stored in them and the complexity of the software that translates the
RIB into a FIB.


> As Mark just said--sane ISPs push their vendor for a knob to disable it, so 
> that they can return back the land of deterministic lookups for the sanity of 
> their engineers.  ;)

Just so it doesn't get lost - I endorse that idea as well. With a very
few exceptions, I think the operator should have sufficient knobs to
control how their equipment does its work. The developer doesn't (and
can't) know all of the situations the operator will encounter, so
can't plan his software to be smart enough to always do the right
thing on its own. The exceptions deal with knobs where the operator is
not just likely shoot themselves in the foot but  likely shoot other
people too. That doesn't apply here.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: maximum ipv4 bgp prefix length of /24 ?

[Jakob Heitz (jheitz) via NANOG]

On a related note, I'm working on a project to handle FIB overflow in
such a way as to cause the least disruption in the network.

I welcome suggestions either on or off list.

Kind Regards,
Jakob