Re: [Idr] community of the day - common header

Jared Mauch <jared@puck.nether.net> Fri, 09 September 2016 18:08 UTC

Return-Path: <jared@puck.nether.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 B5AA212B306 for <idr@ietfa.amsl.com>; Fri, 9 Sep 2016 11:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.71
X-Spam-Level:
X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, 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 NZveYWWM6JBM for <idr@ietfa.amsl.com>; Fri, 9 Sep 2016 11:07:58 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 09DE412B268 for <idr@ietf.org>; Fri, 9 Sep 2016 11:07:58 -0700 (PDT)
Received: from [IPv6:2601:401:4:3000:991e:457b:df1e:a04e] (unknown [IPv6:2601:401:4:3000:991e:457b:df1e:a04e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 59A425409EB; Fri, 9 Sep 2016 14:07:56 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <20160909170513.GE12105@pfrc.org>
Date: Fri, 09 Sep 2016 14:07:55 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <479C494A-0C06-4A27-AA39-C3C220DE3730@puck.nether.net>
References: <20160908214031.GA23544@pfrc.org> <20160908231840.GB16775@puck.nether.net> <20160909153317.GC8370@pfrc.org> <8C072797-55A7-4D1A-87E4-67551953EF22@puck.nether.net> <20160909155952.GE8370@pfrc.org> <20160909164640.GE79185@Space.Net> <20160909170513.GE12105@pfrc.org>
To: Jeffrey Haas <jhaas@pfrc.org>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LzavOzHXzy6bHT_gKMGiffIklIs>
Cc: idr@ietf.org
Subject: Re: [Idr] community of the day - common header
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: Fri, 09 Sep 2016 18:08:04 -0000

> On Sep 9, 2016, at 1:05 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> On Fri, Sep 09, 2016 at 06:46:40PM +0200, Gert Doering wrote:
>> Hi,
>> 
>> On Fri, Sep 09, 2016 at 11:59:53AM -0400, Jeffrey Haas wrote:
>>> As an operator, do you want to play long-term whack-a-mole with the
>>> attribute set of the week, worrying about whether something you filter today
>>> may need to get through later, or would you prefer we make that job easier
>>> but trying to move "color" into a common bucket?
>> 
>> I'd love to have something minimal ASAP, and the kitchen sink bucket thingie
>> can then take until I'm retired to materialize.
> 
> I suspect your 3 implementations in flight can add 64 bits of header on top
> of the existing code without too much headache.  They should already have
> transitivity checks in the code for extended communities they can lift.

I similarly speculate you are correct.

> And if those 3 implementations in flight ship on squatted code points
> without appropriate plans to change per IDR standardization, they've learned
> nothing about the foibles of what happens when you ship too early.

Honestly, I’ll take shipped in this case, but that is perhaps a topic for over
drinks in Seoul.  “Too early” here is flame bait, which may have been earned
but should not cloud the technical discussion.

I will say presuming that large is adopted by the WG (either with or without
the header as part of that draft or some other ..) this is near the top of
my list to discuss with my routing software and hardware suppliers next month.

- jared