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

[Mark Tinka]

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.