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

[Iljitsch van Beijnum <iljitsch at muada.com>]

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

> 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.

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).

_______________________________________________
Idr mailing list
Idr at ietf.org
https://www1.ietf.org/mailman/listinfo/idr