Re: [sig-policy] Fwd: Re: [nznog] Prop 94
impression of giving out /22 allocations too generously by not requiring
renumbering.
My concern is actually the other way around, that keeping the current
renumbering criteria after the final /8 makes initial allocation
conditions more strict than today.
Today, if a new LIR has existing address holdings from its upstream IR,
APNIC can allocate more than a /22 to compensate for the loss of
renumbering.
This will no longer be the case after the final /8. For example, if a
new LIR's existing address holding is a /21, they must return this /21
in exchange for a /22 allocation from APNIC.
This doesn't make much sense when you request for an allocation to
receive an additional IPv4 space.
Do people have thoughts about this?
Regards,
Izumi
(2011/02/01 9:42), Seiichi Kawamura wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I think what Brian is trying to point out, is
> that you're basically nullifying "the existing criteria"
> because the "new alternative criteria" is much more relaxed.
> I agree with Brian here.
>
> There are many other reasons (or unreasonable reasons)
> that people deaggregate. IMHO, deaggregation caused by the implementation
> of this policy is most likely to be very small compared to those numbers.
>
> Regards,
> Seiichi
>
> (2011/01/31 21:35), Izumi Okutani wrote:
>> Andy, thank you very much for fowarding the discussions.
>>
>> About the aggregation concern, is the issue being that once an
>> organization becomes an LIR, they might start puching-holing existing
>> assignments from their upstream?
>>
>> I'm not sure if I understand the issue well, and would be interested to
>> hear more about it if anyone is able to share.
>>
>> For the 80% requirement, we simply made the % consistent with the
>> subsequent allocation criteria today. (I just realised it's not
>> explicitly stated in the policy document - may I confirm with APNIC
>> secretariat if this is still true?)
>>
>> I've made some slides on the issue we are trying to solve in this
>> proposal. Hope it clarifies the intention a little better.
>>
>>
>> thanks,
>> Izumi
>>
>> (2011/01/31 5:51), Andy Linton wrote:
>>> There's been some discussion of prop-094 on the nznog mailing list after
>>> last week's meeting in Wellington.
>>>
>>> Brian is a former chair of the IAB and IETF and Jamie is the VP of
>>> InternetNZ.
>>>
>>> I'm forwarding them here.
>>>
>>> andy
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Re: [nznog] Prop 94
>>> Date: Sat, 29 Jan 2011 17:15:56 +1300
>>> From: Brian E Carpenter<brian.e.carpenter at gmail dot com>
>>> Organization: University of Auckland
>>> To: jamie baddeley<jamie.baddeley at vpc dot co dot nz>
>>> CC: nznog at list.waikato dot ac dot nz<nznog at list.waikato dot ac dot nz>
>>>
>>> On 2011-01-29 15:49, jamie baddeley wrote:
>>>> Hi Brian,
>>>>
>>>> I don't think the proposal at this point is too bad. Happy to be
>>>> persuaded otherwise. If someone is prepared to make the leap into a
>>>> /22 then 20% of what's remaining in the existing upstream allocation
>>>> is not a massive amount of space. How many assignments happen from
>>>> upstream to downstream that is greater than a /22?
>>>
>>> Yes, certainly this isn't a disaster, but why set the level at 80% occupied?
>>> 90% would halve the amount of potentially wasted or hoarded space.
>>>
>>>> We're expecting everyone who takes the global routing table to be (or
>>>> have been) busy upgrading to v4/v6 dual stack and I presume as a
>>>> consequence they have nice shiny routers with lots of mem/cpu etc.
>>>> Therefore the number of prefixes in the GRT is much less a concern
>>>> these days right?
>>>
>>> Well, routers have kept up with growth because CIDR has been a great
>>> success over the last 15+ years, and this seems like a step back:
>>> 2 prefixes instead of one for every operator who uses this policy and
>>> has multihomed transit. There's a significant risk of IPv4 disaggregation
>>> for many reasons during the coming address space end game, so I think we
>>> need to be watchful.
>>>
>>> As an author of RFC 5887, I fully realise that asking operators
>>> to renumber is a hard ask. So the effect of this change will actually
>>> be to nullify the renumbering requirement completely - why would
>>> any operator take that pain voluntarily?
>>>
>>> Brian
>>>
>>>> jamie
>>>>
>>>>
>>>>
>>>>
>>>> On 28/01/2011, at 3:22 PM, Brian E Carpenter wrote:
>>>>
>>>>> The APNIC policy proposal 94 allows an operator to put in for new
>>>>> IPv4 space without having to renumber, if they can show that
>>>>> they've used 80% of the space already obtained from their
>>>>> upstream.
>>>>>
>>>>> http://www.apnic.net/policy/proposals/prop-094
>>>>>
>>>>> That seems bad in two ways
>>>>>
>>>>> 1. It allows 19.99% of IPv4 space to be hoarded.
>>>>>
>>>>> 2. It probably encourages disaggregation, compared with renumbering
>>>>> into this new block.
>>>>>
>>>>> Brian
>>>>>
>>>>> _______________________________________________ NZNOG mailing list
>>>>> NZNOG@list.waikato.ac.nz
>>>>> http://list.waikato.ac.nz/mailman/listinfo/nznog
>>>>
>>>>
>>> _______________________________________________
>>> NZNOG mailing list
>>> NZNOG@list.waikato.ac.nz
>>> http://list.waikato.ac.nz/mailman/listinfo/nznog
>>> * sig-policy: APNIC SIG on resource management policy *
>>> _______________________________________________
>>> sig-policy mailing list
>>> sig-policy at lists dot apnic dot net
>>> http://mailman.apnic.net/mailman/listinfo/sig-policy
>>
>>
>>
>> * sig-policy: APNIC SIG on resource management policy *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy at lists dot apnic dot net
>> http://mailman.apnic.net/mailman/listinfo/sig-policy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
>
> iEYEARECAAYFAk1HVwMACgkQcrhTYfxyMkLkwgCfToUaB4pDQUb+d3zNBnwovgdV
> rNgAn2XGYySeA02mGH7ukBf7i1fdE21N
> =IRN1
> -----END PGP SIGNATURE-----
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy