[arin-ppml] Rationale for /22

[Joel Jaeggli]

Scott Leibrand wrote:
> Let me ask the inverse (or is it converse?) question:
> 
> Do you have evidence that unaggregated /24's (still) break things?  I
> haven't seen any evidence myself in the last 5 years...

Not convinced that the growth in the number of dfz advertised prefixes
needs additional incentives beyond those already cooked in.

The assertion that cidr allowed us to step back from the abyss in the
era of 10k prefixs is I think well founded. As is the contribution of
stub AS to overall update rates.

It seems likely that at some point networks will likely routinely accept
longer prefixes than /24. There is already some good evidence of the
reachability of /25s. That something is inevitable, is in itself not a
reason to discourage it.

joel

> Thanks,
> Scott
> 
> Kevin Kargel wrote:
>> I haven't been following this closely, sometimes work intrudes, but
>> have we
>> all forgotten all the rationals that say that unaggregated /24's break
>> things?  Or are we assuming that everyone will be able to handle huge
>> routing tables or are we assuming that the /24 recipients don't care
>> if they
>> can route beyond peers? 
>> I realize that IP's will become a smaller pool, so maybe the thinking is
>> that when this triggers there won't be enough /24's left to significantly
>> affect the routing tables?
>>
>> I am still in the camp of "Keep doing what we are doing and when it
>> runs out
>> it runs out."  Rationing is not always a good idea.  Trying to stretch
>> out
>> resources indefinitely will be an exercize in futility.
>>
>>  
>>> -----Original Message-----
>>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>>> Behalf Of Joel Jaeggli
>>> Sent: Tuesday, July 28, 2009 9:33 AM
>>> To: William Herrin
>>> Cc: ARIN PPML
>>> Subject: Re: [arin-ppml] Rationale for /22
>>>
>>>
>>>
>>> William Herrin wrote:
>>>    
>>>> On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
>>>>      
>>>>> Bill Darte wrote:
>>>>>        
>>>>>> Every effort to lower minimum allocations throughout the years has
>>>>>> met
>>>>>> with resistance.  Each successful policy managed a 'bit at a time' to
>>>>>> ensure 'nothing bad happened'....
>>>>>>           
>>>>> Realistically is it in the interest of a prospective multihomer to a
>>>>> recieve a prefix that's likely longer than the one they already use?
>>>>>         
>>>> Joel,
>>>>
>>>> I don't follow your logic here. Why would a multihomer request less IP
>>>> addresses than he already uses, regardless of the minimum prefix size?
>>>>
>>>>
>>>>      
>>>>> How quickly does one chew up /32s /30 /28s in the process of
>>>>>         
>>> multihoming
>>>    
>>>>> the internet facing infrastructure in a smple-multihomed network?
>>>>>         
>>>> When I was at the DNC, I structured the network to justify a /22. I
>>>> really wanted a /23 but a /22 was what I could get.
>>>>
>>>> I'm faced with a similar situation today. I need a /24 but I'll
>>>> structure the network so that it justifies a /22. Just to be clear, I
>>>> won't tell a single lie. I'll simply structure the network so that
>>>> everything which could consume a public IP address does.
>>>>
>>>> I doubt my experience is unique. I expect that many if not most of the
>>>> /22 end-user requests are similarly padded, not because the registrant
>>>> actually wants that many addresses but because that's what they can
>>>> get.
>>>>
>>>> Given the shortage of IPv4 addresses, why structure the policies so
>>>> that we give anyone more than they actually want?
>>>>       
>>> The minimum number of addresses that can be used may not in fact reflect
>>> the minimum that should be used.
>>>
>>>     For the purposes of minimizing fragmention.
>>>
>>>     Supporting basic network operation (it's nice when traceroute
>>>     and pmtud work) because your intermediate routers are privately
>>>     numbered.
>>>
>>>     Limiting the consequences of imagination failure, which may
>>>     sound flippant but renumbering, requesting an additional block,
>>>     or and point one and two are good reasons to make a potential
>>>     multi-homer justify the assignment of a block of the appropriate
>>>     size for that activity.
>>>
>>>
>>>    
>>>> Regards,
>>>> Bill Herrin
>>>>
>>>>
>>>>       
>>> _______________________________________________
>>> 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.
> _______________________________________________
> 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.
>