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