[ppml] Policy Proposal 2005-9: 4-Byte AS Number

[Scott Leibrand]

On 12/22/05 at 12:09pm -0000, Michael.Dillon at btradianz.com wrote:

> > Now the policy, as written, had a definition of "4-Byte only AS
> > Numbers"  in the terminology section, and I suspect that this
> > definition is adequate in terms of equating this phrase with the
> > concept of numbers with non-zero high order bits.
>
> This is the type of language that I am attacking when
> I suggested that the policy proposal needs a complete
> rewrite to put into PLAIN ENGLISH.
>
> Convoluted language may be acceptable in academic papers
> but it has no place in ARIN's policies!

The problem with "plain English" is that it conveys less information
and/or is more ambiguous than precisely defining and then properly using
new terminology.  If that were not the case, jargon would not be so
prevalent nor so useful.

> As far as I can see, there is no such thing as a 4-byte
> AS number and therefore no such thing as a 4-byte only
> AS number. All the AS numbers that I have ever seen have
> been simple decimal numbers, positive integers if you want
> a more technical definition. If the BGP protocol needs to
> allocate some number of bytes to transmit the number, then
> that is an implementation issue, not a policy issue.
>
> On the policy level I see that we are lifting the maximum
> AS number beyond the 65535 that is the current maximum.
> As far as policy is concerned, I don't see what bytes
> have to do with this at all.
>
> If people want to talk about bytes, I suggest that they
> should join the IETF list or the BGP implementors list.

The problem here is that it's not just an implementation issue, it's a
standards issue.  The RFC's defined by the IETF et. al. dictate that
existing autonomous system numbers, because they are two-byte unsigned
integers, must be in the range of 1-65535.  Because the real world drives
ARIN policy, ARIN cannot simply ignore that fact and blithely continue to
allocate autonomous system numbers of 65536 and above without working with
the routing community (represented by the IETF, BGP implementors, NANOG,
et. al.) to ensure such numbers will be usable.  That's why this policy
has been proposed.

The reason for defining 2-byte, 4-byte, and 4-byte-only ASNs in this
*temporary* policy is to clarify to those who must actually use the
policy what their options are.  If your version of IOS doesn't support
4-byte ASNs, you need a 2-byte one.  If you want to test whether your new
bleeding-edge code properly supports 4-byte ASNs, you need a 4-byte-only
ASN.  If your mainline well-tested code supports 4-byte ASNs and you're
trying to operate a production network, any 4-byte ASN will do.

While you could remove the 2-byte, 4-byte, and 4-byte-only definitions and
simply refer to ranges of unsigned integers in the policy, that would
provide less information to ARIN members when they must decide whether to
request an ASN from a specific range.  If it's plain on my ASN request
form that I can requesting a 2-byte or 4-byte-only ASN, I'm much more
likely to be able to Google for "2-byte vs. 4-byte ASN" and get useful
guidance on which my router supports.

-Scott