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

Job Snijders <job@ntt.net> Thu, 20 October 2016 15:49 UTC

Return-Path: <job@ntt.net>
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 032B8129975 for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 08:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level:
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.431, SPF_SOFTFAIL=0.665] 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 zu34TN1_CdW2 for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 08:48:59 -0700 (PDT)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0DF12964B for <idr@ietf.org>; Thu, 20 Oct 2016 08:48:59 -0700 (PDT)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1bxFaS-000Boc-HG (job@us.ntt.net); Thu, 20 Oct 2016 15:48:58 +0000
Date: Thu, 20 Oct 2016 10:48:47 -0500
From: Job Snijders <job@ntt.net>
To: David Farmer <farmer@umn.edu>
Message-ID: <20161020154847.GU1033@Vurt.local>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <CAN-Dau1dx_4o4yV=ytR-mFL1noLtGLKAZE3D_9mP5xxhSM=v_Q@mail.gmail.com> <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org> <5807ED30.30204@foobar.org> <CAN-Dau3cXE50aLmSXpuJHcZ9t+itmhicmD4E53W4aDm4592OJw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAN-Dau3cXE50aLmSXpuJHcZ9t+itmhicmD4E53W4aDm4592OJw@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.0 (2016-08-17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/NXaVoHSwPNOIMFXt0-EINwFYgJA>
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: Thu, 20 Oct 2016 15:49:01 -0000

On Wed, Oct 19, 2016 at 05:34:37PM -0500, David Farmer wrote:
> On Wed, Oct 19, 2016 at 5:01 PM, Nick Hilliard <nick@foobar.org> wrote:
> > Jeffrey Haas wrote:
> > > 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.
> >
> > are you thinking of rfc7454?
> >
> > Dave's suggestion is definitely an operational- rather than a
> > protocol-level issue.  draft-ietf-idr-large-community is a protocol
> > definition, so it would be better to see this in a GROW document.
> 
> So it's slightly more than just the wire-protocol issues, it defines a
> Canonical Representation.  I think that's important, but I think it's
> equally important that to interoperability that implementations include
> policy tools.  I included some motivation for why the tools need to be
> included, but if you'd prefer to strip that out, I'd be fine with that. So
> that leaves something like this;
> 
>    Implementations SHOULD provide a rich set of policy capabilities to
>    allow operators to decide which large communities are received from
>    or propagated to peers.

This would be a statement without teeth. There are BGP implementations
where policy capabilities are not so relevant. I also consider it the
operator's job to negotiate with their vendors on what features are
available on a box.

The market self-corrects. Such text belongs in a commercial request for
proposal, not nessecarily in protocol specification.

Kind regards,

Job