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
- [Idr] Last Call: 'Canonical representation of 4-b… The IESG
- [Idr] Re: Last Call: 'Canonical representation of… John Leslie
- Re: [Idr] Re: Last Call: 'Canonical representatio… Joe Abley
- Re: [Idr] Re: Last Call: 'Canonical representatio… Scott Leibrand
- Re: [Idr] Re: Last Call: 'Canonical representatio… Bill Fenner
- RE: [Idr] Re: Last Call: 'Canonical representatio… Bruno Rijsman
- Re: [Idr] Re: Last Call: 'Canonical representatio… Joe Abley
- Re: [Idr] Re: Last Call: 'Canonical representatio… Geoff Huston
- Re: [Idr] Last Call: 'Canonical representation of… John G. Scudder
- Re: [Idr] Last Call: 'Canonical representation of… Iljitsch van Beijnum
- Re: [Idr] Last Call: 'Canonical representation of… Iljitsch van Beijnum
- Re: [Idr] Last Call: 'Canonical representation of… Curtis Villamizar
- Re: [Idr] Re: Last Call: 'Canonical representatio… Vince Fuller
- Re: [Idr] Last Call: 'Canonical representation of… Curtis Villamizar
- Re: [Idr] Last Call: 'Canonical representation of… Joe Abley