[rpd] Last Call - Resource Reservation for Internet Exchange Points

[ALAIN AINA]

Hello,

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….

Thanks

—Alain





> On Jun 18, 2015, at 3:10 PM, Mark Tinka <mark.tinka at seacom.mu <mailto:mark.tinka at seacom.mu>> wrote:
> 
> 
> 
> On 18/Jun/15 16:48, Owen DeLong wrote:
>> I disagree… I think that may be the easiest or most expedient solution, but almost certainly not the best.
>> 
>> 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.
>> 
>> Type 0x02 is for transitive communities where 0x42 indicates a non-transitive community.
>> 
>> The remaining portions of the community are the 32 bit ASN (MSB..LSB) followed by a 16 bit Tag value.
>> 
>> Thus, all existing practices (other than ASN:ASN tagging) can be supported in a nearly identical fashion just with longer community numbers.
>> 
>> 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:
>> 
>> 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.
>> 
>> 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.
>> 	(note, 0x02xx is used as a placeholder for either 0x02 or 0x42 depending on whether transitive or non-transitive behavior is preferred)
>> 
>> 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.
>> 
>> Overall, this gives more flexibility in communities than the current 32 bit community strings without requiring all that much effort to implement.
> 
> I have nothing against deploying RFC 5668 as a solution for this, to be
> honest, if folk come together to do it.
> 
> Mark.
> 
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net <mailto:rpd at afrinic.net>
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd <https://lists.afrinic.net/mailman/listinfo.cgi/rpd>



and on June 18, 2015 at 5:50:10 AM GMT, Mark Tinka <mark.tinka at seacom.mu <mailto:mark.tinka at seacom.mu>> wrote



On 18/Jun/15 00:27, Owen DeLong wrote:
> Since we’re talking about resources for exchange points that don’t exist yet, I don’t see how your statement is relevant.
> 
> 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.

Very likely. I was not in Tunis for the remainder of the conference meeting, so did not listen to any comments on the proposal.

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.

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.

Mark.
_______________________________________________
rpd mailing list
rpd at afrinic.net <mailto:rpd at afrinic.net>
https://lists.afrinic.net/mailman/listinfo.cgi/rpd <https://lists.afrinic.net/mailman/listinfo.cgi/rpd>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20150619/b0628754/attachment.html>