[arin-ppml] ARIN-PPML 2018-1
David R Huberman
daveid at panix.com
Mon Feb 5 14:54:01 EST 2018
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
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.
More information about the ARIN-PPML