Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

Rob Shakir <rjs@rob.sh> Sat, 03 September 2016 16:04 UTC

Return-Path: <rjs@rob.sh>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5294E12D507 for <netmod@ietfa.amsl.com>; Sat, 3 Sep 2016 09:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.20150623.gappssmtp.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 nk5T7RpB6_sb for <netmod@ietfa.amsl.com>; Sat, 3 Sep 2016 09:04:50 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 8477412D1B1 for <netmod@ietf.org>; Sat, 3 Sep 2016 09:04:50 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id e124so87681389ith.0 for <netmod@ietf.org>; Sat, 03 Sep 2016 09:04:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LzzPvWzNoog3KAvp6R3APyK4TOKt3RPc4/55j2gyAyE=; b=YSXCNH6Rnp9UikZDi1yOvFwSzComqyo2c+Qneu4E+qqCjzY1ULJ3sY1R8U+OhhBGRE B+sCWJ0Kzt2lLFN+LvUwkIa5QEwWK6EvHGbY8egcvwXwWbj9DkBiWMOYf7TdcuvAvqJm YxRaVIaCtuIYPXoAKMSfYx8oGojknep7TRp3772QmMpx+F+sL8MJD5aH7P/rz4ue1cgi Nz0RCrRFrAKONj58YZj0cVRCNQ++5xWpyX8H/j3Rc4JR6gIIXR3yzBqnQPhQJ8op6Z+J T3f0xm52B0ZSc6SY2wtAj/z8/y8LcKbnkh+ReInV/U73Cle2tVwaCaIx0p1VCskamCel rq5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LzzPvWzNoog3KAvp6R3APyK4TOKt3RPc4/55j2gyAyE=; b=TnlKL7eZguYrEPXMe03s22GlpoAPojRus1CNjlNFkBAsQgYWRyaoTt1jOKX9J+wX63 g0dL+uEvMRgQdznrZQD2gC7gSLbq2fcJcT4D6UzOOo2jn/Pmf0NuHtiBxASJN1z2lGrl WteidH3601TdbkjdAyhlT5gtEt+zDrKO7IvV4lT29BSQ7FjEZnKMBMPK1/SfKJVRSQpe JoX9ZblKNEgX5pAs7nMwmoQnbJaWPNrKrxuiCUuV6S5LVL8eypRRpRhy/aumeP8+NspC eDF/xC/KiuNxv3Pub87knakmy8Nph9bstzkRVlghW3qyt/z7g+DO71utjPXy1emz53K4 1O6A==
X-Gm-Message-State: AE9vXwMC1bW1xK9v+4+SLAZogQtTnha9pbrquivkA9VfFG0btRJuZ0CZSdEj2ZHaPcXUjwLXc5dpOnU8rD64iQ==
X-Received: by 10.107.8.37 with SMTP id 37mr5878949ioi.110.1472918689650; Sat, 03 Sep 2016 09:04:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.25.66 with HTTP; Sat, 3 Sep 2016 09:04:49 -0700 (PDT)
X-Originating-IP: [2601:647:4700:ebc0:b510:a70e:b85a:c4ad]
In-Reply-To: <08A2A580-BEA2-4AF0-9FFB-0F995B9DC778@juniper.net>
References: <08A2A580-BEA2-4AF0-9FFB-0F995B9DC778@juniper.net>
From: Rob Shakir <rjs@rob.sh>
Date: Sat, 3 Sep 2016 09:04:49 -0700
Message-ID: <CAHxMRebgqUVYBcpKXbU1KXGQcbSWJJjVnYdgUzNXbRtLLe3r2w@mail.gmail.com>
To: Kent Watsen <kwatsen@juniper.net>
Content-Type: multipart/alternative; boundary=001a113fb63c47c1c5053b9c9bd1
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/qOoPYtp-2skuRoimNZWweq_W_Vs>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Sep 2016 16:04:52 -0000

Hi Kent, NETMOD,

On Fri, Aug 26, 2016 at 10:54 AM, Kent Watsen <kwatsen@juniper.net>; wrote:

>
>
>
>
> Please indicate your support or concerns by Thursday September 9, 2016.
>
>
>
> We are not only interested in receiving defect reports, we are equally
> interested in statements of the form:
>
>
>
>   * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
>
>   * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
>
>   * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
>
>   * I am considering to implement the data model in
> draft-ietf-netmod-routing-cfg-23
>

I'd like to add a new category to this set of statements:

 * I have reviewed this draft, and will *not* be implementing the data
model described within it.

I have concerns with the contents of this model and their suitability as a
base for the wider set of models that are intended to augment it. Indeed, I
think the elements that it tackles (e.g., arrangement of protocols within a
routing instance) are very much lowest common denominator, and none of the
wider issues around multi-tenancy of routing instances (especially those
that mix VSI and VRF type semantics) on an individual device, or the way
that protocols map to RIBs, and how they then interact/interconnect are
tackled within the model.

Whilst I understand the difficulties that the authors have been through to
try and find a solution, I'm afraid that consensus here has led to a model
that actually is operationally a no-op -- even the configuration for static
routing is not sufficient for most operator use cases that we have examined
when working on a similar problem space.

Based on this, and the lack of examination of real configurations of
network elements to the model described within the draft, I would oppose
progressing this model to RFC until such time as it has been proved to
cover a operationally viable set of functionality, and there can be any
level of confidence that further changes to the model will not be
immediately needed to be able to accommodate the use cases that are
required of it.  Given the historical opposition to revising models once
they have been cast as RFCs that we have seen within the IETF, then I feel
that avoiding incomplete models going to RFC is the best course of action.

Thanks,
r.

[0]: Please note: I am speaking as an individual here, not on behalf of any
wider set of view points.
[1]: Please further note: This opposition to publishing this document
completely ignores the issue of operational state. I have made my thoughts
clear on this previously, but these comments are entirely orthogonal to
that opposition.