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

In message <BFA41ABC-06EE-4ABF-99B4-49B6FBA58865@muada.com>
Iljitsch van Beijnum writes:
>  
> 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).

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

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