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

Jared Mauch <jared@puck.nether.net> Fri, 09 September 2016 15:44 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 3409612B145 for <idr@ietfa.amsl.com>; Fri, 9 Sep 2016 08:44:18 -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 tgal1tsn_mCZ for <idr@ietfa.amsl.com>; Fri, 9 Sep 2016 08:44:16 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id DACA1127A91 for <idr@ietf.org>; Fri, 9 Sep 2016 08:44:16 -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 DA1525409F3; Fri, 9 Sep 2016 11:44:13 -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: <20160909153317.GC8370@pfrc.org>
Date: Fri, 09 Sep 2016 11:44:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C072797-55A7-4D1A-87E4-67551953EF22@puck.nether.net>
References: <20160908214031.GA23544@pfrc.org> <20160908231840.GB16775@puck.nether.net> <20160909153317.GC8370@pfrc.org>
To: Jeffrey Haas <jhaas@pfrc.org>
X-Mailer: Apple Mail (2.3226)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RZ-G6bLwevalXfPwkHG3bPcj2qE>
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 15:44:18 -0000

> On Sep 9, 2016, at 11:33 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> On Thu, Sep 08, 2016 at 07:18:40PM -0400, Jared Mauch wrote:
>> On Thu, Sep 08, 2016 at 05:40:31PM -0400, Jeffrey Haas wrote:
>>> - We shouldn't be burning path attributes for it.  While the code space for
>>>  it isn't being exhausted fast, it means the only way to discard
>>>  unparseable attributes (implementation doesn't support) is a general path
>>>  attribute filtering mechanism.  Such filtering mechanisms are hazardous to
>>>  the incremental deployment of new BGP features.
>> 
>> 	Is there a particular shortcoming in rfc7606 that creates this
>> [moral] hazard, or are you speaking of the difficulty of writing
>> the code as referenced below?
> 
> You cite the issue yourself below with the example of attr 128.  In the
> absence of any ability to parse the attribute, your choice is to blindly
> pass it along or to drop it.
> 
> We know these things are community-like.  Stick them under a common type and
> let people's policy engines filter them.

Sure, implementations compliant with 7606 should do
treat-as-withdrawl if they encounter something they
can recover from.

>> Any code received today will take me ~12 months to deploy.  If wide
>> communities is ready to WGLC and ship with 3.1, I'd like to see movement
>> immediately so we can test and plan accordingly.  ~6+ years is quite a
>> long gestation period for the IETF.
> 
> This thread isn't about wide communities.  Stop making it about that.

Well, is it about rate of consumption of attributes, any new
route coloring/community-type thing?  It’s clear from me watching
the live stream of operator events today account teams are going to face
a number of requests about implementation details.

Please don’t trim too much of my operational grouse here, we should seek
consensus on *something* without prescribing what it is, wide, jumbo,
skinny or otherwise.  We as operators need something, i’m less worried
about the wire encoding than a viable solution.

>> P.S. Jeff, lets get together in person next week if you have time.
> 
> I'm available, but at this point it's unclear if you can afford that much
> beer.

I’ll take on this challenge. :)  I’ll message you privately about details
and if you’re local to me, feel free to inquire as well.

- Jared