IETF Logo Mail Archive

Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

Jeffrey Haas <jhaas@pfrc.org> Wed, 19 October 2016 18:20 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467B21294D2 for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 11:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level:
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtX3HsiCShfe for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 11:20:54 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EA487126FDC for <idr@ietf.org>; Wed, 19 Oct 2016 11:20:53 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 051C81E1F0; Wed, 19 Oct 2016 14:23:03 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4BD346EF-8DAF-4286-8747-0D6A8016081F"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CAN-Dau1dx_4o4yV=ytR-mFL1noLtGLKAZE3D_9mP5xxhSM=v_Q@mail.gmail.com>
Date: Wed, 19 Oct 2016 14:20:52 -0400
Message-Id: <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <CAN-Dau1dx_4o4yV=ytR-mFL1noLtGLKAZE3D_9mP5xxhSM=v_Q@mail.gmail.com>
To: David Farmer <farmer@umn.edu>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/zvr-I1owzRY4pPiPplmy8VEqvgE>
Cc: IETF IDR WG <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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>
X-List-Received-Date: Wed, 19 Oct 2016 18:20:55 -0000

> On Oct 19, 2016, at 2:12 PM, David Farmer <farmer@umn.edu> wrote:
> 
> I believe this is ready to go and support it's publication as-is.  However, I believe it would be improved with the addition of something like the following paragraph;
> 
>    While from a BGP protocol perspective it is necessary for large communities to be 
>    transitive, as there are many plausible situation where large communities need to 
>    be used to signal beyond a singles or even directly adjacent Autonomous Systems.  
>    On other other hand, large communities are not necessarily intended to be passed 
>    unimpeded across the entirety of the Internet either. Therefore, implementations 
>    SHOULD provide a rich set of policy capabilities to allow operators to decide which 
>    large communities are received from or propagated to peers.
> 

FWIW, I'd rather see such a thing as part of a grow document for good community practices.

I had thought that a BCOP document on communities was out there for BGP communities in general, but "community" clutters the search engines quite a bit and I'm not finding such a thing.

-- Jeff

v2.23.0 | Report a Bug | By Email