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
- [Idr] Proposed IANA procedures for BGP Well-known… David Ward
- Re: [Idr] Proposed IANA procedures for BGP Well-k… Jeffrey Haas
- Re: [Idr] Proposed IANA procedures for BGP Well-k… David Ward
- Re: [Idr] Proposed IANA procedures for BGP Well-k… Jeffrey Haas
- Re: [Idr] Proposed IANA procedures for BGP Well-k… Tony Li
- Re: [Idr] Proposed IANA procedures for BGP Well-k… David Ward
- Re: [Idr] Proposed IANA procedures for BGP Well-k… Brian Dickson
- Re: [Idr] Proposed IANA procedures for BGP Well-k… Jeffrey Haas
- Re: [Idr] Proposed IANA procedures for BGP Well-k… David Ward
- Re: [Idr] Proposed IANA procedures for BGP Well-k… Danny McPherson