Re: [Idr] Proposed IANA procedures for BGP Well-known communities

David Ward <dward@cisco.com> Thu, 17 July 2008 20:25 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 0928E3A67FC; Thu, 17 Jul 2008 13:25:42 -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 7AB613A67FC for <idr@core3.amsl.com>; Thu, 17 Jul 2008 13:25:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.37
X-Spam-Level:
X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 oJt2CabsruQW for <idr@core3.amsl.com>; Thu, 17 Jul 2008 13:25:39 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 59BE53A63D2 for <idr@ietf.org>; Thu, 17 Jul 2008 13:25:39 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,205,1215388800"; d="scan'208";a="14609815"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Jul 2008 20:26:10 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6HKQAxl003166; Thu, 17 Jul 2008 16:26:10 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6HKQAS3012556; Thu, 17 Jul 2008 20:26:10 GMT
Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 16:26:10 -0400
Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 16:25:14 -0400
In-Reply-To: <0D6A70C961EC4DD9A18857956E977E36@ad.redback.com>
References: <12433A6D-95F0-46B6-89C1-EEC6D425823C@cisco.com><20080717024718.GB21614@slice> <7814BA97-5E24-400D-95FD-6B6C97F1C239@cisco.com> <0D6A70C961EC4DD9A18857956E977E36@ad.redback.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Message-Id: <165BD300-DCB5-4BD9-8CF8-67177302C5FE@cisco.com>
From: David Ward <dward@cisco.com>
Date: Thu, 17 Jul 2008 15:25:00 -0500
To: tony.li@tony.li
X-Mailer: Apple Mail (2.753.1)
X-OriginalArrivalTime: 17 Jul 2008 20:25:14.0253 (UTC) FILETIME=[382A0BD0:01C8E84B]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2481; t=1216326370; x=1217190370; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20<dward@cisco.com> |Subject:=20Re=3A=20[Idr]=20Proposed=20IANA=20procedures=20 for=20BGP=20Well-known=20communities |Sender:=20 |To:=20tony.li@tony.li; bh=SMihL3Z874ScqAikoZwBdaZsH2x1cMPl5FEoLShs/pE=; b=DRFUvTfb0yb0rKN5u1N7dERZ8qvtsyly4lw9Yi/W3OGAmyc6NioFpkiPlJ r1/WtDuCSbMPSo8/Z4iJ+TZRcWVMxZB0rkZ0O4cDoZnZpgZh5oPVO43puNkv OiMLCNsVHC;
Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: 'idr' <idr@ietf.org>, David Ward <dward@cisco.com>
Subject: Re: [Idr] 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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Tony -

I don't think that it is entirely procedural given the semantics of  
the well-known set. Rephrasing ...

point 1: The only well-known communities are those specified in 1997  
as they are old enough and widely deployed to the point that they are  
considered part of the foundation of BGP communities support.

point 2: calling any extensions to that subset (e.g. "ACCEPT_OWN")   
as well-known isn't appropriate as there is no guarantee of ubiquity  
of support

Issue: we know that we want to be able to add to the reserved set of  
values

If we care about the deployment ubiquity  of those titled "well- 
known" vs "allocated." Do we need a mechanism to signal that  
standardized communities are supported? Config mechanisms? Options  
include:

- dyn cap for each new value = painful signaling for each
- notion of "sets of allocated comms" that can have dyn cap for each  
set (insert issue of defn of the set) = move the problem to tomorrow
- required installation of configuration on devices for "identifying"  
comms until a version of SW can be loaded that supports the allocated  
comms
- do nothing and apply hope that an operator knows what they are doing

I prefer not to get caught in a chicken-egg situation of the  
semantics of "well-known" vs "allocated." There is clear precedence  
of being able to extend allocations of bits, flags, opaque_ids, etc  
and have incremental deployment.

-DWard

On Jul 17, 2008, at 3:09 PM, Tony Li wrote:

>
> Dave,
>
> My concern is related and is perhaps entirely procedural.  If a  
> "well-known"
> community is supposed to have universal support and given that we  
> already
> have implementations in the field, how can any new community (or  
> for that
> matter, path attribute) truly become "well-known"?  We have to  
> assume that
> there will always be at least one box in the field that will not  
> support it.
>
> Further, if it's not practical to add to the set of "well-known"
> communities, is there really a reason to have an IANA registry for  
> that
> subset?
>
> Regards,
> Tony
>
>
> |>> Well-known Communities
> |>>
> |>>    The following communities have global significance and their
> |>>    operations shall be implemented in any community-attribute-
> |>> aware  BGP
> |>>    speaker.
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

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