Dear Sebastian, On Sat, Jan 25, 2014 at 02:56:16PM +0100, Sebastian Spies wrote:
So here's the thing: IXPs usually implement N:M filtering based on standard community strings. As standard BGP communities support only 4 bytes, this only works for IXPs with 2-byte ASNs and peers with 2-byte ASNs.
There are various directions in which a workable solution may for IXP Operators: - Use a mapping table: 32 bit values to 16 bit values. Every participant with a 4-byte ASN is represented with 2-bytes, there are pro's and con's to this approach. - Use an out-of-band mechanism which allows IXP participants to signal the desired routing policy to the Route Server. (VIX.at offers a web-interface where people can click and point to which ASNs they want to export or not). Another approach would be to signal the desired routing policy through RPSL. I've been working on some extensions which would allow an IXP participant to publish what the Route Server should do on their behalf, in this example 6777 is a Route Server and AS4247483647 is an IXP participant with a 4-byte ASN: import-via: AS6777 from AS4247483647 accept AS4247483647 export-via: AS6777 to AS4247483647 announce AS-ATRATO (read more here: http://tools.ietf.org/html/draft-snijders-rpsl-via ) Support for these extensions will be available in the next release of the RIPE Whois Database. After that IXP Operators can consider implementing support for RPSL-via. All of the above approaches have disadvantages: - Mapping tables add complexity - Most Out-of-band methods would differ from each other - RPSL-via is has yet to be implemented in the wild
Extended communities to the rescue?
Nope. Not as it stands today.
I have been asking some IXP operators, about their practice and their reply was "4-byte ASNs are supported by our RS". What's your experience?
Most of them are lying through their teeth. :-) Kind regards, Job