On 4 Oct 2016, at 14:13, Ignas Bagdonas <[email protected]> wrote:
> Both are prone to errors and conflicts - please do not use them, instead ask > your vendors to implement the correct native AS4 solutions. That is not a > huge price to pay to get an unambiguous solution to a problem that is real > and urgent. I'm all for a permanent solution, but routers just don't get updated with new features all that often. A temporary solution could look like this: I'm going to use AS-DOT notation for a bit here because it's easier for my purposes, obviously that's not a feature of my solution. The RIRs have received AS number ranges in 2.x, 3.x, 4.x, 5.x and 6.x from IANA. 1.x is unused and 0.x is covered by existing 16-bit solutions. We need 19 bits to encode 32-bit AS numbers up to 7.65535. There are 1024 private AS numbers, so we can borrow 10 bits there. Then we use 9 bits from the nn in AS:nn, leaving us with 7 bits for the actual nn. We encode the top 10 of the 19 bits in the private AS number space, but we do a bit of math to make sure that the range around ASN 65000 falls in the unused 0.x and 1.x ranges, because those are the most frequently used private 16-bit ASNs. This way any 32-bit AS number up to 7.65535 can be used in AS:nn where nn can be 0 - 127, which is just about enough to encode a reasonable local preference value. There are two ways to do this: with an unambiguous mapping between those AS:nn values and the 32-bit community value, or one where each AS:nn maps to a 32-bit value, but the 32-bit value can map to multiple AS:nn, for instance 263000:0 is equal to 65535:44032. If we allow this that also means we can accommodate ASNs above 7.65535. Those will just map to (AS mod 7):nn. But if we allow this then there's no unambiguous mapping from the 32-bit community value to a text representation so filtering communities using regular expressions will no longer be possible. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
