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

[Nii Narku Quaynor]

+1 these points were indeed discussed.  It is worth following up on this separately given the continued discussion after support for the stated policy 

Regards
Nii

> On Jun 19, 2015, at 9:33, ALAIN AINA <aalain at trstech.net> wrote:
> 
> 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> 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
>> 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> 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
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
> _______________________________________________
> rpd mailing list
> rpd at afrinic.net
> https://lists.afrinic.net/mailman/listinfo.cgi/rpd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20150619/5af582cb/attachment.html>