Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02

Jon Mitchell <jrmitche@puck.nether.net> Mon, 29 July 2013 10:40 UTC

Return-Path: <jrmitche@puck.nether.net>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2880721F9F5F for <i2rs@ietfa.amsl.com>; Mon, 29 Jul 2013 03:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPfaGZ5z5Eny for <i2rs@ietfa.amsl.com>; Mon, 29 Jul 2013 03:40:58 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 71A4F21F994B for <i2rs@ietf.org>; Mon, 29 Jul 2013 03:40:58 -0700 (PDT)
Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6TAeu6m017257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Jul 2013 06:40:56 -0400
Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r6TAeuq6017255; Mon, 29 Jul 2013 06:40:56 -0400
Date: Mon, 29 Jul 2013 06:40:56 -0400
From: Jon Mitchell <jrmitche@puck.nether.net>
To: Russ White <russw@riw.us>
Message-ID: <20130729104056.GA7087@puck.nether.net>
References: <CAG4d1rdOrA4P6tZXqRmReRetusDLX3cjFvtxYw0OD9oE2ASZQA@mail.gmail.com> <039801ce8bf0$c7caed60$5760c820$@riw.us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <039801ce8bf0$c7caed60$5760c820$@riw.us>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Mon, 29 Jul 2013 06:40:57 -0400 (EDT)
Cc: i2rs@ietf.org, 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [i2rs] Call for WG Adoption: draft-keyupdate-irs-bgp-usecases-02
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/i2rs>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2013 10:40:59 -0000

On 28/07/13 20:15 -0400, Russ White wrote:
> 
> > Please review draft-keyupdate-irs-bgp-usecases-02 and comment on
> > whether it should be adopted by I2RS.  Detailed technical conversation is
> also
> > most welcome.
> 
> I was under the impression that this was being merged with
> draft-white-i2rs-use-case... Did we decide to carry all these use cases
> forward separately? Or not to carry draft-white-i2rs-use-case forward?

WG Chairs - is the intent to only have one BGP use cases draft?

The current keyupdate draft has a large number of use cases and
scenarios, mostly focused on SP network requirements.  Also, I note
that most of it's use cases are centralized deployment and vendor
neutral specification of configuration oriented in nature.  If we are
going to only progress one document to cover BGP use cases, I would
prefer it cover at least some use cases oriented towards manipulation
of routing information to meet service differentiated routing such as
those specified in your draft.

At this time without knowing the authors intent (although one of the
authors is on both documents?) and lack of comment on Joel's similar
feedback earlier to the group, I'm can't support adoption of this
draft if there is only an intent to progress one.  I'd be willing to
support it if the authors are committed to integrating the white draft
use cases (that don't already overlap such as VPN membership) into a
merged document however.

Jon