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

David Ward <dward@cisco.com> Tue, 29 July 2008 17:45 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 9B2763A6AA3; Tue, 29 Jul 2008 10:45:35 -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 8204D3A67EF for <idr@core3.amsl.com>; Tue, 29 Jul 2008 10:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.439
X-Spam-Level:
X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 QC4NbVfxzCNZ for <idr@core3.amsl.com>; Tue, 29 Jul 2008 10:45:28 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4D17F3A6942 for <idr@ietf.org>; Tue, 29 Jul 2008 10:45:22 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,273,1215388800"; d="scan'208";a="39134918"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 29 Jul 2008 17:45:35 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m6THjZpg001605; Tue, 29 Jul 2008 10:45:35 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m6THjOio005473; Tue, 29 Jul 2008 17:45:35 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); Tue, 29 Jul 2008 13:45:33 -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); Tue, 29 Jul 2008 13:45:32 -0400
In-Reply-To: <12433A6D-95F0-46B6-89C1-EEC6D425823C@cisco.com>
References: <12433A6D-95F0-46B6-89C1-EEC6D425823C@cisco.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Message-Id: <3980AE3D-A9C1-4F82-96EC-53440FA6EA3E@cisco.com>
From: David Ward <dward@cisco.com>
Date: Tue, 29 Jul 2008 12:45:28 -0500
To: David Ward <dward@cisco.com>
X-Mailer: Apple Mail (2.753.1)
X-OriginalArrivalTime: 29 Jul 2008 17:45:32.0827 (UTC) FILETIME=[E62576B0:01C8F1A2]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4945; t=1217353535; x=1218217535; c=relaxed/simple; s=sjdkim4002; 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=20Proposed=20IANA=20procedures=20for=20BG P=20Well-known=20communities |Sender:=20; bh=bjyJtYu2/0djMSGnQ+f9TI7Z9i++DgLA5BGbw34pwsg=; b=lbKnuGnPjWKxlYv/tkvgiwnj0DY23CaEDdrQ+nqxcIQRtE1WVgvmT5LacB ixpQCZYr9081YnLy2N2zEVCInGIs0HikcDs1Jp0hlMMuMeAKfDvK1ZMmTikV zzLUR7cAFB;
Authentication-Results: sj-dkim-4; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: idr <idr@ietf.org>, shares@ghs.com, Yakov Rekhter <yakov@juniper.net>
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

All -

I'll fire this off again so that folks have context for the  
discussion in IDR today and we can try to get consensus. The proposal  
is to effectively end the notion of allocating "well-known  
communities" and have "reserved code space." The well-known  
communities we have today are what we get. The claim is that given  
the state of the internet today, we are unable to determine when  
something is ubiquitously "well-known."

Please discuss as we will have no allocation of well-known or  
reserved BGP communities until some procedures have reached WG  
consensus. If it is felt that we must maintain "well-known  
communities," a reliable and guaranteed algorithm as to when a  
community is ubiquitously deployed has to be given otherwise we are  
simply stuck w/ the notion of "reserved."

Thanks

-DWard

On Jul 16, 2008, at 9:37 PM, David Ward wrote:

> All -
>
> 	The IDR WG chairs and and Routing ADs  were requested by IANA to  
> clear up the lack of registration procedures for BGP communities  
> specified in RFC 1997.
>
> This registry exists;
>
> http://www.iana.org/assignments/bgp-well-known-communities
>
> but, there is no specified way to reserve new well-known- 
> communities. Here is the relevant quotation from RFC 1997:
>
> "COMMUNITIES attribute
>
>    This document creates the COMMUNITIES path attribute is an optional
>    transitive attribute of variable length.  The attribute consists  
> of a
>    set of four octet values, each of which specify a community.  All
>    routes with this attribute belong to the communities listed in the
>    attribute.
>
>    The COMMUNITIES attribute has Type Code 8.
>
>    Communities are treated as 32 bit values,  however for   
> administrative
>    assignment,  the following presumptions may be made:
>
>    The community attribute values ranging from 0x0000000 through
>    0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.
>
>    The rest of the community attribute values shall be encoded  
> using an
>    autonomous system number in the first two octets.  The semantics of
>    the final two octets may be defined by the autonomous system  
> (e.g. AS
>    690 may define research, educational and commercial community  
> values
>    that may be used for policy routing as defined by the operators of
>    that AS using community attribute values 0x02B20000 through
>    0x02B2FFFF).
>
> Well-known Communities
>
>    The following communities have global significance and their
>    operations shall be implemented in any community-attribute- 
> aware  BGP
>    speaker.
>
>       NO_EXPORT (0xFFFFFF01)
>          All routes received carrying a communities attribute
>          containing this value MUST NOT be advertised outside a BGP
>          confederation boundary (a stand-alone autonomous system that
>          is not part of a confederation should be considered a
>          confederation itself).
>       NO_ADVERTISE (0xFFFFFF02)
>          All routes received carrying a communities attribute
>          containing this value MUST NOT be advertised to other BGP
>          peers.
>       NO_EXPORT_SUBCONFED (0xFFFFFF03)
>          All routes received carrying a communities attribute
>          containing this value MUST NOT be advertised to external BGP
>          peers (this includes peers in other members autonomous
>          systems inside a BGP confederation).
> "
>
>
> I am proposing a 50/50 split of the upper range of currently  
> reserved space between the "First Come First Served" policy defined  
> in RFC 2434 and those assigned by IANA using  either the Standards  
> Action process defined in RFC 2434, or the Early IANA Allocation  
> process defined in RFC 4020.
>
> Here is the definition of the space:
>
> 0x0000000-0x0000FFFF                                                 R 
> eserved
> 0xFFFFFF01         NO_EXPORT                                      
> [RFC1997]
> 0xFFFFFF02         NO_ADVERTISE                                
> [RFC1997]
> 0xFFFFFF03         NO_EXPORT_SUBCONFED          [RFC1997]
> 0xFFFFFF04          
> NOPEER                                             [RFC3765]
> 0xFFFF0000-0xFFFFFFFF                                                
> Reserved
>
> Proposal of redefinition of space:
>
> 0xFFFF0000-0xFFFF8000 = FCFS
> 0xFFFF8001-0xFFFFFFFF = IANA Assigned
>
>
> Note: The first 65535 comms remain reserved (0x0000000-0x0000FFFF).
>
> Note1: there is a proposal in draft-pmohapat-idr-acceptown- 
> community-01.txt that proposes that 0xFFFFFF05 be "ACCEPT_OWN."  
> This request would follow the 50/50 split proposal if the draft is  
> standardized.
>
>
> I'll hopefully explain it in 3 mins or less at the IDR meeting at  
> IETF72 so that we can give some procedures to IANA.
>
> Please discuss now....
>
> -DWard
>
>
>
>
>

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