[ppml] a modified proposal 2005-8

[Jason Schiller (schiller@uu.net)]

Some how this didn't get posted.

___Jason
---------- Forwarded message ----------
Date: Mon, 13 Mar 2006 11:58:49 -0500 (EST)
From: "Jason Schiller (schiller at uu.net)" <schiller at uu.net>
To: Lea Roberts <lea.roberts at stanford.edu>
Cc: Randy Bush <randy at psg.com>, ppml at arin.net
Subject: Re: [ppml] a modified proposal 2005-8

First let me say I think the policy is a good one.

I agree with the general concept that we should consider moving away from
"classful" and towards CIDR, and agree that the end site assignemnt should
generally be between /64 and /48 and should not be "fixed values".

The guidelines (and I understand they are just a guidelines) clearly
defines the upper and lower bounds, but then offers a fixed value of a /56
for small sites, or /60 as some suggest.

I guess I would like to see guidelines for how an ISP or LIR would
determine best fit for an end site assignment that does not center around
a fixed number such as /56 or /60 for small sites.

I understand there is a trade off between aggregation and efficent use,
and I understand aggregation is currently more important, but I'm not sure
how much more important aggregation is over efficent use.

Should an ISP plan for as many subnets as the end site could ever imagine
using and then round up to the nearest CIDR?  Should we plan for twice as
many as thay can imaging using in the next 10 years and then round up?  OR
manybe the exact number of subnets today then rounded up to the nearest
CIDR and then doubled?


___Jason



==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       schiller at uu.net
UUNET / Verizon                         jason.schiller at verizonbusiness.com

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

On Sat, 11 Mar 2006, Lea Roberts wrote:

> Date: Sat, 11 Mar 2006 16:44:36 -0800 (PST)
> From: Lea Roberts <lea.roberts at stanford.edu>
> To: Randy Bush <randy at psg.com>
> Cc: ppml at arin.net
> Subject: Re: [ppml] a modified proposal 2005-8
> 
> hi Randy -
> 
> On Sat, 11 Mar 2006, Randy Bush wrote:
> 
> > >    The following guidelines may be useful (but they are only guidelines):
>                                                    ^^^^^^^^^^^^^^^^^^^^^^^^
> 
> > >    - /56 for small sites, those expected to need only a few subnets
> > >      over the next 5 years.
> >
> > 256 is a few?  if you have to nibble away at it, isn't a /60 more
> > like a few
> 
> I don't disagree...  we just put out some talking numbers and thank you
> for your suggestion(s).  I think one thing I would like to know is what
> people think about providing generous assignments with the justification
> being to make sure to provide flexibility to adapt to new architectures
> that we have yet to imagine.  That's been the argument for /48 everywhere
> and I don't want to fall into the tighten it too much trap.  I believe it
> is *really* important to try to make sure that everyone who needs lots of
> subnets can get them easily.  This needs to be balanced against careless
> waste of the address space.
> 
> that said, do others think we should add the /60 "for a few" to the
> guidelines?
> 
> > >    - /48 for larger sites
> >
> > i still do not understand why/how you are picking these points on
> > the knob.  what we really mean is allocate what is justifiable for
> > the next few ( !=256 :-) years.
> 
> Our goal is to provide some numbers for people with less clue than you.
> Are you suggesting that we should assume a sufficient clue level for all
> ISP/LIRs?
> 
> > >    For end sites to whom DNS will be delegated, the LIR/ISP
> >                           ^ reverse
> 
> thanks for this editorial suggestion.  I will ask Einar to include it if
> he can...				thanks again,		/Lea
> 
> 
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>