Fwd: Re: RPSL support for 32 bit ASN

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.