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

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

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Tue Apr 9 14:17:52 UTC 2019


So, my "Spanglish" is better than American ?

;-)

Saludos,
Jordi
 
 

El 9/4/19 16:09, "Mark Elkins" <mje at posix.co.za> escribió:

    You can't ask Owen that - he speaks American, not English :-D
    
    On 2019/04/09 15:50, JORDI PALET MARTINEZ via RPD wrote:
    > Hi Owen,
    >
    >
    > El 9/4/19 15:18, "Owen DeLong" <owen at delong.com> escribió:
    >
    >      Small suggested edit…
    >      
    >      7.4.2 should, IMHO, read as follows:
    >      	7.4.2 Interconnection with one or more other ASNs which requires a globally unique ASN.
    >      
    >      The reason for this change is as follows… A literal reading of the text as written has two defects.
    >      
    >      	1.	It could be interpreted to require interconnection to at least 2 peers.
    >      	2.	The term unique could be stretched to include situations where a unique (within an administrative
    >      		boundary) private ASN would be adequate or sufficient.
    >
    > I've no issue with this wording. Just one question, being too picky maybe, being a non-native English speaker:
    >
    > 7.4.2 Interconnection with one or more other ASNs which requires a globally unique ASN
    >
    > or
    >
    > 7.4.2 Interconnection with one or more ASNs which require a globally unique ASN
    
    The second variation without "other" sounds better to me. You need an 
    ASN "to interconnect with" either "other ASN's" or "one or more ASN's"
    
    
    >   
    >      Regards,
    >      
    >      Owen
    >      
    >      
    >      > On Apr 9, 2019, at 4:00 AM, JORDI PALET MARTINEZ via RPD <rpd at afrinic.net> wrote:
    >      >
    >      > Hi Ernest, all,
    >      >
    >      > According to this and the last email exchange in the list, this is the text that I believe will be acceptable for everyone:
    >      >
    >      > ******
    >      >
    >      > 7.0  ASN
    >      > This section contains the policies relating to the distribution, management, and use of Autonomous System (AS) numbers in the AFRINIC service region.
    >      >
    >      > 7.1  Definitions
    >      >
    >      > [Retain under here all text from the current CPM 7.3]
    >      >
    >      > 7.2 Eligibility for an AS Number assignment
    >      >
    >      > It is important to determine which sites require unique AS Numbers.  Sites which do not require a unique AS Number should use one or more of the AS Numbers reserved for private use. Those numbers are: 64,512 - 65,535 and 4,200,000,000 - 4,294,967,294 (RFC1930, RFC6996 and possible future updates).
    >      >
    >      > In order to qualify for an AS number, the requesting organization must be an AFRINIC resource member and fulfill one of the following requirements:
    >      >
    >      > 7.4.1 A unique routing policy or
    >      > 7.4.2 Interconnection with other ASNs requiring a unique ASN.
    >      >
    >      > 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 the following six months).
    >      >
    >      > *****
    >      >
    >      > If this is the case, unless there are further comments in the next few days, I will officially submit a new version.
    >      >
    >      > Regards,
    >      > Jordi
    >      >
    >      >
    >      >
    >      > El 9/4/19 12:17, "Ernest Byaruhanga" <ernest at afrinic.net> escribió:
    >      >
    >      >
    >      >
    >      >> 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
    >      >
    >      >
    >      >
    >      > **********************************************
    >      > IPv4 is over
    >      > Are you ready for the new Internet ?
    >      > http://www.theipv6company.com
    >      > The IPv6 Company
    >      >
    >      > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    >      >
    >      >
    >      >
    >      >
    >      > _______________________________________________
    >      > RPD mailing list
    >      > RPD at afrinic.net
    >      > https://lists.afrinic.net/mailman/listinfo/rpd
    >      
    >      
    >
    >
    >
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.theipv6company.com
    > The IPv6 Company
    >
    > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    >
    >
    >
    >
    > _______________________________________________
    > RPD mailing list
    > RPD at afrinic.net
    > https://lists.afrinic.net/mailman/listinfo/rpd
    
    -- 
    Mark James ELKINS  -  Posix Systems - (South) Africa
    mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
    For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
    
    
    _______________________________________________
    RPD mailing list
    RPD at afrinic.net
    https://lists.afrinic.net/mailman/listinfo/rpd
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.






More information about the RPD mailing list