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

Fri Apr 5 17:55:35 UTC 2019

Actually, a unique routing policy has a specific and definite meaning in internet parlance. It means a collection of routes which share a set of BGP attributes which are in some way distinct from the attributes of any other existing collection of routes. 

Participation in an IX, for example, constitutes a unique routing policy. Peering with one or more other ASNs constitutes a unique routing policy. 

In other words, this term precisely describes and covers literally all of the legitimate use cases for an ASN. Multihoming is a subset of unique routing policy, but being the most common, provides a touchpoint in language that is easier for the vast majority of applicants to understand. 

Owen

> On Apr 5, 2019, at 02:49, Jaco Kroon <jaco at uls.co.za> wrote:
> 
> Hi Jordi,
> 
> This is a definite step in the right direction.  I just think "A unique routing policy" is very vague.
> 
> And in theory, nobody would genuinly require an ASN under 7.4.2 since we could (very impractical) route the world statically, but since we all know the intent is that we want to route dynamically ... and the "require" could be a commercial or even policy requirement from the remote party (dynamic routing).
> 
> My opinion is that all resource members should get an ASN.  If you want more than one, that should be motivated.
> 
> The only exception to that might be resource members that only have a single (/24 ?) prefix from Afrinic, and is not multihoming.  Or single IPv4 (/24) and a single IPv6 (/48?).  Even this should not be prohibitive, as long as they can show they'll actually use it.
> 
> And with "show they'll use it" I mean provide the AS of the intended BGP peer.  It makes sense for these parties to get ASNs since it'll enable them to participate in an INX and to multihome, or even just transitioning from one provider to another becomes easier.  Where it doesn't make sense is if these parties don't have the technical ability (and I'm not referring to qualifiations because I don't have that either, other than somewhat qualified by experience).
> 
> Kind Regards,
> Jaco
> 
>> On 2019/03/31 11:13, JORDI PALET MARTINEZ via RPD 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.
>> 
>> This is what I've now (including a shorter version from Owen suggestion):
>> 
>> 
>> 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 a reasonably short time thereafter).
>> 
>> All requests for ASNs under these criteria will be evaluated using the guidelines described in RFC1930 "Guidelines for the creation, selection and registration of an Autonomous System (AS)”.
>> 
>> Regards,
>> Jordi
>>    
>> El 31/3/19 8:48, "Frank Habicht" <geier at geier.ne.tz> escribió:
>> 
>>     Hi,
>>          On 30/03/2019 01:11, Owen DeLong wrote:
>>     > Since we’re no longer limited to 16 bit ASNs, personally, I think that the requirement beyond the annual fees to maintaining an ASN is an anachronism and we should simply state that ASNs are available to anyone who meets one of the two following requirements:
>>     >
>>     >    1.    A unique routing policy
>>     > or    2.    Interconnection with other ASNs involving an exterior gateway protocol which requires a unique ASN.
>>     >
>>     > I believe that covers pretty much every circumstance in which an ASN would be useful and gives tremendous leeway in obtaining ASNs where needed.
>>          I agree, this is the right direction to take; more permissive.
>>          Regards,
>>     Frank
>>               > Is there any reason we can’t make the policy that simple?
>>          Can't see any.
>>          > Owen
>>               _______________________________________________
>>     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
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd