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
Attachment:
prop094.pdf
Description: Adobe PDF document