[arin-ppml] Rationale for /22
dlw+arin at tellme.com
Tue Jul 28 11:52:41 EDT 2009
You suggest that this proposal (or anything like 2007-6) will "break
things". By "things", I assume you mean the ongoing growth of the
routing table. Two things:
While I think mast of us are concerned about routing table growth, it's
a problem that is unrelated to good stewardship of the address space. That's
why routability of any given block is explicitly note to not be guaranteed
by the NRPM.
Also, please tell me how this contributes to routing table growth. If
you are a multihomed org, you are already consuming a routing slot (and
probably a /24). It's just not yours, and you are stuck with some
provider's space, and have to renumber when you change primary
providers. (Your other providers also have to change their configs to
route your ne space, and there's probably a transition when the org is
consuming two routing slots in the DFZ instead of one.)
I'm sorry, but I don't buy this argument. It's just a different block
in the DFZ, but it won't add to overall consumption. It's also
interesting to me that the other RIRs allow /24
allocations/assignments, and we haven't seen any added routing table
growth (beyond the normal explosive growth) as a result of that.
On Tue, Jul 28, 2009 at 10:19:05AM -0500, 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.
> 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:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML