Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Proposal Update (was: Re: New Proposal - "Soft Landing - BIS (AFPUB-2016-V4-001-DRAFT-02)"

ALAIN AINA aalain at trstech.net
Mon Feb 29 22:31:17 UTC 2016


Hello,


> On Feb 28, 2016, at 12:40 PM, Nishal Goburdhan <nishal at controlfreak.co.za> wrote:
> 
> On 23 Feb 2016, at 15:09, ALAIN AINA wrote:
> 
>> Hello All,
> 
> hi,
> 
>> Thank you all for your interest in our policy proposal.  Some of the impressions being created about what it sets out to achieve are incorrect.  The IPv4 softlanding-bis policy proposal does not intend to extend IPv4 lifetime at AFRINIC.
> 
> s/lifetime/availability.
> 
> (and that’s not necessarily bad, btw!)

Yes, “Availability”  in the context defined by the global policy http://www.afrinic.net/en/library/policies/135-afpub-2009-v4-001 

> 
> 
>> The policy proposal stays in the spirit of the global Global Policy for the Allocation of the remaining IPv4 address pool: http://www.afrinic.net/en/library/policies/135-afpub-2009-v4-001 (section 2 and 3) and the current IPv4 soft landing policy http://www.afrinic.net/en/library/policies/697-ipv4-soft-landing-policy (section 3).
>> 
>> The proposal makes sure the distribution of the final /8 [102/8] is fair enough based on the current consumption rate, assures availability of IPv4 to new comers, to Critical Internet Infrastructure as well as to the current players as we go through the transition to IPv6.
>> 
>> To achieve this, it says :
>> - during  phase 1,  move the maximum from /10 to /15.
>> 
>> http://afrinic.net/en/services/rs/membership-fees shows the member categories and /15 is the median which covers majority of AFRINIC membership as shown at  http://www.afrinic.net/en/services/statistics/membership  [members by Category]
> 
> there was a lot of discussion around this at the time of the original policy.  many large ISPs felt that a /15 would severely impact them, and (please correct me douglas) that’s why during phase1, this was a large number (/10).

Nope.

During phase 1, the maximum is  /13.

Our FAQ presents the different situations….  see http://www.afrinic.net/en/community/policy-development/policy-proposals/1627-softlanding-bis-policy-faq-v2

> 
> a median is fine, but, it’s still a median.  how do you propose afrinic deal with a large LIR request (specifically during phase1)


With the max  of /15, you asked  “how do you propose AFRINIC deal with “large" LIR request.”

One could ask : With the max set to  /13,  “how do you propose AFRINIC deal with  "very large" or "extra large”  LIR request.” :-)

AFRINIC will as usual  follow existing policies. Members are  encouraged to check eligibility before sending requests.

NB: In the current  soft landing policy and in the proposal, there is no explicit limit of number of requests from a member( though some have challenged  this…) So one could get multiple  /15 (following additional allocation criteria) to /14 and above (large allocation)

> 
> 
>> - during phase 2, reserve a block for new comers and for Critical Internet Infrastructures(new and current).  Make sure CIRs get IPv4 they need for their operations during the exhaustion and the transition.
>> 
>> CIRs have been expanded to include TLDs during exhaustion phase 2. gTLDs are coming and ccTLDs being developed..
>> 
>> Definition of CIR in other regions is available at :https://www.nro.net/rir-comparative-policy-overview/rir-comparative-policy-overview-2015-04#2-4-2
> 
> to be clear - because you did not state it - are you suggesting that we accept this definition for _this_ region as well?  and which definition?  


The policy proposal defines what Critical Internet Infrastructure means in phase 2


> it’s good to have reference, but, as has been pointed out before, what works elsewhere is *NOT* the same as what should needlessly be done here.

I agree and especially regarding  this /last 8,  each region “must” adopt its management rules to match the best its needs  towards the exhaustion of the v4 and the transition to v6….

yes, references are good and from the  referred link, it is interesting to see that definition of CIR is not the same everywhere...


> i, for one, would not support .MYSEXYNEWTLD as a critical resource, vs, say an african ccTLD.  

Shall we look at the string? Any operator of a gTLD in this region,  which went through the gTLD process and got delegated should qualify...


> others might feel otherwise.

thus the discussion, we are have having here


> 
> since there are unlikely to be more RIRs created, and we *should* be able to assume that the IANA can take care of itself ;-)  what amounts to a CIR please?

The  total reserve for the CIR is  /16

> 
> 
>> Our initial thinking was that IXPs may benefit from the CIRs block during the phase 2 as the current reserve may not last and cover their needs at that time. We have no objection about  removing IXPs from CIRs.
> 
> you’re 100% correct in that the current reserve (when the hostmasters get around to implementing it) might not last.  we thumbsucked a number that we thought that the community would be willing to support, which worked to roughly 2x new IXPs per economy (well, less actually).  more space would be nice.

ok.


> i don’t recall reading anyone asking for an exclusion;  i asked specifically how you saw the IXP’s *need* for non-network announcement, and *want* for allocations from a contiguous block, to easily identify accidental route leakage, to be addressed within this policy.  that remains unanswered.

this need was not taken into account in this proposal and we will be have to see text proposal to address this. 


> 
> 
>> IPv6 deployment is slow. AFRNIC has the lowest rate of members with v4/v6[1]. During exhaustion, one must have IPv6 (from AFRINIC or upstreams ) when requesting IPv4.
> 
> i am still opposed to this part.  as it seems are others.  i am happy with the request-v4-once idea once you hit exhaustion phase X.  but i’m not happy about forcing an ipv6 allocation down someone’s throat;


> that hardly sounds bottom-up to me…

bottom-up does not mean, you necessary consent to .

the idea is that the 102/8  is used to  encourage and facilitate transition. So if one qualify for allocation from it, he “must’ need v6. Otherwise may be queue for allocation from a "non-102" pool. shall we open one ? 


> 
> 
>> Deployment may not be enforceable but it puts IPv6 transition forward as the clear agenda at this time.
> 
> ok, so then to save time, why doesn’t afrinic simply allocate the minimum the appropriate minimum IPv6 allocation to existing LIRs and EUs *now*;   ie. *every* resource member in good standing, that doesn’t already have an IPv6 allocation, automatically gets the minimum allocation per IPv6 allocation policy … think of how many more cute infographics can be made showing IPv6 rollout^Wallocations^Wgrowth^W^W in africa !!!    :-)
> 
> incidentally, quoting from your earlier paragraph:
> “The policy proposal stays in the spirit of … soft landing (section 3)“
> 
> and then reading those references:
> 135-afpub-2009-v4-001:
> “This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs”
> 
> and:
> 697-ipv4-soft-landing-policy section 3:
> “This policy (IPv4 Soft Landing), applies to the management of address space that will be available to AfriNIC after the current IPv4 pool is depleted.”
> … in fact, the words IPv6 do not appear in soft landing, section 3, *at all*.
> 
> so, i’d strongly suggest to the authors to decouple “IPv4 management under soft landing” (which i think is important) from, “enforced ipv6 allocations”

Ack, but it is hard to explain that we reserve some v4  space for  "new comers", CIRs, etc... in this  102/8, and they do not need v6.

hope this helps

—Alain


> 
> best,
> —n.
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd




More information about the RPD mailing list