Re: [ppml] Fw: ":" - Re: Proposed Policy: 4-Byte AS Number Policy Proposal
From ppml-bounces@arin.net Wed Dec 14 04:30:07 2005 To: ppml@arin.net From: Michael.Dillon@btradianz.com Date: Wed, 14 Dec 2005 10:32:06 +0000 Subject: [ppml] Fw: ":" - Re: Proposed Policy: 4-Byte AS Number Policy Proposal
I'm also not thrilled with "2-byte only" and "4-byte only" ASN; there's too much chance of confusion with "2-byte" and "4-byte" ASNs which have a different enough meaning to warrant a better distinction. I'd prefer something like "legacy" vs. "expanded", "low" vs. "high", etc.
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', as I understand the currently-proposed methodoloty, but there is no intrinsic reason why that _must _be the case. A two-byte AS number, and a 4-byte AS number with the SAME numeric value, _are_ distinguishable as =different= entities.
1. ARIN begin allocating AS numbers greater than 65535 to those who specifically request them starting on $date.
2. On $date ARIN will not allocate AS numbers less than 65536 unless a small number is specifically requested.
3. On $date, ARIN will no longer make a distinction between AS numbers less than 65536 and larger ones.
Guess what? I said it in plain English so I don't have to define what is an "AS number less than 65536" or an "AS number greater than 65535". I also don't have to invent silly new notations so that AS2 looks different after the change. A number is a number is a number.
Is it? <grin> Do you represent AS 17 in two bytes, or four? 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"?
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?
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
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. 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
On Wed, 14 Dec 2005, Robert Bonomi wrote:
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. :)
No, there isn't. AS numbers are integers. It just so happens that there are now two representations of said integers with different domain bounds. Any other interpretation simply adds too much confusion. After all, "2 byte AS2" vs. "4 byte AS2" implies *more than* 4 bytes -- because you have to use metadata beyond the 4 bytes to represent which "type" of AS you have. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
Actually, for actual implementation, there are subtle differences between AS 0x0002 ans AS 0x00000002. True, they are the same AS in 16 and 32 bit representation, and, for allocation policy, they are the same, but, in actual router guts, there are limited circumstances where you might actually care which one you are talking about. Owen --On December 15, 2005 1:45:20 PM -0500 Todd Vierling <tv@duh.org> wrote:
On Wed, 14 Dec 2005, Robert Bonomi wrote:
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. :)
No, there isn't. AS numbers are integers. It just so happens that there are now two representations of said integers with different domain bounds.
Any other interpretation simply adds too much confusion. After all, "2 byte AS2" vs. "4 byte AS2" implies *more than* 4 bytes -- because you have to use metadata beyond the 4 bytes to represent which "type" of AS you have.
-- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
On Thu, 15 Dec 2005, Owen DeLong wrote:
Actually, for actual implementation, there are subtle differences between AS 0x0002 ans AS 0x00000002. True, they are the same AS in 16 and 32 bit representation, and, for allocation policy, they are the same, but, in actual router guts, there are limited circumstances where you might actually care which one you are talking about.
The metadata in this case is per BGP session, not per AS as implied by the original post. They are still logically equivalent. Further, the least error-prone way to implement BGP that can work in both 2 and 4 byte AS representations is to go completely 4-byte internally on the router, and treat the 2-byte sessions as a backwards compatibility case. In such an implementation, there is also no such thing as a "2-byte AS", because all ASs are represented in 4 bytes. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
participants (4)
-
Michael.Dillon＠btradianz.com -
Owen DeLong -
Robert Bonomi -
Todd Vierling