[arin-ppml] CIDR v2.0

[Kevin Kargel]

I wasn't advocating enforced route aggregation as a viable method..  I was
just stating it is the only way I know of to allow >24bit network
allocations and make them work given todays routing hardware.

If route tables are going to multiply, which is what would happen if subC PI
networks became common, routing hardware would have to make a quantum leap
in power.  

I run mid level (Cisco 10K, 72xx, 76xx) enterprise routers, and they do not
have a lot of excess space or power for the route tables I manage today.
Even doubling or tripling the size of the route tables would cause problems,
much less the increase we would see if sub-C PI space became common.  

I am sure that there are millions of business cases for routing sub-C
networks, but stuffing the route tables like that before hardware to handle
them is available and affordable will bring us to critical mass in short
order.


> -----Original Message-----
> From: bmanning at vacation.karoshi.com 
> [mailto:bmanning at vacation.karoshi.com] 
> Sent: Tuesday, September 16, 2008 1:24 PM
> To: Kevin Kargel
> Cc: PPML
> Subject: Re: [arin-ppml] CIDR v2.0
> 
> 
> 	Kevin, 
> 		in some ideal world, aggregation into some small set of
> 	"ISP" space would be fine.  but things have not worked 
> out that way.
> 	for efficent address utilization, I expect we will see 
> >24 bit allocations
> 	more and more.  esp if that is all you need to support 
> a translation function.
> 
> --bill
> 
> 
> 
> On Tue, Sep 16, 2008 at 08:11:51AM -0500, Kevin Kargel wrote:
> > The difficulty with this is that we already have problems 
> of hardware 
> > that is insufficient to support the routing tables.  ISP's 
> are already 
> > filtering long CIDR routes (>24bit) because there isn't sufficient 
> > memory or processor in the hardware to support the number 
> of routes it 
> > would require.
> > 
> > Your idea would work, but only if we got rid of PI space and forced 
> > everyone to use IP space from their ISP so that there could be 
> > efficient route aggregation.  If you search through threads 
> you will 
> > see that there is violent opposition by end users who want to be 
> > provider independent.
> > 
> > > -----Original Message-----
> > > From: arin-ppml-bounces at arin.net
> > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Iljitsch van 
> > > Beijnum
> > > Sent: Tuesday, September 16, 2008 5:37 AM
> > > To: PPML PPML
> > > Subject: [arin-ppml] CIDR v2.0
> > > 
> > > In the early 1990s IPv4 address space was running out. They fixed 
> > > this by changing routing protocols. Maybe we should try 
> to do that 
> > > again.
> > > 
> > > <history>
> > > 
> > > In the early days of the internet you could only use IPv4 
> addresses 
> > > as blocks of 16777216, 65536 or 256 addresses. 256 was 
> too small for 
> > > most people so 65536 was a popular choice, but there are 
> only some 
> > > 16000 of these class B blocks and it was looking like 
> those would be 
> > > exhausted by the mid-1990s.
> > > So they started giving people a bunch of class C blocks (256 
> > > addresses each) but now the routing tables started to explode 
> > > because a university that needed a single class B block 
> before now 
> > > used something like 16 class C blocks, which had to appear in 
> > > routing tables individually. To fix this, routing protocols, 
> > > especially BGP, were changed to be able to work with 
> address blocks 
> > > of arbitrary power of two sizes so address space and 
> routing table 
> > > slots could be managed much more efficiently. (This is "classless 
> > > interdomain routing".)
> > > 
> > > </history>
> > > 
> > > Now that IPv4 address space is becoming scarce again, why 
> not do the 
> > > same thing again? But now rather than arbitrary powers of 2, we 
> > > modify the protocols to work with arbitrary address ranges. I.e., 
> > > 192.0.2.27
> > > - 192.0.2.43.
> > > 
> > > To accommodate legacy routers that can't do lookups based 
> on ranges 
> > > we can put in backward compatibility mechanisms from
> > > BGP5 to BGP4 similar to the ones from BGP4 (with CIDR) to
> > > BGP3 (no CIDR).
> > > _______________________________________________
> > > PPML
> > > You are receiving this message because you are subscribed to the 
> > > ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > > 
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed 
> to the ARIN 
> > Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3107 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20080916/feae32c9/attachment.bin>