North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: that 4byte ASN you were considering...

  • From: Henk Uijterwaal
  • Date: Tue Oct 10 06:22:18 2006 
At 10:44 10/10/2006, [email protected] wrote:
> > - 'Canonical representation of 4-byte AS numbers '
> >
http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-01.txt

>
> and what is good or bad about this representation? seems simple to me.
> and having one notation seems reasonable. what am i missing?

It breaks any applications which recognize IP address-like
objects by seeing a dot in an otherwise numeric token.
Well, it will break an applications that considers everything
consisting of numbers and dots to be an IP address/netmask/inverse
mask.  I don't think many applications do this, as they will then
treat the typo "193.0.1." as an IP address.  It won't break applications
that check if there are exactly 4 numbers in the 0-255 range and 3 dots.

The alternative notation (x:y) is much worse in this respect.  "x:y"
is something (a community string).  "x.y" is not.



The real question is what does the notation 1.0 add that the
notation 65536 does not provide?

It is (for me, and I guess most other humans) much easier to read and
remember, just as 193.0.1.49 is easier to read and remember than
3238002993.  It also reflects that on the wire there are two 16
bit numbers, rather than 1 32-bit number.

More important: I think it is a mistake to assume that using AS65536
will NOT break things:

1. If you are a 16-bit AS speaker (ASN16), then AS65536 is not just
   the next one in the line, it is an AS that will have to be treated
   differently.  The code has to recognize it and replace it by the
   transistion mechanism AS.

2. Just as people having used the regexps that you mentioned, I'm
   also certain that people have used unsigned short int's or
   signed long int's in their code.

In short, like it or not, you will have to check and update your tools
anyway.


If the IETF had really wanted
The IETF process is open and you can still comment on the issue.

Henk


------------------------------------------------------------------------------
Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre http://www.amsterdamned.org/~henk
P.O.Box 10096 Singel 258 Phone: +31.20.5354414
1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445
The Netherlands The Netherlands Mobile: +31.6.55861746
------------------------------------------------------------------------------

1160438400 + 381600 = 1160820000.