Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

Jeffrey Haas <jhaas@pfrc.org> Wed, 21 September 2016 18:19 UTC

Return-Path: <jhaas@pfrc.org>
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 F03F312B71F for <idr@ietfa.amsl.com>; Wed, 21 Sep 2016 11:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.217
X-Spam-Level:
X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.316, 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 qoVgiRmIGLLT for <idr@ietfa.amsl.com>; Wed, 21 Sep 2016 11:19:08 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9916612B8D6 for <idr@ietf.org>; Wed, 21 Sep 2016 11:19:08 -0700 (PDT)
Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 66D3E1E332; Wed, 21 Sep 2016 14:20:33 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD0B76A7-3F94-48D0-AA67-7EBA6B7F19D6"
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <7A2A0295-D838-47F0-99E8-9A8796356452@puck.nether.net>
Date: Wed, 21 Sep 2016 14:19:07 -0400
Message-Id: <543A3E32-58E2-435D-91C7-9F86BD3E3294@pfrc.org>
References: <CA+b+ERm82jJPzHJGgmwKWY-T+q97D8tRUWW3rh6hYr3iV4BKag@mail.gmail.com> <D0E1DDA5-2C26-46A2-95BC-C7A7B19F2F8B@steffann.nl> <20160914161526.GA19429@puck.nether.net> <20160914162702.GC80448@shrubbery.net> <20160914162919.GD19429@puck.nether.net> <123D938E-E345-4572-84A4-377669A8F6FD@alcatel-lucent.com> <D56CA059-56AC-48A6-B832-177A637F0CC4@puck.nether.net> <CA+b+ERm4gm9FctgaAYyC=rr51EX=Pzsd-4+gef1v=VpkqXYwQg@mail.gmail.com> <1BC163F0-3D87-41D2-99F8-03B3F9FFD756@puck.nether.net> <CA+b+ER=wz=8EMrOusBT+EZjHECA_spER8=JQP3oUWWF65n6n5w@mail.gmail.com> <20160921135930.GG1101@Vurt.local> <CA+b+ER=2eyB1T3JhPpvLivvZDyVE8-DT03-00gYWtZ7W_9F7Zg@mail.gmail.com> <28460172-3CD0-4601-A543-612FEE5FFB7E@puck.nether.net> <CA+b+ERnKBEp8=sfooZ+EgyGjVp8AcofjUsWfGA-xAm3dNq_vng@mail.gmail.com> <7A2A0295-D838-47F0-99E8-9A8796356452@puck.nether.net>
To: Jared Mauch <jared@puck.nether.net>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/PMovHd78XCYet3yYIw_pxLXvIdM>
Cc: John Heasley <heas@shrubbery.net>, "idr@ietf.org" <idr@ietf.org>, Sue Hares <shares@ndzh.com>, Robert Raszuk <robert@raszuk.net>
Subject: Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)
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, 21 Sep 2016 18:19:10 -0000

> On Sep 21, 2016, at 10:50 AM, Jared Mauch <jared@puck.nether.net> wrote:
> 
>> Yet in few more cases there is evidence for the need of 4:4:4:4:1 or :2 and as indicated 4:4:4:4:16+1 would allow to use IPv6 prefix ... Likewise Jeff mentioned his customers asking him for RFC5701 to embed text. 
> 
> I take Jeff at his word and face value that people want these attributes attached to their routes.  I’m expecting to see a regex engine for this as well, which is other large work.

The existing engine is sufficient, but not optimal, for such work.  And is being used exactly this way for existing 1997 style communities.

There had been discussion along the lines of an extended mechanism to permit the same matching on positional character tokens with underlying map actions.  Readily doable.  Just have to force it over product management mountain.

But the extended version of that discussion became why force things down to an ascii mapping - why not hex? And once hex, why not bit-ranges?  And thus leads to the ipv6 conversation which are natively represented in hex anyway.

And eventually leads down the discussion of if you're going to do all of that range mapping... why not just make it a first order of the feature.

-- Jeff (because knowing that the 3rd digit with a value of 5 is Europe is totally intuitive..)