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

Christopher Morrow <morrowc.lists@gmail.com> Wed, 21 September 2016 16:10 UTC

Return-Path: <christopher.morrow@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 A631612B566; Wed, 21 Sep 2016 09:10:08 -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 dbMWIpKFS7Jr; Wed, 21 Sep 2016 09:10:06 -0700 (PDT)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 DFBBF12B078; Wed, 21 Sep 2016 09:10:05 -0700 (PDT)
Received: by mail-qt0-x230.google.com with SMTP id 93so24708315qtg.2; Wed, 21 Sep 2016 09:10:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1ZI4zikvGb0GQhEFjatOqNwEJu0IHBJ6VpC+t1awfT8=; b=h6FeCLtf//z8pMJIVVbNPPUlDdcGkbs76IdH/ULDqcQ0dfC7Xe15viluB92pR3rnhD gwR9u8bNA+2gGH5kEzgf+7iseikg1MwjzXGS5Dzbm+QifbW2QDR9V7rkZvpJOxoYBeV2 StaGSyA/JRj55hBQHALyIjMJyssi9JFRWT5//iOw5GW9cwYaKluvUEsYvfzokkKjBB2E tY4Blp6TfCIsMUmPnMijIQoVs8JccHE8E/l8Pt7LjdQvGcJBMmDDhF0MPo0IqDrqyIsX LLssDWS8ZGXsTLq3YUnX3zx6c4d7qFjzahJGxWX+T4t6ldj9KzyUDSv08vW6MuDMdjd6 s+FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1ZI4zikvGb0GQhEFjatOqNwEJu0IHBJ6VpC+t1awfT8=; b=Agu+ZaftfvsODm/B01xCfITk7ANh0kb5oHVMd1az5iHSWpd4Bvx+Pzc9mQjXVevPI0 1E8NpDH5keqk83h/aLUS4/rcbUoAeosHRJ4jRfyyDgaJs8jvZvQo2Ry9XIwW20vZUbmF HYGxhayxBcRqgyhn1ZZh5t9qmoa8YtIxJeoVZ93wiETwjBYTomEzrH969Jtl0XqGHxUP QfsUQb66ogdVb894Apj2KdNCHvkTGaAORU0HBWV65MZ2eW0u6iEe0vFXeECT9sshdmvo 9gYXVeQMGh/mhOqKuPwC0BhhPAqDKc50aTkSENb6hG47gLxjgH/z10vTh/eC/XWQjXX0 H1Qg==
X-Gm-Message-State: AE9vXwPl8IqPzw32f2VLT9Yd881jeUN7s2TTmx8tHZRQLyhnMKukqPg0rQeXtzCi4ZdXaXWz98E182mv7nLJaQ==
X-Received: by 10.237.33.111 with SMTP id 102mr41729117qtc.56.1474474204976; Wed, 21 Sep 2016 09:10:04 -0700 (PDT)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.82.35 with HTTP; Wed, 21 Sep 2016 09:10:04 -0700 (PDT)
In-Reply-To: <CA+b+ERnL=RhivBFDERivrAFs73NA02Vr4ryHEEP3dOy-MtOu8A@mail.gmail.com>
References: <E7A5509A-4B20-44A9-9FBE-284734B5E2FD@cisco.com> <20160909155047.GD8370@pfrc.org> <CA+b+ERnyFi_0_rfW6F2uV8AGuBXm=zpRLuWAiyrmEMmXnrY6CA@mail.gmail.com> <A0FF8539-2868-46A8-995D-7D57705D8AA3@alcatel-lucent.com> <CA+b+ERk9vOdzacXjjmhK2uWFM+Aad8gK3KLJQBeFVb2XwbW3fA@mail.gmail.com> <6190874E-0CC8-4437-9117-F7429242064B@puck.nether.net> <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> <57E27785.2010809@foobar.org> <CA+b+ERnL=RhivBFDERivrAFs73NA02Vr4ryHEEP3dOy-MtOu8A@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Wed, 21 Sep 2016 12:10:04 -0400
X-Google-Sender-Auth: j2aHlMnLT0OoFOIrRLNksX5Chuk
Message-ID: <CAL9jLaaKK4Uacuc10SZ2pJkfVuwFvwFu7zBud+a_5a8fvcEHXw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>, "grow@ietf.org grow@ietf.org" <grow@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0c7d2237e719053d06c7f8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/knHPTM1IXFrN4yxcUddNGjyG2JI>
Cc: "idr@ietf.org" <idr@ietf.org>
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 16:10:08 -0000

+grow

On Wed, Sep 21, 2016 at 12:02 PM, Robert Raszuk <robert@raszuk.net> wrote:

> But it already there ... it is even WG document ..
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-registered-
> wide-bgp-communities/
>
>
>
i'm unclear how this is helping this dicussion.


>
> On Wed, Sep 21, 2016 at 2:05 PM, Nick Hilliard <nick@foobar.org> wrote:
>
>> Robert Raszuk wrote:
>> > ​If something as you admit is critical to operators to run the network
>> > shouldn't it be maintained by IANA registry rather then sit on private
>> > web sites ?
>>
>> if you are seriously suggesting this, then we look forward to your
>> Internet Drafts.
>>
>
I think nick/jared/gert/jzp/mikael (all operators) have all said that
registering the usecases today isn't helpful, that some of these usecases
are not public (by design) and that they have evolved over time.

I'd like to see the generalized set of these captured in a
document/reference though, which is something grow can / should do ... and
then use that as the requirements set going forward (updated as Gert/etc
find new requirements of use to their networks). Getting focused on
byzantine corner cases isn't helpful, so generally useful requirements
should be a goal. This should make the IDR side of life simpler and it
should help vendors stop telling me, mikael, jared all: "Hey you're the
first to ever ask for this, wow!" (because actually we've had to configure
these things between us... so we know we're all asking for this 'feature' -
insert feature-du-jour-discussion)

-chris