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

David Ward <dward@cisco.com> Thu, 17 July 2008 02:38 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 B73153A6A05; Wed, 16 Jul 2008 19:38:12 -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 B28D53A69FF for <idr@core3.amsl.com>; Wed, 16 Jul 2008 19:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.329
X-Spam-Level:
X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 ednTzRff7VEv for <idr@core3.amsl.com>; Wed, 16 Jul 2008 19:38:10 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 847DD3A69CD for <idr@ietf.org>; Wed, 16 Jul 2008 19:38:10 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,200,1215388800"; d="scan'208";a="14547578"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 17 Jul 2008 02:38:40 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m6H2ceON031225; Wed, 16 Jul 2008 22:38:40 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6H2ceew005157; Thu, 17 Jul 2008 02:38:40 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); Wed, 16 Jul 2008 22:38:40 -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); Wed, 16 Jul 2008 22:37:43 -0400
Mime-Version: 1.0 (Apple Message framework v753.1)
Message-Id: <12433A6D-95F0-46B6-89C1-EEC6D425823C@cisco.com>
From: David Ward <dward@cisco.com>
Date: Wed, 16 Jul 2008 21:37:33 -0500
To: idr <idr@ietf.org>
X-Mailer: Apple Mail (2.753.1)
X-OriginalArrivalTime: 17 Jul 2008 02:37:43.0688 (UTC) FILETIME=[170D7080:01C8E7B6]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3872; t=1216262320; x=1217126320; c=relaxed/simple; s=rtpdkim2001; 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:=20Proposed=20IANA=20procedures=20for=20BGP=20Well -known=20communities |Sender:=20 |To:=20idr=20<idr@ietf.org>; bh=BMWWbj8UHsvuij7Ym/mJl5ugB325cfPvotPg9ZByloE=; b=kjgYqhGA7JqyGcmcdfkSAjXoLFrkMiy4fCjHpabG5Rv2c0VRfJUUNEZP4X 8UrJdhi5QqMPWyTbtcSSIBylg+E9DfFzUP7GA6PQdR9DDk3uiAA7SX5+hzUv rBQbsYeDLH;
Authentication-Results: rtp-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Cc: David Ward <dward@cisco.com>
Subject: [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 -

	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                                                  
Reserved
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