Re: [Idr] WGLC on draft-ietf-idr-as-private-reservation-00

[Jeff Wheeler <[e-mail]>]

On Wed, Dec 12, 2012 at 1:35 PM, David Farmer <[e-mail]> wrote:
> Nick, why is this any different than creating a regexp that matches the
> current private ASN range?  To me this is a CLI/Config semantics issue and
> not a standards or allocation issue.

When I read the above argument, I think it is a clear statement that
you don't just not care how something appears in a CLI/NMS, but you
actually care more about an arbitrary range of numbers being
unnecessarily bit-aligned than you do a zero-cost move of that range
to where it can be CLI-friendly.

Operators do care what is on the CLI.  Operators also think the IETF
pays little attention to our concerns.  That's our fault for not
participating in the IETF process, but here you've got some operators
saying, please, reconsider this allocation!  Make it easier on us!
And then you've got some guys whining about a bit-alignment thing that
actually isn't.

Why isn't it bit-aligned?  Because ASN 2^32-1 is already reserved by
IANA and is not part of this new proposed private ASN range.

That means a programmer implementing a test to find if an ASN is in
this private range will be doing a range-check.  Could you make a
branch table from the first bits and then do the second arithmetic
comparison?  Sure.  Why would you want to?  Unless there are a bunch
of other branches in the table, it will be slower.

There is no argument to be made that the bit-alignment can make code
faster.  We are talking about a difference of a few instruction cycles
on any modern CPU anyway, but unless there will be a bunch of other
results besides "private" and "not private," which would mean there
are going to be a bunch of other reservations for different kinds of
ASNs in the future, then the bit-alignment simply does not offer an
advantage.  Making the branch-table would actually be slower, but not
so much slower you would care; however you probably won't implement
the branch table anyway because it is both more complicated and
slower.

I continue to think that a decimal-aligned allocation makes more
sense.  I also agree with Nick Hilliard that this range should
possibly be much lower in the ASN space to further improve legibility.

-- 
Jeff S Wheeler <[e-mail]>
Sr Network Operator  /  Innovative Network Concepts