[ppml] 2005-1 or its logical successor

[Tony Hain]

Steve Feldman wrote:
> On Oct 27, 2005, at 11:04 PM, Lea Roberts wrote:
> 
> >
> > for the record, the straw poll was 24 vs 25.
> 
> ... And for what it's worth, my vote for the policy was mostly because
> it was better than no policy at all, and hoping it could be cleaned
> up on the way to adoption.  I was also in favor of the original 2005-1.

My vote against it was that this particular proposal was so bad that it
would be *worse* than no policy at all. There is a need creating pressure so
a reasonable policy will be created. If that version passed there would be a
'let it have a chance' attitude that would stall any reasonable text for
years.

> 
> >
> > For the record, here are some excerpts from what I wrote to Kevin Loch
> > inviting him to work on the combined 2005-1 that you are so unhappy
> > about.
> > I hope this will help others (and maybe even you) to understand how
> > the
> > extra stuff got piled on.  I honestly believe that for 2005-1 to
> > achieve
> > consensus it has to focus on the large organizations for whom
> > renumbering
> > is a problem while having criteria which would limit the number of
> > qualifying organizations to the range of 5K to 10K.  When I wrote
> > the text
> > below, the feedback from other AC members is that it matched their
> > recollection from ARIN XV.
> 
> I think it's a mistake to focus on renumbering as the main issue; it
> really comes
> down to multihoming.  Whether I multihome using PA or PI addresses,
> my prefix
> is necessarily going to take up a slot in the global routing table.
> So if
> multihoming is to be allowed at all, routing tables will have to grow.

Renumbering, multi-homing, size, and use are all inadequate qualifications
that will do nothing more than drag the debate on forever. You are correct
that a dedicated PI block, or a whole punched in a PA will consume a routing
slot. The issue that needs consideration is why that slot has to be global?
Tradition says it will be, but is that really a requirement? Aggregation is
about compartmentalizing the knowledge, so the fear here is that we don't
know how else to do it. There have been proposals, including the ITU
thoughts about country based prefixes, which are ignored because they don't
allow the absolute freedom to do random things. PA is no better than country
based schemes, unless you are a provider and want to maintain sovereignty
over your decisions. 

> 
> Given that, it doesn't make much sense to force the multihomers into
> PA space
> (unless the objective is to provide a disincentive to switch providers.)
> 
> So the fundamental questions should be:
>   1) should IPv6 end sites be permitted to multhome?

Yes, because they will despite allocation policy.

>   2) if so, should there be more stringent restrictions than on IPv4
> multihoming?

No.

>   3) if so, what sorts of entities should qualify, and how can the
> restrictions be
>      crafted to achieve that goal?

It should not be ARIN's job (or any RIR for that matter) to be a judge here.
As long as we have a model that says an independent slot has a global
impact, the appropriate response is to create a set of membership thresholds
each with a specific prefix length. There is no reason to even ask why they
might want, or what they will do with that space, just set a price and let
economics drive the allocations. It then becomes a routing question of what
prefix length will get through, and that is explicitly outside ARIN's
domain. 

Tony