Subject: [Idr] Last Call: 'Canonical representation of 4-byte AS numbers' to Informational RFC (draft-michaelson-4byte-as-representation)

From: The IESG <[email-masked]>
Date: Mon, 09 Oct 2006 14:43:55 -0400

The IESG has received a request from an individual submitter to consider
the following document:

- 'Canonical representation of 4-byte AS numbers '
   <draft-michaelson-4byte-as-representation-01.txt> as an Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-11-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-01.txt

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: John Leslie <[email-masked]>
Date: Mon, 9 Oct 2006 16:11:06 -0400

>    <draft-michaelson-4byte-as-representation-01.txt> as an Informational

   While I entirely agree with the author that using ":" to separate the
high-order 16 bits from the low-order 16 bits would be a bad idea, I'm
not confident that using "." would be problem-free.

   The draft already mentions possible confusion with floating-point
numbers; I also see possible confusion in searching.

   Before trying to designate a "standard" representation, IMHO, we should
make sure there's a problem to be solved, and consider how likely our
"solution" is to prevail.

   And there's a particularly obvious alternative: simply continuing the
decimal notation used now. We've already adapted to five-digit decimal
numbers without a whimper: is there really any reason to believe six
digits will prove unworkable?

--
John Leslie <[email-masked]>

---

From: Joe Abley <[email-masked]>
Date: Mon, 9 Oct 2006 23:09:59 -0500

> digits will prove unworkable?

But then how do you distinguish between a 2-byte only AS number and a  
4-byte AS number which happens to be less than 0.65535?

Joe

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 10 Oct 2006 09:05:23 -0400 (EDT)

On 10/09/06 at 11:09pm -0500, Joe Abley <[email-masked]> wrote:

> >    And there's a particularly obvious alternative: simply continuing
> > the decimal notation used now. We've already adapted to five-digit
> > decimal numbers without a whimper: is there really any reason to
> > believe six digits will prove unworkable?
>

There is no meaningful distinction, is there?  The only distinctions I can
see are for understanding how they'll work for backwards compatibility,
and "less than 65535" seems adequate for that.

I'm agnostic to which notation we should use, but I don't think it matters
all that much, as long as we avoid confusing ourselves.

-Scott

---

From: Bill Fenner <[email-masked]>
Date: Tue, 10 Oct 2006 06:36:52 -0700

>[If you just use larger decimal values,]
>... how do you distinguish between a 2-byte only AS number and a  

When is this difference significant?  0.7018 == 7018, an AS number
is an AS number.  There are some AS numbers that can *only* be
represented in 4 bytes, but there isn't a different space for the
4-byte values.

I'm in the "having a common notation is better than not" camp - there is
no perfect notation, but if everyone ends up using the same notation,
it'll improve consistency and reduce confusion.  (I'd be willing to be
convinced "no notation is OK", i.e., people don't have a problem with
using longer and longer decimal strings - we probably don't expect to
get to 4294967295 but some would argue that's too long for people to
easily remember)

  Bill

---

From: "Bruno Rijsman" <[email-masked]>
Date: Tue, 10 Oct 2006 09:50:31 -0400

I second this, in other words: I am also in favor of simply displaying
4-octet AS numbers as (potentially large) decimal integer numbers.

There is already one widely used implementation that does just that.

The main reason for my preference is that there is no semantic
difference between 333 and 0.333: they both refer to the same autonomous
system. Consider an AS-path with traverses various islands of 2-octet
and 4-octet BGP speakers; it would probably be confusing if the AS
number flipped back and forth from 333 to 0.333.

-- Bruno

> -----Original Message-----
> From: Bill Fenner [mailto:[email-masked]]
> Sent: Tuesday, October 10, 2006 9:37 AM
> To: Joe Abley
> Cc: [email-masked]; John Leslie; [email-masked]
> Subject: Re: [Idr] Re: Last Call: 'Canonical representation of 4-byte
> ASnumbers' to Informational
> RFC(draft-michaelson-4byte-as-representation)
> 
> 
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 10 Oct 2006 09:16:40 -0500

On 10-Oct-2006, at 08:05, Scott Leibrand wrote:

> There is no meaningful distinction, is there?

In terms of resource allocation, it seems to me that you only have to  
deal with 32-bit numbers, and no distinction is necessary.

In terms of presentation to an operator, e.g. as part of a "show"  
command, it also seems like whatever is simplest and easier on the  
eye wins.

(I would note that on cisco routers it's perfectly possible to view  
community string attributes as simple 32-bit numbers, but everybody  
seems to prefer the representation of two 16-bit values separated by  
a colon.)

In terms of encoding values into a wire format to include in a BGP  
attribute, though, might it not be important for the router to know  
which was intended? Perhaps not; I'm not a router vendor, and I'm not  
presupposing an answer.

Joe

---

From: Geoff Huston <[email-masked]>
Date: Wed, 11 Oct 2006 02:37:14 +1000

>which was intended? Perhaps not; I'm not a router vendor, and I'm not

According to draft-ietf-idr-as4bytes-12.txt, the wire format uses 
straightforward 32 bit fields to encode an AS number in "new" BGP.

The notation is in the form of offering guidance to folk relating to 
CLI, Route Registry Objects, Whois Objects, routing requests, ... and 
other places where humans and AS numbers intersect. I'm sure that 
most implementations of such tools would align to the principle of 
being liberal in what they accepts as input, but the notation is 
intended to offer some guidance to implementors and users of a 
default input format and a default output format.

regards,

Geoff

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 10 Oct 2006 13:14:01 -0400

I'm inclined to agree with others who've expressed a slight 
preference for a simple decimal integer representation.  I think the 
(lack of) technical issues with doing so has already been pretty well 
captured in the conversation.

--John

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Oct 2006 14:41:45 +0200

On 10-okt-2006, at 19:14, John G. Scudder wrote:

> preference for a simple decimal integer representation.  I think  
> the (lack of) technical issues with doing so has already been  
> pretty well captured in the conversation.

My preference is a lot stronger than this. The main issue is that  
it's customary today in routers to work on AS paths with regular  
expressions, and introducing a new character in AS numbers will  
require changing at least some of those regular expressions (= all  
must be reviewed), while adding digits generally shouldn't.

xx.yy notation is also interpreted as a valid IPv4 address in many  
implementations, for instance, try: ping 17.4752682

Note that there is significant resistance to this on the NANOG list,  
and although this resistance is criticized, nobody is actually  
speaking up in favor of the draft under consideration.

On a related note: what happens to community values? These are 32  
bits long but are often interpreted as AS:nn. If AS is already 32,  
then there are no bits for nn. The obvious answer is to use some kind  
of extended community, but that's something that won't happen over  
night.

Suggestion: introduce a new syntax for community values that is:

[16 low order bits AS * 16 + 4 lowest high order bits AS][some  
character][12 bits nn]

For instance, today you'd see 701:120, with the new notation  
something like 7000001#120 (although 700001#5000 isn't valid while  
701:5000 is). If the RIRs then start giving out 32-bit AS numbers  
starting at 655360 or higher, the high order bits of the AS and the  
nn won't clash for existing AS numbers (= < 40960).

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 11 Oct 2006 22:03:51 +0200

On 11-okt-2006, at 22:32, Curtis Villamizar wrote:

> How the protocol encodes an atribute does not impact how that
> attribute is displayed in the CLI and therefore how or whether an RE
> syntax could be used in policy statements.

I don't understand how these statements relate to the discussion at  
hand.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Oct 2006 17:04:15 -0400

In message <[email-masked]>
> I don't understand how these statements relate to the discussion at  

You are right - type first think later is a bad idea.  In any case it
is fine to represent AS as big decimal numbers since there is no real
need to run RE over an adjacent set of numbers in policy statements or
sets of numbers with common values in the top part.  Adding a dot or
colon might upset some REs in existing policy.

Curtis

---

From: Vince Fuller <[email-masked]>
Date: Wed, 11 Oct 2006 14:10:00 -0700

> seems to prefer the representation of two 16-bit values separated by  

That's because a convention has evolved to structure the community as two
16-bit values, with specific semantic meanings attached to them.

Similarly, the dotted-quad notation for IP addresses once made sense because
class-A/B/C networks assigned structure to the octets.

IMHO, displaying 32-bit ASNs as "x.y" would be a mistake as it would imply
that some structure exists.

	--Vince

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Oct 2006 16:32:55 -0400

In message <[email-masked]>

How the protocol encodes an atribute does not impact how that
attribute is displayed in the CLI and therefore how or whether an RE
syntax could be used in policy statements.  For example, there are no
dots in the encoding of an IP address nor is there a slash before the
prefix length and there are no spaces between AS numbers or square
brackets around AS sets in the protocol encoding.

Curtis

---

From: Joe Abley <[email-masked]>
Date: Thu, 12 Oct 2006 13:23:25 -0400

On 11-Oct-2006, at 08:41, Iljitsch van Beijnum wrote:

> Note that there is significant resistance to this on the NANOG  
> list, and although this resistance is criticized, nobody is  
> actually speaking up in favor of the draft under consideration.

This was also my observation.

I don't believe I have heard a convincing argument as to why  
HHHH.LLLL is a useful representation, and I've heard plausible  
concern that it is a bad idea.

The overwhelming feedback I heard in St Louis (as well as on the  
list) was that a simple decimal representation of the 32-bit quantity  
was the preferred notation. I have heard nobody point out any  
concerns with that approach.

Regardless of which notation is chosen, it still seems useful to have  
the canonical representation documented.

Joe