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

Brian Dickson <briand@ca.afilias.info> Thu, 17 July 2008 20: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 077893A67F8; Thu, 17 Jul 2008 13:38:51 -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 5890B3A67F8 for <idr@core3.amsl.com>; Thu, 17 Jul 2008 13:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 TXmru6k0-57V for <idr@core3.amsl.com>; Thu, 17 Jul 2008 13:38:49 -0700 (PDT)
Received: from vgateway.libertyrms.info (vgateway.libertyrms.info [207.219.45.62]) by core3.amsl.com (Postfix) with ESMTP id 4CA723A63D2 for <idr@ietf.org>; Thu, 17 Jul 2008 13:38:49 -0700 (PDT)
Received: from wormhole-ddwrt.int.libertyrms.com ([10.1.2.190] helo=briandmacbook.local) by vgateway.libertyrms.info with esmtp (Exim 4.22) id 1KJaFw-0005B3-Km; Thu, 17 Jul 2008 16:39:16 -0400
Message-ID: <487FADE8.2030500@ca.afilias.info>
Date: Thu, 17 Jul 2008 16:39:04 -0400
From: Brian Dickson <briand@ca.afilias.info>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: David Ward <dward@cisco.com>
References: <12433A6D-95F0-46B6-89C1-EEC6D425823C@cisco.com><20080717024718.GB21614@slice> <7814BA97-5E24-400D-95FD-6B6C97F1C239@cisco.com> <0D6A70C961EC4DD9A18857956E977E36@ad.redback.com> <165BD300-DCB5-4BD9-8CF8-67177302C5FE@cisco.com>
In-Reply-To: <165BD300-DCB5-4BD9-8CF8-67177302C5FE@cisco.com>
X-SA-Exim-Mail-From: briand@ca.afilias.info
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Cc: 'idr' <idr@ietf.org>, tony.li@tony.li
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"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

David Ward wrote:
> 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.
>

I think that this can be handled, by analogy, by the status of the RFCs 
which cause new "well-known" communities to be allocated.

We have, in theory, a maturity level on standards-track RFCs, which can 
include:
Individual ID submission
WG ID
Proposed Standard
Draft Standard
Standard

I would submit that once a community's RFC-of-origin reaches DS, that it 
can be called "well-known".
Prior to that, perhaps some other term could apply, such as 
"soon-to-be-well-known community"?

I definitely am of the opinion that there is room for new well-known 
communities, and that, as such, the IANA registry makes a lot of sense.

I don't think how often we expect to expand the set, so long as we 
contemplate expanding it, it needs a registry.

If we intend on closing off the set at some point, we should do so in a 
standards-based manner, with a new RFC that memorializes the complete 
set, and terminates the IANA registry, all in one fell swoop, including 
text that reads "updates and obsoletes RFC 1997 (et al)".

Brian

P.S. Don't let the fact that I have an ID I'm presenting in Dublin, 
about just such a community, color your judgment on my opinion on this, 
please. :-)

> 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?
[...]
>
> - 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.
>>
>> 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?

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