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

David Farmer <farmer@umn.edu> Wed, 19 October 2016 20:05 UTC

Return-Path: <farmer@umn.edu>
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 85A631296D1 for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 13:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Level:
X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu
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 h4aKu_J5lM_s for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 13:05:38 -0700 (PDT)
Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 126D2129476 for <idr@ietf.org>; Wed, 19 Oct 2016 13:05:38 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id B9C8A840 for <idr@ietf.org>; Wed, 19 Oct 2016 20:05:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at umn.edu
Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnSnbCEDUKY9 for <idr@ietf.org>; Wed, 19 Oct 2016 15:05:36 -0500 (CDT)
Received: from mail-qk0-f198.google.com (mail-qk0-f198.google.com [209.85.220.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 74DD45FD for <idr@ietf.org>; Wed, 19 Oct 2016 15:05:36 -0500 (CDT)
Received: by mail-qk0-f198.google.com with SMTP id z190so26725441qkc.4 for <idr@ietf.org>; Wed, 19 Oct 2016 13:05:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9NnkClMLRv+F+wCq5k0mFTZGUyk9+HcVg2gn9ce9jjQ=; b=PAtzRkenK3Z2fzfnq1GMfi7Nc6jR0pYiGuIsyDgiVezxQqRmyj1apq+Jr7ZfNlZQyj d5rxEJRq+m5tcEEPe7y8mm/wkw4qE/1VkC67vsYJMlJ3V9xkYGZNOANklMvMvvfzHjmc GOXlfMANMKEv3MYLRdLD4+Z2muHc6BObE4loZsMRIeJC1+ymyIdv1azMBsrCUwjtjH+W G58C6Du7dLc4lfOQY9R3Uuk/fyCp6GOMkEeeABtQTWyrn0FDXwhsDQQQARMufbG0fnST PESWJQd/nYcRsMz/UbrSxOX9Iygk+EqNYD5JB+gJuV/f+z6MS0PUI48ImljZQQvfIVWf OUkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9NnkClMLRv+F+wCq5k0mFTZGUyk9+HcVg2gn9ce9jjQ=; b=k6ZWLfcLEB3CIJvKmxpkAo+D18CcEEMVwIRA4LmESj6znqXvs9Q8QpnhD2S0F/M78l iXkX7Np82kksqk1wjkcurnWA/1bTxeR+iF1SFA/pp4AM5T6RycoryuVS2SmlTDnXyHbf 2ezb6V9K81Mz3u2Q0X0OREa+kMA2yrN43KPPpcCgkq9KH74Jnmk+/V1PEu4/QMprIvNT L7cQkVzp8z0NvotVNYt3AbS3IZJkf/IaM6onQAkbaVM55V/vzHML5+/kYwwVeCX95ze0 fPuSxxdivkkIL6mkif0p5TQl+zopn6K+E/5sdVWz8tiLBQvOeiFTNsgGt8S2mT6LuhNe PGXw==
X-Gm-Message-State: AA6/9Rm6EkFo4MztaMAlwKvtBMJxR4/EALbcal3PfBuBwSnu+TrIH/VUMvus+c37Wq+5LAjvzoaN9NG1wGDiQiNDbDHKF3gGRgp4G/QIHMNOZudT9mCN/pnIUprmHH4avJmIH6MHlxj1MchPfg==
X-Received: by 10.200.41.201 with SMTP id 9mr7706996qtt.138.1476907535811; Wed, 19 Oct 2016 13:05:35 -0700 (PDT)
X-Received: by 10.200.41.201 with SMTP id 9mr7706982qtt.138.1476907535608; Wed, 19 Oct 2016 13:05:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.41.230 with HTTP; Wed, 19 Oct 2016 13:05:34 -0700 (PDT)
In-Reply-To: <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <CAN-Dau1dx_4o4yV=ytR-mFL1noLtGLKAZE3D_9mP5xxhSM=v_Q@mail.gmail.com> <107141A7-5CD2-4E48-8F6C-C737FF370359@pfrc.org>
From: David Farmer <farmer@umn.edu>
Date: Wed, 19 Oct 2016 15:05:34 -0500
Message-ID: <CAN-Dau3WSWjj5kNt_nTeOW0ANuvBCgdBporafdiqg=JoEL9Zgg@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: multipart/alternative; boundary=001a1139743a06c449053f3d553d
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RnVHfecXKf10_sIs2fLAGKsROIQ>
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 20:05:39 -0000

My intent for this was to motivate why it's necessary for implementations
to include filtering policies in order to be complete, which I think is in
scope for this document. It's not intended to supplant a BCOP document,
which would talk about how to use the policies and need way more details
and examples.

On Wed, Oct 19, 2016 at 1:20 PM, Jeffrey Haas <jhaas@pfrc.org>; wrote:

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


-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================