<div dir="ltr">David,<div><br></div><div>This is exactly the right question.  </div><div>To what extent is there working code to support AS numbers larger than 65535, </div><div>and how costly/dfifficult is it to support them.</div><div><br></div><div><br></div><div>We examined this very question when we passed 2009-6.</div><div><br></div><div>The community concluded that there was really no technical reason</div><div>why the larger ASNs could not work, and the adoption of 2007-19 </div><div>was to put the community on notice that they had until 12/31/2009</div><div>to sort this out (about two years from when the community supported it).</div><div><br></div><div>This was modified by 2009-6 to push back the action by one year.</div><div><br></div><div>In April of 2014, the IANA asked for advice on this policy.</div><div><br></div><div>It seemed there was an RIR who was out of 4-byte ASNs, but </div><div>still had so many 2-byte ASNs that they did not qualify for </div><div>additional 4-byte ASNs.  </div><div><br></div><div>The question was if it was in the best interest to hold the two-byte</div><div>ASNs in reserve, and issue more 4-byte ASNs?  Surely the intent</div><div>was not to force them to burn through their existing 2-byte ASN holdings?</div><div><br></div><div>This came to a crisis during the April ARIN meeting, and the communtiy was </div><div>consulted at lenght.  The ARIN community (at that time) mostly said there </div><div>really wasn't a technical reason that made supporting the larger ASNs</div><div>problematic.  If you have a router that is less than 5 years old, just upgrade</div><div>the code!</div><div><br></div><div>The result was that the RIR should burn through the two byte ASNs, and IANA</div><div>could not look the other way on two byte ASNs that were set aside.  </div><div>It was also noted that RIR could manage their two byte and four byte ASNs</div><div>as they saw fit, but might need to ensure they did not set so many two-byte</div><div>ASNs aside which could prevent them from getting additional four-byte ASNs.</div><div><br></div><div>We also suggested that the IANA and the RIR could agree to take a fixed amount</div><div>of their 1024 ASNs in two-byte, but if they did reach such an agreement, that it</div><div>should be transparent.  </div><div><br></div><div>How are things different now?</div><div><br></div><div>Where does the community currently stand on the question of</div><div>how costly/dfifficult is it to support ASNs larger than 65535?<br></div><div><br></div><div>-------------------------------</div><div><br></div><div>my take:</div><div><br></div><div>I initially came at this from the same perspective the community had in </div><div>2009.  This is just s simple software fix.  Everyone agrees that there is no</div><div>technical reason preventing the support of big ASNs.  Anyone running </div><div>BGP (or about to run BGP) surely has equipment that is current enough</div><div>to run current code that supports big communities.</div><div><br></div><div>But in discussions, some have pointed out, to not allow ASN transfers,</div><div>supports the encumbants, and is a barrier to entry for a smaller ISP</div><div>who has a four byte ASN.  This transit provider may have a down stream </div><div>customer with older hardware that cannot run code that suppots big </div><div>communities.  As a result, their down stream customer (with old gear) </div><div>cannot participate in BGP TE as they cannot encode their upstream ISP's</div><div>four-byte ASN into a big BGP community.</div><div><br></div><div>Secondary to this, the same four-byte ASN using transit provider may want</div><div>to purchase transit (or Peer) with a network that supports only two byte-ASN, and</div><div>will not be able to BGP peer.  </div><div><br></div><div>I'm not sure how big a problem this is, and how costly / dfifficult is it to support </div><div>big BGP communities in this space.    My support or oppision to this proposal</div><div>hinges on hearing answers to this question from those in the space descibed.</div><div><br></div><div><br></div><div>___Jason</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 5, 2018 at 2:54 PM, David R Huberman <span dir="ltr"><<a href="mailto:daveid@panix.com" target="_blank">daveid@panix.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
For this reason, I support draft policy proposal ARIN-2008-1.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>