[arin-ppml] 2-byte ASN policy

[Ron Grant]

The biggest technical problem with 4-byte ASNs that I'm aware of comes 
when propagating BGP communities - AFAIK even with extended communities, 
you can't specify two 4-byte ASNs in a single community.

This can be worked around when using communities for direct peering 
arrangements, as one side of the equation is static - but at a Public 
Exchange point, it can be problematic, because who knows who might want 
to connect or not connect to whom.

Recently we ran into this problem when requesting an ASN for the 
Vancouver Internet Exchange (VANIX) - we were told there were no 2-byte 
ASNs left, so we went back to the drawing board to see how we could run 
our Route Server with a 4-byte ASN, and after wrestling with the problem 
for a few weeks, went back to ARIN and...joy!...someone had returned a 
2-byte, which we obtained for the RS.

IMO any future returned 2-byte ASNs should be reserved for critical 
infrastructure or special need, but I'd love to find a solution to the 
communities issue that made 2-byte ASNs "not special" anymore.




On 2016-04-03 11:36 AM, Adam Thompson wrote:
> IMO, 2-byte ASNs should simply be retired and not reallocated. 
> "Solving the technical problem", as described in your email, is 
> actually ensuring the perpetuation of a different technical problem.
> It's the same sort of thing as the IPv4 vs IPv6 --transition, but this 
> time ARIN has an opportunity to at least avoid being part of the 
> problem, even if it can't really be part of the "solution".
> Let's please not prolong this problem, too... even in central Canada, 
> known for a paucity of upstream carriers, it's now commercially 
> feasible to work around the 2-byte technical limitations.
>
> -Adam
>
>
> On April 3, 2016 12:59:37 PM CDT, Andrew Dul <andrew.dul at quark.net> 
> wrote:
>
>     Hello,
>
>     I am starting a new thread in PPML, as a follow up to the ARIN
>     suggestion and consultation which recently started regarding creating a
>     2-byte ASN waiting list.
>
>     The original suggestion is here:
>
>     https://www.arin.net/participate/acsp/suggestions/2016-04.html
>
>     ARIN opened a consultation on this suggestion on the arin-consult
>     mailing-list.  This thread starts here for those who are not subscribed
>     to arin-consult.
>
>     http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html
>
>     http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html
>
>     As the thread evolved it has been suggested that this issue should be
>     resolved via the policy development process rather than through a
>     suggestion.
>
>     There are a number of questions that have been raised by this thread.  I
>     am copying them here to continue the discussion on PPML.
>
>     ===
>
>     Working problem statement: ARIN will receive 2-byte ASNs as  returns
>     over time, and these ASNs have perceived or additional value to
>     organizations compared to 4-byte ASNs.  How should ARIN allocate these
>     2-byte ASNs?
>
>     ===
>
>     Should they be given to the next requester, regardless of technical need
>     for a 2-byte ASN? (What are the technical qualifications we should use
>     if there is a specific technical need?  e.g. provides transit to more
>     than 1 ASN?)
>
>     If there is really a technical need for 2-byte ASNs, shouldn't we
>     attempt to build an inventory of 2-byte ASNs?
>
>     Should returns be held in reserve?
>
>     Should ARIN hold them for some period of
>        time
>     before reallocating them?
>
>     Should they be put up for auction to  qualified organizations?
>
>     Should they be given to the 1st organization  on a wait-list for 2-byte
>     ASNs?
>
>     Would an organization looking for a 2-byte ASN have the option to
>     receive a 4-byte ASN in the interim?  If they did would they have to
>     return it?
>
>     Should the waiting list be closed to organizations that already have a
>     2-byte ASNs?
>
>     I and the AC would appreciate your comments on these questions so that
>     we can start to build a draft policy that best matches with what the
>     community would like to see implemented by ARIN.
>
>     Thanks,
>     Andrew
>
>
>
>     ------------------------------------------------------------------------
>
>     PPML
>     You are receiving this message because you are subscribed to
>     the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>     Unsubscribe or manage your mailing list subscription at:
>     http://lists.arin.net/mailman/listinfo/arin-ppml
>     Please contact info at arin.net if you experience any issues.
>
> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-- 
Ron Grant                             Managed DSL/Cable/Wireless/Fibre
Skyway West Business Internet          Internet and Private Networking
rgrant at skywaywest.com                  Bonding and Fail Over Solutions
cell: 604-737-2113              Virtual Data Centre and Private Clouds
direct: 604-484-5263                         http://www.skywaywest.com

Sales, Support and Billing    http://www.skywaywest.com/contact-us.htm

ca.linkedin.com/in/obiron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20160403/4d2dcf2e/attachment.htm>