Re: [Idr] draft-decraene-idr-reserved-extended-communities-00

Eric Rosen <erosen@cisco.com> Mon, 15 November 2010 19:36 UTC

Return-Path: <erosen@cisco.com>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DC633A6D06 for <idr@core3.amsl.com>; Mon, 15 Nov 2010 11:36:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGCnIWxtd9As for <idr@core3.amsl.com>; Mon, 15 Nov 2010 11:36:55 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 57D363A6CF4 for <idr@ietf.org>; Mon, 15 Nov 2010 11:36:55 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.59,201,1288569600"; d="scan'208";a="182221244"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Nov 2010 19:37:36 +0000
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAFJbavg028361; Mon, 15 Nov 2010 19:37:36 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id oAFJbZA8011857; Mon, 15 Nov 2010 14:37:35 -0500
To: bruno.decraene@orange-ftgroup.com
In-reply-to: Your message of Mon, 15 Nov 2010 19:05:26 +0100. <FE8F6A65A433A744964C65B6EDFDC24001A99167@ftrdmel0.rd.francetelecom.fr>
Date: Mon, 15 Nov 2010 14:37:35 -0500
Message-ID: <11856.1289849855@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
Cc: idr@ietf.org, erosen@cisco.com, draft-decraene-idr-reserved-extended-communities@tools.ietf.org
Subject: Re: [Idr] draft-decraene-idr-reserved-extended-communities-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: erosen@cisco.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2010 19:36:56 -0000

> Reserving 2^48 = 2.8 10^14 = two hundreds thousand billions communities
> while a single is required, I call this wasting resources.

The resource being wasted is the 2^48 potential values of the low order six
bytes of the extended community??  I.e., there are 2^48 values that could
have been used for codepoints but are instead going wasted?

How many codepoint values do you expect IANA to assign from this registry?
Even if they assign, say, a billion, the resource utilization will still be
pretty close to zero.

> We ran out of class B, AS number, IP addresses, optional parameter
> length... How can you be certain that we will never run out of extended
> types?

I don't think the proposed registry is a very good hedge against running out
of extended types, as it essentially creates an extended community that
consists of eight bytes of type field and zero bytes of value field.  If we
use up all the two-byte extended type values, we will probably still want
some value field bytes.

> if _you_ believe these are evil, you will be able to remove or not
> interpret them.

It's hard to imagine that all 2^48 codepoints will be evil.

> A registry for reserved/well known/std action community do exist. Do you
> have a concern with it?

Yes, I don't think it makes any sense to have a registry for communities
that "have global significance and their operations shall be implemented in
any community-attribute-aware BGP speaker"; obviously one can't allocate a
new codepoint from that registry without throwing all existing
implementations out of compliance.