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

[AFRINIC-rpd] Fwd: new proposal: "Remove requirement to announce entire v6 block as single aggregate"

Sunday Folayan sfolayan at gmail.com
Wed May 15 10:00:38 UTC 2013 

On 15/05/2013 10:34, Andrew Alston wrote:
> Hi Sunday,
>
> While I agree the proposal is unnecessary since the current policy doesn't actually prohibit the announcement of smaller blocks, I must also point out that the announcement of an aggregate does not necessarily guarantee reachability of all the smaller prefix's either (because while that SHOULD be the case, if a network is running with a series of islands that aren't connected to each other, this won't work, and in Africa with a network announcing from 15 countries, I'd actually be surprised if they were all linked together, sadly).

We are talking of a multinational here, amigo ... why insult their 
ability to multihome each location?? I bet they are all linked with mpls 
and an extra layer of vpn to boot.


>
> My understanding of this policy is attempting to fix more an economic/admin issue than a technical one though, and reading through what was said below, I can understand the economic and administrative issues that would drive such a change, and I'm inclined to agree there is a problem here, I am just far from convinced that this particular change is the right way to address it.

We are looking at and testing the strength of our policy here, not the 
intention, or capabilities of the drafters.

>
> So, I have a couple of questions for the policy drafter.
>
> a.) These 15 countries, are each of these companies autonomous entities, or are they a single entity
> b.) Is each country announcing from the same ASN, or are there multiple ASN's involved here
> c.) Does this space qualify as PI space, or is it being onward assigned, and as such would have to be LIR space?

Fair questions.


>
> Dependent on the answers to the above, it would be possible if it is PI space, to apply for a single block of space out of the PI blocks (a /44 would give you 16 /48s), and since this would come out of the PI allocation block, it wouldn't be filtered when you announced /48s.  Of course this would not apply if this space was LIR space.
>
> I might point out that there is plenty of precedent for being granted PI blocks in the way mentioned above, where I can cite several examples of institutions that have multiple physical locations and have been granted enough space for a /48 per physical location/campus.

I was wondering why they must be LIR ... but I held it, considering the 
huge traffic on that issue, in the past ;)


>
> This would effectively solve the problem for the drafter, though in the LIR world, it's still a more complex issue that I think needs more thought.
>
> Andrew

Sunday.



>
>
> -----Original Message-----
> From: Sunday Folayan [mailto:sfolayan at gmail.com]
> Sent: Wednesday, May 15, 2013 11:25 AM
> To: Andrew Alston
> Cc: 'Ernest'; 'AfriNIC Resource Policy Discussion List'
> Subject: Re: [AFRINIC-rpd] Fwd: new proposal: "Remove requirement to announce entire v6 block as single aggregate"
>
> <BEGIN PROPOSAL>
> [3] Proposal
> ----------------
> We propose to delete the following sentence in section 6.1.1 (d) from the IPv6 policy “The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months.”
> <END PROPOSAL>
>
>
> The existing policy only compels the LIR to announce a single aggregated block, but does not forbid the announcement of assignments made out of the entire block. Deleting that provision will mean that resources can be obtained, and not advertised at all. not good. Is the resource owner forbidden from advertising subsets of the allocation?
>
> For as much as the entire block is advertised, the network will be reachable, even if smaller advertisements are filtered.
>
> In my opinion, the proposal itself is unnecessary, at least what is being requested to be deleted in the original policy. Lets keep that requirement, but not forbid the advertisement of smaller prefixes.
>
> SF.
>
> On 15/05/2013 07:39, Andrew Alston wrote:
>> Hi RPD List,
>>
>> While I see the logic behind this proposal, I have to oppose it based on technical grounds.
>>
>> If said multi-national applies for a large enough block to cover each
>> country and is allocated space equivalent to a single /32 per country (so in this case, a /28, or 16 /32s), then this proposal would work since the multi-national could announce /32s from each location.  However, allowing for announcements of /48s out of the LIR blocks would not work because of filtering.  There are many that still only accept /32s, other than when the /48 is assigned out of a known PI block.
>>
>> To allow this would only result in partial reachability for the block and I'm not sure that's a good idea at all.
>>
>> At the same time, huge allocations of /28s or whatever may not be practical though I think that’s another debate entirely.
>>
>> I do acknowledge the problem the proposer has, and I do believe the economic problem stated needs to be rectified, I just don't agree with the proposed solution.
>>
>> Andrew
>>
>>
>> -----Original Message-----
>> From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On
>> Behalf Of Ernest
>> Sent: Wednesday, May 15, 2013 8:25 AM
>> To: AfriNIC Resource Policy Discussion List
>> Subject: [AFRINIC-rpd] Fwd: new proposal: "Remove requirement to announce entire v6 block as single aggregate"
>>
>> Colleagues,
>>
>> The policy proposal below has just been submitted as detailed. We encourage the community to study and provide appropriate feedback on the proposal.
>>
>> Regards,
>> Ernest.
>>
>>
>> __________________________________________________________________
>>
>> Identifier:	    AFPUB-2013-V6-001-DRAFT01
>>
>> Draft Policy Name:   Remove requirement to announce entire v6 block as
>> single aggregate
>>
>> Author(s)
>>    :
>>       Steven Wiesman,
>>       steven.j.wiesman at accenture.com,
>>       Accenture
>>
>>
>>      Steven Tapper,
>>      steven.tapper at accenture.com,
>>      Accenture
>> 	
>>      Charles Hendrickson,
>>      Charles.hendrickson at accenture.com,
>>      Accenture
>> 	
>>
>> Submission Date:   2013-05-16
>>
>>
>>
>> [1]  Summary of the Problem Being Addressed by this Policy Proposal
>>
>> ----------------------------------------------------------------------
>> ----------------------
>>
>> The current AFRINIC allocation policy provides for and assigns IPv6 space to companies residing within the region’s countries.  This assignment policy aligns with the IPv6 hierarchy but does not allow for multinational companies’ efficient distribution of IPv6 address space. Under the existing policy, a multinational company has to apply for membership and IPv6 resources from every location in which it operates.  This is both costly and time consuming to the Registry and the Multinational Company applying for membership.
>> The RIR has to maintain and organize multiple prefixes assigned to one company and provide services appropriate to the membership process.  The company applying for membership has to perform the same function of managing multiple IPv6 assigned ranges and technically operate and manage the disparate IPv6 ranges assigned to the locations.
>>
>> For example under the existing policy,
>> •	Multinational company A operates in 15 countries within the
>> AFRINIC region.
>> •	The Multinational Company needs to apply for membership from each
>> of the 15 locations.
>> •	The Multinational Company needs to apply for IPv6 resources from
>> each of the 15 locations.
>> •	The Multinational Company has 15 potentially different prefixes to
>> manage and operate.
>> •	The Multinational Company has 15 potentially different prefix
>> lengths to manage and operate.
>> •	The multinational company needs to pay yearly the renewal fees to
>> lease the IPv6 address space awarded for each location.
>> •	AFRINIC needs to review and award location based appropriate
>> prefixes to each of the 15 locations.
>> •	AFRINIC needs to assign IPv6 resources to 15 separate locations
>> which may come from separate areas of the RIR managed IPv6 ranges.
>> •	AFRINIC needs to process the paperwork for 1 company 15 times for
>> membership.
>> •	AFRINIC needs to process billing on a yearly basis for 1
>> multinational company 15 different times.
>> •	IPv6 address assignments are location based and must only be
>> advertised as an aggregated prefix to the Internet in which the prefix was awarded.  Additional subnetting and advertisement of the awarded IPv6 address range is not permitted.  For example:
>> -	One /32 aggregated from one location
>> -	Smaller subnets, ie /48 from the same prefix, cannot be advertised
>> out of another location
>>
>>
>> [2] Summary of How this Proposal Addresses the Problem
>>
>> ----------------------------------------------------------------------
>> ------- This proposal allows for the Multinational Company to apply
>> for and obtain a larger aggregated IPv6 block of addresses and allows the company to allocate, assign and advertise the IPv6 address range awarded according to its own internal IPv6 hierarchical policies.
>> Additionally, AFRINIC will now only need to review and maintain membership records for one instance of the multinational company, and by prefix, immediately identifies the company.
>>
>> For example under the proposed policy,
>> •	Multinational Company A operates in 15 countries within the
>> AFRINIC region.
>> •	The Multinational Company needs to apply for membership one time.
>> •	The Multinational Company needs to apply for IPv6 resources one
>> time providing sufficient evidence of hierarchical design.
>> •	The Multinational Company is awarded a prefix sufficent to cover
>> the 15 offices and future growth and or expansion within the region.
>> •	The Multinational Company has one prefix to manage, operate and
>> break down according to its internal policy.
>> •	The multinational company needs to pay yearly the renewal fees to
>> lease the IPv6 address space awarded one time.
>> •	AFRINIC needs to process the paperwork for 1 company.
>> •	AFRINIC needs to review and award a prefix to the multinational
>> company one time.
>> •	AFRINIC needs to process billing on a yearly basis for 1
>> multinational company one time.
>> •	The IPv6 address assignment is company identifiable.
>> •	Policy allows for multiple aggregated prefixes to the Internet.
>> •	Additional subnetting and advertisement of the aggregated IPv6
>> address range is permitted.  For example:
>> -	One /32 aggregated from one location
>> -	Smaller subnets, ie /48 from the same prefix, advertised out of
>> another location.
>>
>>
>> [3] Proposal
>> ----------------
>> We propose to delete the following sentence in section 6.1.1 (d) from the IPv6 policy “The LIR should also plan to announce the allocation as a single aggregated block in the inter-domain routing system within twelve months.”
>>
>>
>> [4] Revision History
>>
>> None
>>
>> [5] References
>>
>> IPv6 Allocation Policy
>> https://my.AFRINIC.net/help/policies/afpol-v6200407-000.htm
>>
>> __________________________________________________________________
>>
>>
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>>
>> _______________________________________________
>> rpd mailing list
>> rpd at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
>>
>
> --
> --------------------------------------------------------
> Sunday Adekunle Folayan
>       blog: http://www.sundayfolayan.name.ng
>      email: sfolayan at skannet.com.ng, sfolayan at gmail.com
>      phone: +234-802-291-2202
>      skype: sfolayan
>       fcbk: www.facebook.com/sfolayan
>      tweet: sfolayan
> linkedin: sfolayan
> ---------------------------------------------------------
>
>
>


-- 
--------------------------------------------------------
Sunday Adekunle Folayan
     blog: http://www.sundayfolayan.name.ng
    email: sfolayan at skannet.com.ng, sfolayan at gmail.com
    phone: +234-802-291-2202
    skype: sfolayan
     fcbk: www.facebook.com/sfolayan
    tweet: sfolayan
linkedin: sfolayan
---------------------------------------------------------

More information about the RPD mailing list