<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>+1 these points were indeed discussed. It is worth following up on this separately given the continued discussion after support for the stated policy </div><div><br></div><div>Regards</div><div>Nii</div><div><br>On Jun 19, 2015, at 9:33, ALAIN AINA <<a href="mailto:aalain@trstech.net">aalain@trstech.net</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Hello,</div><div class=""><br class=""></div><div class="">All of these points were discussed intensively during AFRINIC-21 in Mauritius. It was even suggested to form a small group to look at the technical aspects for the 2-bytes ASN reservation. Make the problem statement clear, evaluate possible solutions… and answer the question about shouldn’t this be a global policy if need be….</div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">—Alain</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 18, 2015, at 3:10 PM, Mark Tinka <<a href="mailto:mark.tinka@seacom.mu" class="">mark.tinka@seacom.mu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class=""><br class="">On 18/Jun/15 16:48, Owen DeLong wrote:<br class=""><blockquote type="cite" class="">I disagree… I think that may be the easiest or most expedient solution, but almost certainly not the best.<br class=""><br class="">I think the best solution is to migrate to extended communities type 0x02 or 0x42 (RFC5668) with subtypes 0x02 for Route Target or 0x03 for Route Origin.<br class=""><br class="">Type 0x02 is for transitive communities where 0x42 indicates a non-transitive community.<br class=""><br class="">The remaining portions of the community are the 32 bit ASN (MSB...LSB) followed by a 16 bit Tag value.<br class=""><br class="">Thus, all existing practices (other than ASN:ASN tagging) can be supported in a nearly identical fashion just with longer community numbers.<br class=""><br class="">For the case of ASN:ASN tagging (which I still don’t have a sufficient explanation for the use case), this could be implemented using two communities as follows:<br class=""><br class="">1. Assign a unique value to each required ASN pair. Admittedly there is a scaling limit of 65536 ASN pairs per router, but since most routers will fall over well before 65536 BGP sessions, this shouldn’t be a significant issue.<br class=""><br class="">2. Use two community tags of the format 0x0203:ORIGIN:XXXX and 0x0202:DEST:XXXX where ORIGIN and DEST are the two ASNs in the previous ASN:ASN tag and XXXX is the unique identifier assigned to this ASN pairing.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>(note, 0x02xx is used as a placeholder for either 0x02 or 0x42 depending on whether transitive or non-transitive behavior is preferred)<br class=""><br class="">Yes, this requires some extra effort, but it’s really the only viable option in the case where ASN:ASN tagging is required and there are two ASNs involved.<br class=""><br class="">Overall, this gives more flexibility in communities than the current 32 bit community strings without requiring all that much effort to implement.<br class=""></blockquote><br class="">I have nothing against deploying RFC 5668 as a solution for this, to be<br class="">honest, if folk come together to do it.<br class=""><br class="">Mark.<br class=""><br class="">_______________________________________________<br class="">rpd mailing list<br class=""><a href="mailto:rpd@afrinic.net" class="">rpd@afrinic.net</a><br class=""><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" class="">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a><br class=""></div></blockquote><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">and on June<font face="-webkit-system-font, Helvetica Neue, Helvetica, sans-serif" class=""> 18, 2015 at 5:50:10 AM GMT, </font><span class="" style="font-family: -webkit-system-font, 'Helvetica Neue', Helvetica, sans-serif;">Mark Tinka <<a href="mailto:mark.tinka@seacom.mu" class="">mark.tinka@seacom.mu</a>> wrote</span></div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><br class=""><div class="moz-cite-prefix">On 18/Jun/15 00:27, Owen DeLong wrote:<br class=""></div><blockquote cite="mid:39B0F74D-8D5E-4AC5-9E9B-20270CB6E39B@delong.com" type="cite" class="">Since we’re talking about resources for exchange points that don’t exist yet, I don’t see how your statement is relevant.<div class=""><br class=""></div><div class="">I’m all for making life simpler for IXPs, but what I don’t want to do is promote expanding damage due to poor education. In this case, I believe that ASN ≤65535 issue is more likely the latter than the former.</div></blockquote><br class="">Very likely. I was not in Tunis for the remainder of the conference meeting, so did not listen to any comments on the proposal.<br class=""><br class="">This is also an operational issue in service provider networks. Use of the 16-bit low and high order values to convey BGP communities has made it a practical problem of how this can be replicated when one uses the same representation convention while in possession of a 32-bit ASN.<br class=""><br class="">While there are a number of proposals around how this can work, at the moment, the best solution I see is to decouple the ASN from the BGP community. It is less-than-ideal, yes, but given that this is not embedded router code, but rather, a community "understanding", we do not really need to tie our hands if we don't have to.<br class=""><br class="">Mark.<br class=""></div>_______________________________________________<br class="">rpd mailing list<br class=""><a href="mailto:rpd@afrinic.net" class="">rpd@afrinic.net</a><br class=""><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd" class="">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a></div></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>rpd mailing list</span><br><span><a href="mailto:rpd@afrinic.net">rpd@afrinic.net</a></span><br><span><a href="https://lists.afrinic.net/mailman/listinfo.cgi/rpd">https://lists.afrinic.net/mailman/listinfo.cgi/rpd</a></span><br></div></blockquote></body></html>