[arin-ppml] Rationale for /22

[Kevin Kargel]

> 
>   Obviously the primary reason for a limit is the accepted minimum routing
> entry size of a /24.  Of course, you knew that.  So why ask the question?

Perhaps it is time to examine the 'accepted minimum routing entry size'.  If
it won't cause problems then why not extend the mask size?  Or are you
saying that long mask route entries do in fact cause problems?

> 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Kevin Kargel
> Sent: Tuesday, July 28, 2009 12:30 PM
> To: William Herrin; Joel Jaeggli
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> Based on what everyone is saying about the /24 issue - and for the purpose
> of argument accepting that /24 will cause no problems - then why not take
> it a step further and remove any maximum length netmask restriction for a
> multi-homed entity with a single allocation.
> 
> One entity with one allocation will generate one table entry regardless of
> what size it is, so why limit them to a /24.  I am sure there are entities
> out there who could operate just fine out of a /25 or even a /32, and so
> long as they are not creating gratuitous route table entries then we could
> be more efficient allowing them to only consume the space they need.
> 
> 
> 
> 
> > -----Original Message-----
> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
> > On Behalf Of William Herrin
> > Sent: Tuesday, July 28, 2009 10:30 AM
> > To: Joel Jaeggli
> > Cc: ARIN PPML
> > Subject: Re: [arin-ppml] Rationale for /22
> >
> > On Tue, Jul 28, 2009 at 10:32 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> > > William Herrin wrote:
> > >> 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.
> >
> > Hi Joel,
> >
> > I could almost see that argument on the ISP side but it doesn't make
> > sense to me on the end-user side, particularly when they may be
> > trivially multihomed. I surely wouldn't want to presume that I know
> > every registrant's address count needs better than he does though. f
> > you don't mind, let's just focus on the downside risk.
> >
> > So, the registrant asks for a /24 and a year later his replacement who
> > is a better network engineer figures out he really needs a /22 after
> > all. What's the impact? Other than insisting on giving him a /22 up
> > front, is there another way to mitigate that impact?
> >
> > Regards,
> > Bill Herrin
> >
> >
> > --
> > William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> > Falls Church, VA 22042-3004
> > _______________________________________________
> > 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: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/451875f8/attachment.bin>