Re: [Idr] WG Last Call on Proposed IANA procedures for BGP Well-known communities

Jeffrey Haas <jhaas@pfrc.org> Tue, 12 August 2008 02:07 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9843A6D0F; Mon, 11 Aug 2008 19:07:47 -0700 (PDT)
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 724263A6E04 for <idr@core3.amsl.com>; Mon, 11 Aug 2008 19:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.776
X-Spam-Level:
X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334]
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 ktHZdGHQLu4i for <idr@core3.amsl.com>; Mon, 11 Aug 2008 19:07:45 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id B7C743A68E1 for <idr@ietf.org>; Mon, 11 Aug 2008 19:07:45 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 17BDB244050; Tue, 12 Aug 2008 02:07:46 +0000 (UTC)
Date: Mon, 11 Aug 2008 22:07:46 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Brian Dickson <briand@ca.afilias.info>
Message-ID: <20080812020745.GA13583@slice>
References: <200808071424.m77EO8u88925@magenta.juniper.net> <48A0505C.7030802@ca.afilias.info>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <48A0505C.7030802@ca.afilias.info>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
Cc: idr@ietf.org
Subject: Re: [Idr] WG Last Call on Proposed IANA procedures for BGP Well-known communities
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Brian,

On Mon, Aug 11, 2008 at 10:44:44AM -0400, Brian Dickson wrote:
> However, I *strongly* feel that it would be inappropriate to foreclose the 
> ability to establish new
> communities whose characteristics need to correspond to those of the 
> already-established well-known
> communities.

[And you elaborate on that.]

I'll point out again that "well-known" has wording similarities going
back to the base BGP RFC.  We don't expect any more "well known" path
attributes to pop up.  Matter of fact, it'd be a protocol violation for
them to occur.

Well known communities similarly imply pervasive deployment.  Anything
"new" is unlikely to be pervasive for years to come.  If you're really
lucky, it's possible to similate the behavior of a new "well known"
community via configuration.  One should not count on this.

This isn't to say that new communities will not be standardized with
pervasive deployment in years to come.  Consider the examples of route
reflection and confederations.  You will unlikely encounter anything
beyond a toy BGP implementation that doesn't have these features
implemented and yet they're not necessarily "required" by the BGP
standards.

I continue to object to the labeling of newer communities as "well
known" since they won't meet the "pervasive test".  That won't stop
communities assigned by the other means from being "pervasively
deployed" over their lifetime.  

One could even use the vendor litmus test as "important enough to get
assigned via working group consensus."

-- Jeff
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr