If I may, I'd like to try and re-focus the discussion of 2018-1 on the network engineering problem that prompted this draft proposal. The solution this draft policy proposal offers to the problem is where I think the real value is, and where I think PPML needs to focus.
Since the publication of RFC1997 in the 1996, network engineers have utilized an extension of BGP called the BGP communities attribute to enginer traffic (to "shape traffic") in a desirable way.
RFC1997 only supports the use of 2-byte ASNs. As the free pool of 2-byte ASNs began to shrink, a solultion was needed to enable networks labelled with 4-byte ASNs to utilize BGP community attributes.
In 2010, a draft of Flexible Community attribute was discussed, but no working code was widely released. In 2016, a draft of Wide Comunity attributes was released, but also resulted in no working code. Finally, in February 2017, RFC8092 was published, and Large BGP Communities became the protocol standard for defining 4-byte AS numbers within the BGP community attribute.
Working code exists for some equipment and software, is planned for other equipment and software, but the point is that RFC8092-compliant code is not prevelant in the DFZ. This is important because it means a network operator who wants to shape their traffic properly with BGP communities still needs a 2-byte ASN or it won't work.
This proposal addresses the problem by allowing registrants of an unused or unwanted 2-byte ASN to transfer the registration to a network operator who needs one, all within the existing and community agreed-upon framework of Inter-RIR transfers.
For this reason, I support draft policy proposal ARIN-2008-1. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
