Re: Fwd: Re: RPSL support for 32 bit ASN

["Larry J. Blunk" ljb@localhost]

Henk Uijterwaal wrote:
> Larry,
>
>
> >     The big difference is that existing tools can potentially break if
> > the syntax is changed in existing attributes.     I agree that adding 
> > new
> > attributes is undesirable, but I see a couple alternatives.   The 
> > first would
> > be to use straight integer notation for the AS numbers instead of the
> > "." notations.
> The IESG has asked for a standard notation for ASN32 when processing
> draft-ietf-idr-as4bytes.  draft-michaelson-4byte-as-representation was
> written to suggest the "x.y" notation.  This draft is likely to be
> accepted soon.
>
> My draft follows this "x.y" notation simply because I don't think that it
> is a good idea to have 2 different formats for the same thing.  At least,
> it'd drive me nuts if I had to type 1.0 in one place (my router CLI, for
> example) and 65536 in another (an RPSL tool) when referring to the same
> thing.
       The tool could convert from "x.y" when processing for submission,
so you wouldn't have to deal with 2 different formats.
> >  This is actually compatible with the RFC 2622 flex macro
> > for AS numbers (as Mark Prior noted) and would likely be compatible
> > with existing tools.
> An AS has been a 16 bit number forever (in terms of the lifetime of the
> Internet) and authors have implicitly used that when writing their tools.
> That means: regular int's (or even short unsigned ints) in the code,
> checks on input that numbers entered are below 65536 and/or 5 digits,
> arrays dimensioned to 65536, etc.  All this code will have to be
> checked and updated.  I would definitely not feel comfortable using
> code with numbers outside the range of the original spec.
  The original spec doesn't specify a range.   Some code will have problems
with numbers greater than 16-bit, others won't.   Certainly fewer 
implementations
will have issues with 32-bit numbers than "x.y" notation.

> >   Note that RFC3779 uses a straight integer for 32-bit
> > ASN's  (as opposed to the dotted character bitstrings for IPv4 
> > numbers), so
> > this is not unprecedented.
> I seriously doubt that the authors of RFC3779 had ASN32 in mind when they
> wrote that RFC.  I also think that this is a good example of why things
> have to be checked; a regular C integer (31 bits plus sign bit) in your
> code will fail for ASN 32768.0.  It should be an unsigned int.
    Actually, they did have 32 bit AS numbers in mind.  That's why they 
defined the
following in the RFC --

Autonomous System number - a 32-bit number that identifies an
     autonomous system.

  I'm not sure if this is actually compatible with the ASN.1
INTEGER definition, but they definitely had the foresight to
allow for 32-bit AS numbers.