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

[Owen DeLong]

> On Jun 17, 2015, at 22:50 , 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.

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.

Owen