[rpd] new version of "Multihoming not required for ASN" (AFPUB-2019-ASN-DRAFT04)

[Owen DeLong]

> On Nov 25, 2019, at 07:35 , Fernando Frediani <fhfrediani at gmail.com> wrote:

> 

> Hello Jordi

> 

> The change you made on 7.2.2 from "Single interconnection, with a provider that requires a public" to "Show a unique routing policy or demonstrate a technical need for a coordinated globally unique" means different things in my view and may make things slightly more difficult for organizations to receive an ASN.

> 

> 

Fernando,

A “single interconnection with a provider that requires a public ASN” is an example of a unique routing policy.
It is also an example of a technical need for a coordinated globally unique ASN.

However, you are correct in that the two things cited above are each supersets of the example you cite from the previous version of the policy.

As such, the new wording should make things easier, not more difficult.

> When it says "show a unique routing policy" doesn't necessarily mean two Transit providers  (it could be an IX, a private peering to another ASN, etc), but excludes the possibility to have an ASN with a single Transit Upstream. On the second part that says "demonstrate a technical need for a coordinated globally unique ASN" what kind of technical need could for example be acceptable to justify to have an ASN with a single Transit Upstream provider (have their own assigned IP space ?) ?

> My concern is not to exclude de possibility for organizations to have an ASN even if they have a single interconnection with their Transit Upstream.

> 

A unique routing policy is any situation in which a stub or transit autonomous system has a difference in interconnection from all other autonomous systems. As such, an IX, a private peering session, a cloud service provider which requires a globally unique ASN for BYO addressing, etc. would all qualify.

If you have a single upstream who requires that you have a globally unique ASN in order to use BYO addresses, then that is an example of a technical need.
In essence, any situation where you cannot accomplish your interconnection goals without a globally unique ASN is a technical need.

FWIW, the language in the current version of the policy is very similar to that which has been in use in the ARIN region for many years without any difficulty for organizations obtaining ASNs on any need.

Owen


> Could you clarify this please ?

> 

> Thanks

> Fernando Frediani

> 

> On 25/11/2019 08:45, JORDI PALET MARTINEZ via RPD wrote:

>> Hi all,

>> 

>> Find attached a new version of the proposal "Multihoming not required for ASN", following the latest inputs in the list.

>> 

>> I've also prepared an online diff of the changes to the proposed policy text, so it is easy to track:

>> 

>> https://www.diffchecker.com/omm6xj7m <https://www.diffchecker.com/omm6xj7m>

>> 

>> 

>> Regards,

>> Jordi

>> @jordipalet

>>  

>>  

>> 

>> 

>> 

>> **********************************************

>> IPv4 is over

>> Are you ready for the new Internet ?

>> http://www.theipv6company.com <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 <mailto:RPD at afrinic.net>

>> https://lists.afrinic.net/mailman/listinfo/rpd <https://lists.afrinic.net/mailman/listinfo/rpd>

> _______________________________________________

> RPD mailing list

> RPD at afrinic.net

> https://lists.afrinic.net/mailman/listinfo/rpd


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20191125/263b8b49/attachment.html>