[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)

Hi Gert,

On 9/30/13 7:31 PM, Gert Doering wrote:
> Hi,
>
> (no hats)
>
> On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote:
>> Q: How would that work?
>> A: We could end up with two levels of RIPE NCC membership, e.g. "full"
>> like we have today, and "associate". Both would be fully-blown LIRs, but
>> to keep the operational overhead in NCC billing/finance low, the
>> membership fee for these "associate" members would be charged by the NCC
>> to the full members who are sponsoring them (just like with PI).
>
> I'm not exactly sure what the difference between an "associate member"
> and today's "consumer of resources provided by a sponsoring LIR" would
> then be, except for the title on the contract.   On the contrary, some
> enterprises just don't want to deal with the RIPE NCC if they can make
> a contract with their friendly neighbouring LIR instead...

exactly, I think that there's no difference between 'associate member' 
and customer of 'Sponsoring LIR' (whether we call it Sub-LIR, Portable 
Internet Registry or get enough support to keep calling it End User)

>
> So I'm not sure it's worth abandoning the established concept of sponsoring
> LIR right away (especially since doing away with it would affect IPv4 PI
> as well...).  It wouldn't make a difference anyway :-) - if we want to
> give people the option to take a /48 because it's big enough for them,
> we'd then still have "two standard sizes"...

The Sponsoring LIR concept has been a battle won after quite a few 
years(remember 2007-01?) . I really do not want to throw it away as I 
believe it's a very valuable concept and it has taken two years of 
intense discussions in the community.

>
> So, yes, another avenue could be "abandon /48 assignments/allocations",
> but *that* brings up another can of worms (what about an enterprise that
> has 5 locations that all have local ISP upstreams and want to do BGP
> multihoming?  5x /48 suits them well today, 1x /32 with someone blocking
> more-specifics from that because no site is announcing the /32 aggregate
> would not be that good).

I wouldn't worry about this can of worms, see section 5.2.1

"A /32 (or larger when documented) additional allocation may be provided 
when different routing requirements are demonstrated."

We could change this to

"An additional allocation may be provided when different routing 
requirements are demonstrated."

and leave it to the decision of the enterprise to request either a /48 
or a /32 or larger.

>
> I'm repeating the "no hats" bit, just contributing to the discussion as
> someone who has fought IPv6 policy for a while now :-) - and this is
> discussion phase, so take this all as "brain dump", not as "advice from
> the chair".
>

thanks ;)

> gert
>

cheers,
elvis