Fwd: Re: RPSL support for 32 bit ASN

Henk Uijterwaal wrote:
> Larry,
>
>>     There was considerable discussion during the development of the
>> RPSLng spec (RFC4012) concerning modifying the syntax for existing 
>> attributes.
>> The consensus was that this approach should not be taken and that
>> new attributes should be created wherever an IPv6 address could
>> appear so as not to break existing tools.
>> draft-uijterwaal-rpsl-4bytesas-ext-00.txt
>> appears to have abandoned this approach.
>
> That is correct.  I looked at the problem and creating new attributes for
> ASN32 would cause the number of attributes to expand as N^2.  In other
> words, for each kind of attribute, there would be a version for 
> IPv4-ASN16,
> IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32.  If something else is changed in
> the future, this will result in 8 versions of essentially the same
> attribute.  This does not look very attractive to me.
>
> Also, contrary to IPv4 and IPv6, we are very likely to have a mixed
> ASN16 and ASN32 world "forever".  In fact, the ASN32 standard is
> specifically designed with this in mind, and the two worlds can
> live happily together.
>
> So, any tool will have to be upgraded sooner or later, the only question
> is when and how.
>
> In both cases (change existing attributes or create new ones), people 
> will
> have to upgrade when they move into the ASN32 world.   The difference is
> in the code change.  In my draft, the tools will have to recognize 2
> versions for an AS.  Changing attributes means that tools will have to
> check if the ASN16 or ASN32 version is there,  then parse that to get
> the information.   In the end, this doesn't look like a big difference
> to me.
>
>

     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.  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.

INT            [[:digit:]]+
ASNO           AS{INT}

   The presentation and submission layers could optionally support
the "." 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.

   The other option would be to update RFC4012 (RPSLngbis?) as it is
relatively fresh and the tools to process mp- attributes are few.

 -Larry