Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 13 October 2016 23:15 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 C979812956A for <idr@ietfa.amsl.com>; Thu, 13 Oct 2016 16:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HQgAk6czFmS5 for <idr@ietfa.amsl.com>; Thu, 13 Oct 2016 16:15:52 -0700 (PDT)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65124129471 for <idr@ietf.org>; Thu, 13 Oct 2016 16:15:52 -0700 (PDT)
Received: by mail-lf0-x22e.google.com with SMTP id b75so160402927lfg.3 for <idr@ietf.org>; Thu, 13 Oct 2016 16:15:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ii09ni5J9eIF/vLbuIrYXUtLyGxAcGeecbTP597hzrI=; b=hHT5mjEyghKYOUGJhCIo7kyiD8B6xvcETjFxPoOTAXcaB/puG3QTfZ5SDSo7RaeF8A mMSLBHxRUmoi0gZZRl+1y0/ZglzRCqptQGlqIogcVFWyqWlvmXvAFZoXDPiFo7dyqNk6 atS/I4GLzPDVqB20FSieDV7bbbm8jyl0oNrPeCkYwBUb7ehdLq1iMZc086b0zOQDmxfe OnpcL7VOzrnVC3kLTMnkcEIknWcx/5DaSW1POQNNBk9Dw2pSgPl7yp9ZqMr1mnTNt0D0 Ku7lK7fw2yEA+XPLEeMeyXYnlOhHdfcCXnrvur59fH9xce8AWIEtno1oI8Sr331qtQjh IKEg==
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=Ii09ni5J9eIF/vLbuIrYXUtLyGxAcGeecbTP597hzrI=; b=Mf/utboDa0zzQnMxbK/zAD9xpP5bubb1mnYd1ZJka+SzqV06wO/0neYEqdWPtbrEiv XO6EeL8aVh1bzIcKZMNzXr2VCWLLbqGAwiG9Xu8ViKSaR3kRzn5Oa1LCa+XK/mlEIcTf E6V6v+fwzQcT7UfjIp+trZbKrtpN2A6hos/Ex6iZTMTxQqMSzVjfgG8cUWCrh+tAI6fr Uwm8fxoMSuTxP7VpTlWCnwQXf0xNWTGwLydRWBdYZ6r+RMpKxkGJDpBTYKfGRgdf04Am r/KEQWUH0gibWYHkzgINaove6cc/3FcihRl7+ztkdMNzi+MVCcm+pyvn6xFPYLwGCQjc Opyg==
X-Gm-Message-State: AA6/9RmyvuFy0ilt8BGsliY11LC/Fs1wrtuDDItBwwiqY0cpSkgcpAUvVd21AyMS8hdcBr3JdVqKFeMwTQs9rw==
X-Received: by 10.194.93.234 with SMTP id cx10mr95899wjb.140.1476400550618; Thu, 13 Oct 2016 16:15:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.203.207 with HTTP; Thu, 13 Oct 2016 16:15:49 -0700 (PDT)
In-Reply-To: <20161013141343.GH22695@pfrc.org>
References: <A9BBA442-361F-444F-9AFC-33FAAF5F6061@gmail.com> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <57FCC876.5090109@foobar.org> <52AF3F60-BC0F-44AC-89D7-8E108617162F@pfrc.org> <552160CC-1000-42B1-95E3-6F6B9E1DC2F8@gmail.com> <20161011221544.GG12806@shrubbery.net> <20161012134552.GE22695@pfrc.org> <20161012215623.GH45879@shrubbery.net> <20161013141343.GH22695@pfrc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 13 Oct 2016 16:15:49 -0700
Message-ID: <CAH1iCioV2N9jcTArkF=2b_TULim=qO2-2h3tx2D6_nYcZXMz9g@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: multipart/alternative; boundary="047d7beb93405daf1f053ec74a9c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mZek0_Fmy2ldZD94D3sOG2HIVhg>
Cc: heasley <heas@shrubbery.net>, idr <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt
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, 13 Oct 2016 23:15:55 -0000

On Thu, Oct 13, 2016 at 7:13 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> On Wed, Oct 12, 2016 at 09:56:23PM +0000, heasley wrote:
> > Wed, Oct 12, 2016 at 09:45:52AM -0400, Jeffrey Haas:
> > > Arguably this was one of the motivations for doing scoping of
> attributes or
> > > communities themselves: If the effective operational behavior is almost
> > > always going to be AS-non-transitive, it'd be nice if the cleanup just
> > > happens automagically.  Unfortunately people are rather enamored with
> their
> > > existing cleanup mechanisms.
> >
> > Please, no automatic clean-up.  A community may be 100% legitimately used
> > to affect a decision 2 or 3 AS-hops away and it is extremely useful.
> > Operators already know how to alter communities.
>
> Experience has shown that a lot of people are simply bad about cleaning up
> their trash.  (And also how it was found that some particular bit of code
> had a hash table poorly sized...)
>

I think we actually need a straw-man here, upon which to hang the argument
(pro vs con on clean-up).

IMHO, any ASN that falls outside of the ranges that are "Reserved" or
"Private Use", should be excluded from clean-up.

The flip side to that is having "MUST" to give operators the ability to
protect their ASN-space from accidental or deliberate collisions.

However, I am willing to concede that Private ASN values should only be
propagated one AS-hop (where an entire Federation is one AS-hop).

Is it the case that the implementors in this discussion were specifically
thinking of applying the "intelligent clean-up" to ONLY the Private ASN
ranges?

(A simple Yes or No would be extremely helpful for bringing this discussion
to a close, IMNSHO.)



> But whether "doing better" comes via protocol changes, or getting better
> common practices embedded in running (policy) code is a longer
> conversation.
>

I think articulating the specific values of "better" would help move the
conversation in a productive direction. I am as much to blame here as
anyone :-).

Brian