Search RPD Archives
[rpd] Last Call - Resource Reservation for Internet Exchange Points
mark.tinka at seacom.mu
Thu Jun 18 15:10:45 UTC 2015
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.
More information about the RPD