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..
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 Source Number 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_________
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 <jlewis@lewis.org> 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 Source Number 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
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 <nethead@gmail.com> 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 <jlewis@lewis.org <mailto:jlewis@lewis.org>> 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 Source Number 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
Wouldn’t /48s be a better solution to this need? Owen
On Sep 28, 2023, at 14:25, VOLKAN SALİH <volkan.salih.06@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..
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 <volkan.salih.06@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..
On Sep 28, 2023, at 21:14, VOLKAN SALİH <volkan.salih.06@gmail.com> 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 <volkan.salih.06@gmail.com> <mailto:volkan.salih.06@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..
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.
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.
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 <volkan.salih.06@gmail.com> 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.
On Fri, Sep 29, 2023 at 9:42 AM VOLKAN SALİH <volkan.salih.06@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
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 <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Matthew Petach <mpetach@netflight.com> Sent: Friday, September 29, 2023 10:31 AM To: VOLKAN SALİH <volkan.salih.06@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.06@gmail.com<mailto:volkan.salih.06@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
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 vwittkop@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 <ryan@rkhtech.org> 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 <nanog-bounces+ryan=rkhtech.org@nanog.org <mailto:nanog-bounces+ryan=rkhtech.org@nanog.org>> on behalf of Matthew Petach <mpetach@netflight.com <mailto:mpetach@netflight.com>> Sent: Friday, September 29, 2023 10:31 AM To: VOLKAN SALİH <volkan.salih.06@gmail.com <mailto:volkan.salih.06@gmail.com>> Cc: nanog list <nanog@nanog.org <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 <volkan.salih.06@gmail.com <mailto:volkan.salih.06@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
On Fri, Sep 29, 2023 at 10:42 AM Valerie Wittkop <vwittkop@nanog.org> 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
Answers inline…. ~ Valerie
On Sep 29, 2023, at 13:51, Matthew Petach <mpetach@netflight.com> wrote:
On Fri, Sep 29, 2023 at 10:42 AM Valerie Wittkop <vwittkop@nanog.org <mailto:vwittkop@nanog.org>> 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. ^_^; Sometimes the person responding does a reply all - so it will go directly back to the one person, and also the list, but the message to the list may be in moderation. I would suspect that is one way Owen would see and respond. (Note, my reply all here goes directly to you and cc’s 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). I will have to look into the Discourse mirror, because it shouldn’t hit there before it clears the queue in mailman. Also, I’m 95% certain you can’t respond to the list from Discourse - it is a one way mirror. But that is probably now something on my list to confirm and make sure I’ve got the logistics figured out.
Thank you again for the quick reply, and all the great work you do for the community, Valerie--you totally ROCK! :) Thanks, Matt!
Thanks!
Matt
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 <volkan.salih.06@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
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 <volkan.salih.06@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 <volkan.salih.06@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
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 <volkan.salih.06@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 <volkan.salih.06@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
Please, let’s keep politics out of nanog… Kind Regards Dominik [https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/ci...] Dominik Dobrowolski Technical Consulting Engineer dodobrow@cisco.com<mailto:dodobrow@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 <nanog-bounces+dodobrow=cisco.com@nanog.org> On Behalf Of VOLKAN SALIH Sent: Friday, September 29, 2023 7:59 PM To: Tom Beecher <beecher@beecher.cc> Cc: nanog list <nanog@nanog.org> 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 <volkan.salih.06@gmail.com<mailto:volkan.salih.06@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 <volkan.salih.06@gmail.com<mailto:volkan.salih.06@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
On Fri, Sep 29, 2023 at 10:43 AM VOLKAN SALİH <volkan.salih.06@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,
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
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.com@nanog.org] On Behalf Of Owen DeLong via NANOG Sent: Friday, September 29, 2023 7:11 AM To: VOLKAN SALİH <volkan.salih.06@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 <volkan.salih.06@gmail.com<mailto:volkan.salih.06@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..
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.com@nanog.org] *On Behalf Of *Owen DeLong via NANOG *Sent:* Friday, September 29, 2023 7:11 AM *To:* VOLKAN SALİH <volkan.salih.06@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 <volkan.salih.06@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..
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 <nanog-bounces+jasonbaugher=adamstel.com@nanog.org> On Behalf Of VOLKAN SALIH Sent: Friday, September 29, 2023 2:45 AM To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; Owen DeLong <owen@delong.com> 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.com@nanog.org] On Behalf Of Owen DeLong via NANOG Sent: Friday, September 29, 2023 7:11 AM To: VOLKAN SALİH <volkan.salih.06@gmail.com><mailto:volkan.salih.06@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 <volkan.salih.06@gmail.com<mailto:volkan.salih.06@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.
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 <nanog-bounces+jasonbaugher=adamstel.com@nanog.org> *On Behalf Of *VOLKAN SALIH *Sent:* Friday, September 29, 2023 2:45 AM *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>; Owen DeLong <owen@delong.com> *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.com@nanog.org <mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org>] *On Behalf Of *Owen DeLong via NANOG *Sent:* Friday, September 29, 2023 7:11 AM *To:* VOLKAN SALİH <volkan.salih.06@gmail.com> <mailto:volkan.salih.06@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 <volkan.salih.06@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.
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 <volkan.salih.06@gmail.com> 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 <nanog-bounces+jasonbaugher=adamstel.com@nanog.org> <nanog-bounces+jasonbaugher=adamstel.com@nanog.org> *On Behalf Of *VOLKAN SALIH *Sent:* Friday, September 29, 2023 2:45 AM *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com> <vasilenko.eduard@huawei.com>; Owen DeLong <owen@delong.com> <owen@delong.com> *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.com@nanog.org <nanog-bounces+vasilenko.eduard=huawei.com@nanog.org>] *On Behalf Of *Owen DeLong via NANOG *Sent:* Friday, September 29, 2023 7:11 AM *To:* VOLKAN SALİH <volkan.salih.06@gmail.com> <volkan.salih.06@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 <volkan.salih.06@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/> [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.
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.
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 <nanog@nanog.org> 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.
On Fri, Sep 29, 2023 at 12:54 PM Collider <large.hadron.collider@gmx.com> 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 bill@herrin.us https://bill.herrin.us/
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.
/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 <large.hadron.collider@gmx.com> 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 <nanog@nanog.org> 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.
s/DMS/DFZ/ — Not sure how autocrrect did that without me noticing, apologies.
On Sep 29, 2023, at 14:11, Owen DeLong via NANOG <nanog@nanog.org> 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 <large.hadron.collider@gmx.com> 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 <nanog@nanog.org> 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.
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 <volkan.salih.06@gmail.com> 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.com@nanog.org] On Behalf Of Owen DeLong via NANOG Sent: Friday, September 29, 2023 7:11 AM To: VOLKAN SALİH <volkan.salih.06@gmail.com> <mailto:volkan.salih.06@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 <volkan.salih.06@gmail.com <mailto:volkan.salih.06@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..
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 <nanog@nanog.org> 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 <volkan.salih.06@gmail.com> 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.com@nanog.org] On Behalf Of Owen DeLong via NANOG Sent: Friday, September 29, 2023 7:11 AM To: VOLKAN SALİH <volkan.salih.06@gmail.com> <mailto:volkan.salih.06@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 <volkan.salih.06@gmail.com <mailto:volkan.salih.06@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.
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 <large.hadron.collider@gmx.com> 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 <nanog@nanog.org> 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 <volkan.salih.06@gmail.com> 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.com@nanog.org] On Behalf Of Owen DeLong via NANOG Sent: Friday, September 29, 2023 7:11 AM To: VOLKAN SALİH <volkan.salih.06@gmail.com> <mailto:volkan.salih.06@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 <volkan.salih.06@gmail.com <mailto:volkan.salih.06@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.
On Sep 28, 2023, at 23:57, Vasilenko Eduard <vasilenko.eduard@huawei.com> 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.com@nanog.org] On Behalf Of Owen DeLong via NANOG Sent: Friday, September 29, 2023 7:11 AM To: VOLKAN SALİH <volkan.salih.06@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 <volkan.salih.06@gmail.com <mailto:volkan.salih.06@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..
On Thu, Sep 28, 2023 at 2:25 PM VOLKAN SALİH <volkan.salih.06@gmail.com> 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 bill@herrin.us https://bill.herrin.us/
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.
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.
On Thu, Sep 28, 2023 at 9:50 PM VOLKAN SALİH <volkan.salih.06@gmail.com> 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 bill@herrin.us https://bill.herrin.us/
Volkan, you are confusing routing and forwarding. Elmar. volkan.salih.06@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.
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 <volkan.salih.06@gmail.com> 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.
On Sat, 30 Sept 2023 at 09:42, Mark Tinka <mark@tinka.africa> 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
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
On Thu, Sep 28, 2023 at 9:54 PM Owen DeLong <owen@delong.com> 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 bill@herrin.us https://bill.herrin.us/
On Fri, 29 Sept 2023 at 08:24, William Herrin <bill@herrin.us> 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
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 <saku@ytti.fi> wrote:
On Fri, 29 Sept 2023 at 08:24, William Herrin <bill@herrin.us> 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
On Sep 28, 2023, at 22:29, Saku Ytti <saku@ytti.fi> wrote:
On Fri, 29 Sept 2023 at 08:24, William Herrin <bill@herrin.us> 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
On Thu, Sep 28, 2023 at 10:29 PM Saku Ytti <saku@ytti.fi> wrote:
On Fri, 29 Sept 2023 at 08:24, William Herrin <bill@herrin.us> 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 bill@herrin.us https://bill.herrin.us/
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 <bill@herrin.us> wrote:
On Thu, Sep 28, 2023 at 10:29 PM Saku Ytti <saku@ytti.fi> wrote:
On Fri, 29 Sept 2023 at 08:24, William Herrin <bill@herrin.us> 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 bill@herrin.us https://bill.herrin.us/
On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher <beecher@beecher.cc> 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 bill@herrin.us https://bill.herrin.us/
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 <bill@herrin.us> wrote:
On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher <beecher@beecher.cc> 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 bill@herrin.us https://bill.herrin.us/
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 <nanog-bounces+tony=wicks.co.nz@nanog.org> On Behalf Of Tom Beecher Sent: Saturday, September 30, 2023 11:03 AM To: William Herrin <bill@herrin.us> 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.
On Fri, Sep 29, 2023 at 3:03 PM Tom Beecher <beecher@beecher.cc> 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 bill@herrin.us https://bill.herrin.us/
On Sep 29, 2023, at 14:48, William Herrin <bill@herrin.us> wrote:
On Fri, Sep 29, 2023 at 2:13 PM Tom Beecher <beecher@beecher.cc> 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
On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong <owen@delong.com> 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 bill@herrin.us https://bill.herrin.us/
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 <bill@herrin.us> wrote:
On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong <owen@delong.com> 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 bill@herrin.us https://bill.herrin.us/
On Sep 29, 2023, at 15:14, William Herrin <bill@herrin.us> wrote:
On Fri, Sep 29, 2023 at 3:11 PM Owen DeLong <owen@delong.com> 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
On Fri, Sep 29, 2023 at 3:26 PM Owen DeLong <owen@delong.com> wrote:
On Sep 29, 2023, at 15:14, William Herrin <bill@herrin.us> 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 bill@herrin.us https://bill.herrin.us/
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.
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 <mark@tinka.africa> 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.
On Sun, 1 Oct 2023 at 06:07, Owen DeLong via NANOG <nanog@nanog.org> 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
On Sun, Oct 1, 2023 at 1:03 AM Saku Ytti <saku@ytti.fi> wrote:
On Sun, 1 Oct 2023 at 06:07, Owen DeLong via NANOG <nanog@nanog.org> 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
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
On Sun, Oct 1, 2023 at 11:25 AM Seth David Schoen <schoen@loyalty.org> 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
On Sun, 1 Oct 2023, Matthew Petach wrote:
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].
IMO, fib compression is a bandaid that allows putting off forklift upgrades. My personal experience with it has been that it [at least on Arista gear] works well (reducing the v4 table from ~925k routes to under 600k for devices with several full views and several dozen eBGP peers, even greater savings for internal devices that only see a full table of best paths from a couple of edge devices, and for v6, the savings are even greater). On Arista, I assume the failure mode will be the same as what happens when Lpm is exhausted without fib compression. Routes that don't fit are not programmed from the RIB to FIB, and bits of the Internet cease to be reachable. At that point, You'd have to simply reduce the number of routes accepted and hope you can get hardware upgrades done real soon. Anyone running Arista gear with Jericho/Jericho+ chips and full routes, AFAIK, must be using fib compression at this point, and probably has at least a couple more years to figure out their upgrade path. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Sun, 1 Oct 2023 at 21:19, Matthew Petach <mpetach@netflight.com> 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
On Sat, Sep 30, 2023 at 8:04 PM Owen DeLong via NANOG <nanog@nanog.org> 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 bill@herrin.us https://bill.herrin.us/
On Sep 29, 2023, at 13:43, William Herrin <bill@herrin.us> wrote:
On Thu, Sep 28, 2023 at 10:29 PM Saku Ytti <saku@ytti.fi> wrote:
On Fri, 29 Sept 2023 at 08:24, William Herrin <bill@herrin.us> 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
On Fri, 29 Sept 2023 at 23:43, William Herrin <bill@herrin.us> 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
Hi, For testing/research take a look on dn42.net. Thanks, -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662 ________________________________ Od: NANOG <nanog-bounces+drixter=e-utp.net@nanog.org> w imieniu użytkownika VOLKAN SALİH <volkan.salih.06@gmail.com> Wysłane: czwartek, 28 września 2023 23:25 Do: nanog@nanog.org <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..
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.
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/
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..
participants (23)
-
Collider -
Daniel Corbe -
Dominik Dobrowolski (dodobrow) -
Elmar K. Bins -
Jason Baugher -
Joe Hamelin -
Jon Lewis -
Marcin Gondek -
Mark Tinka -
Matthew Petach -
Mike Lyon -
Owen DeLong -
Robert Blayzor -
Ryan Hamel -
Saku Ytti -
Seth David Schoen -
Seth Mattinen -
Tom Beecher -
Tony Wicks -
Valerie Wittkop -
Vasilenko Eduard -
VOLKAN SALİH -
William Herrin