[arin-ppml] ARIN-PPML 2018-1

[David R Huberman]

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.