Route Server Filters at IXPs and 4-byte ASNs

[Sebastian Spies <s+Mailinglisten.nanog () sloc de>]

Hi there,

as 2-byte ASNs are close to depletion (see NRO announcement this week),
we have come across a topic, that might influence the adoption of 4-byte
ASNs. First of all, we have no data or experience about 4-byte ASN
adoption and are therefore unable to evaluate, if we should rush for the
last available numbers.

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.

Extended communities to the rescue? We are not sure: While RFC4260
(Extended Communities) allows for <Global Admin,2bytes>:<Local Admin,
4bytes> community strings (3.1 Two-Octet AS Specific Extended
Community), this works as long as the IXP itself uses a 2-byte ASN.

What happens, if the IXP uses a 4-byte ASN? RFC5668 (4-Octet AS Specific
BGP Extended Community) defines <Global Admin,4bytes>:<Local Admin,
2bytes>.

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?
Did you see IXPs, that do not support them? Do you think, the IXP
operators are aware of this limitation? Have you seen IXPs with 4-byte
ASNs or do RIRs reserve 2-byte ASNs for future IXPs?  What other
operational problems did you experience while using 4-byte ASNs?

A lot of questions. I am very curious about your answers.

Cheers,
Sebastian


-- 

SEBASTIAN SPIES

lnked.in/sspies