[ppml] Fw: ":" - Re: Proposed Policy: 4-Byte AS Number Policy Proposal

Wed Dec 14 14:51:54 UTC 2005

> > That's an example of the lack of plain English in the 
> > proposal. Why don't we just talk about AS numbers greater
> > than 65535 or AS numbers less than 65536?
> 
> Because there is more to it than just that.  :)
> 
> there is the matter of whether they are represented by 2 bytes, or 4 
bytes
> _in_transmission_.   '0x00004F4F' is a '4-byte' AS number that has a 
value
> less than 65,536.  It _should_ be treated identically with the 2-byte AS 

> number '0x4F4F', 

Thank you for pointing out why we don't need to concern
ourselves with the difference between old AS 2 and new
AS 2. They are the same in every way that matters except
to protocol sniffers and protocol implementors. The new
AS number spec says so itself.

> Is it?  <grin>
> 
> Do you represent AS 17 in two bytes, or four? 

Right now I am representing it in 4 bytes because
by email client uses two bytes (UTF8) per decimal
digit. But what difference does this make. Whether
it is 17, 021, 0x11 or "17" it is still greater than
16 and less than 18.

> if you use 2 bytes, do you, "somewhere down the road", change to 
representing
> it with 4 bytes?  or do you deal with 'mixed-length' codes "in 
perpetuity"?

The whole discussion on PPML is about ARIN beginning to use
4 byte binary representation for AS numbers so that they can
begin giving out AS numbers greater than 65535 to those people
who *WANT* such numbers in order to use 4 byte AS numbers operationally.
And to be ready for the day when AS numbers less than 65536 have
run out.

It is a good idea for people to begin scheduling this change
in any internal systems which record AS numbers in binary
form. Of course, those far-sighted companies who represent
AS numbers as variable length strings in their applications
and databases will have no need to change things.

If you had to cross-post from PPML, you could have chosen
something with more operational relevance like the fact that
multiple networks will appear to be using AS 23456 because
at the boundary between old BGP4 speakers and new BGP4 speakers,
any AS numbers greater than 65535 will be mapped into AS 23456.

--Michael Dillon