[rpd] New Policy Proposal Received - "Multihoming not required for ASN (AFPUB-2019-ASN-DRAFT01)" (staff assessment on v1)

Tue Apr 9 10:17:01 UTC 2019

> On 31 Mar 2019, at 12:13, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net> wrote:
> 
> I think can be even a bit shorter.
> 
> I'm waiting for the impact analysis from AfriNIC, in case I need to take anything else in consideration, but a few days ago, I've already drafted a v2.

The staff assessment/analysis report for policy proposal “Multihoming not required for ASN” has been produced and published at:

https://afrinic.net/policy/2019-asn-d1#staff-assessment

PDF: https://afrinic.net/ast/pdf/policy/staff_assessment_multihoming_not_required_for_asn_afpub-2019-asn-001-d1.pdf

Plain Text Version follows:

Staff Assessment Report:
+++++++++++++++++++++++++++++++++++++++++++++++

Proposal : AFPUB-2019-ASN-001-draft-01 
Title : Multihoming not required for ASN 
Proposal URL : https://afrinic.net/policy/proposals/multihoming-not-required-for-asn#proposal
Assessed : 08 April 2019

1.0 Staff Understanding of the Proposal

a. The proposal aims to remove/ease the current requirement in CPM 7.4 that in order to qualify for an ASN, a requester be multi-homed or have a "unique routing policy", on the basis that the current ASN policy was passed when reliability of networks was not so good as today, and that back then, it made sense that an AS be multi-homed.

b. The proposal suggests that today, multi-homing is not necessarily a reasonable requirement, since in some cases, some networks may require an ASN but are not willing to be multi-homed (due to costs or remote locations that have only a single upstream) and whose SLAs may not specify redundancy. 

c. The criteria for an ASN request are proposed as follows: 
In order to qualify for an AS number, the requesting organization must be an AFRINIC member in good standing (End-User or LIR type) and fulfil one of the following requirements: 

7.4.1 Be a multi-homed site or

7.4.2 Have the need to interconnect with other AS.

An organization will also be eligible if it can demonstrate that it will meet any of the above criteria upon receiving an ASN (or within a reasonably short time thereafter). 

d. The proposal suggests that applicants will be required to provide justification consistent with RFC1930 (or its successors), and will be encouraged to use a private ASN if appropriate.

2.0 Staff Comments

a. Under 7.0, the change from "This section" to "This document" is not appropriate; "this document" would be interpreted to mean the entire CPM.

b. It is not clear how in proposed 7.2, RFC1930 will be applied. It reads "All requests for ASNs under these criteria will be evaluated using the guidelines described in RFC1930...”.  However, RFC1930 section 5.1 states that a single-homed site does not need its own ASN - while  the introduction to the policy proposal suggests that single-homed sites should qualify for an ASN. 

Staff Suggestion: Clarify whether some or all of the guidelines in RFC1930 will apply, and how to resolve conflicts where RFC1930 implies that no ASN is needed, or that a private ASN would be sufficient, but this proposal suggests that a public ASN could be assigned.

In each of the example ASN request scenarios/use cases below, using the provisions of RFC1930 would get the ASN requests denied (yet the same scenarios would meet policy compliance with proposed policy text 7.4.2 and be approved). The use cases consider an example where a requestor is an existing Extra Small LIR holding /22 of IPv4 space: 

* Case 1 - Requestor provides 1 BGP peer who confirms that there is a peering agreement.
* Case 2 - Requestor provides 1 BGP peer who confirms that a peering agreement is under negotiation.
* Case 3 - Requestor has one or more ASN and wants another ASN, provides 1 BGP peer who confirms that a peering agreement is under negotiation.
* Case 4 - Requestor has one or more ASN and wants another ASN, provides 1 BGP peer who confirms that there is a peering agreement

c. Under 7.2 the text, "In order to qualify for an AS number, the requesting organization must be an AFRINIC member" could be reworded to "In order to qualify for an AS number, the requesting organization must be an AFRINIC RESOURCE member". This aligns with the types of membership recognized by AFRINIC Ltd as a legal entity.

d. The community is informed that if this policy proposal is implemented, there could be an increase in the consumption rate of ASNs given the new looser requirements. However, we (and all other RIRs) have since transitioned to assigning ASNs from a general 32-bit ASN pool (which is about 4.3 billion ASNs large), therefore the anticipated increase of the ASN consumption rate is unlikely to be a problem or concern for the foreseeable future.

3.0 Comments from Legal Adviser 

None

4.0 Implementation

4.1 Timeline & Impact

The proposal will be implemented within the timelines provided for in the PDP.

4.2 Implementation Requirements

a. Updates to internal request evaluation processes and checklists.
b. Updates to the ASN request form on MyAFRINIC and the new member request portal.
c. Publishing updated documentation related to ASN Resource Requests on the AFRINIC website