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

Iljitsch van Beijnum <iljitsch@muada.com> Wed, 11 October 2006 12:58 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXdes-0006rZ-46; Wed, 11 Oct 2006 08:58:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXdeD-0006KN-Kq; Wed, 11 Oct 2006 08:57:21 -0400
Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXdPH-0000Am-PB; Wed, 11 Oct 2006 08:41:56 -0400
Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k9BCeQmN043883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Oct 2006 14:40:26 +0200 (CEST) (envelope-from iljitsch@muada.com)
In-Reply-To: <p06230916c151848c2527@[10.0.1.2]>
References: <E1GX06V-0006wb-4J@stiedprstage1.ietf.org> <p06230916c151848c2527@[10.0.1.2]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <BFA41ABC-06EE-4ABF-99B4-49B6FBA58865@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [Idr] Last Call: 'Canonical representation of 4-byte AS numbers' to Informational RFC (draft-michaelson-4byte-as-representation)
Date: Wed, 11 Oct 2006 14:41:45 +0200
To: "John G. Scudder" <jgs@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: idr@ietf.org, iesg@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

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@ietf.org
https://www1.ietf.org/mailman/listinfo/idr