On Tue, Oct 4, 2016 at 6:50 PM, <[email protected]> wrote: > 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. > > this proposal seems a bit complex, it doesn't appear to be required to be so complex, and I think in ~2yrs time most everyone that cares about this problem gets large-communities support in their devices.
Why pay complexity tax today for something that will be obsolete in ~2yrs time? > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
