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

[Allan Eising <[e-mail]>]

List, Nick, Jeff,

I just wanted shortly to express that I agree with both Jeff here and Nick
Hilliard. Their points are good enough and I feel no need to repeat them.

We use a great deal of private ASNs, so an extended range of numbers would
be welcomed no matter what, but with regards to the operational side of
things, I would much prefer if the draft would reflect the points made in
this thread.

/Allan



On Thu, Dec 13, 2012 at 3:15 PM, Jeff Wheeler <[e-mail]> wrote:

> 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
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>