Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model

Rob Shakir <rjs@rob.sh> Thu, 23 July 2015 10:19 UTC

Return-Path: <rjs@rob.sh>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56031A033A for <l3sm@ietfa.amsl.com>; Thu, 23 Jul 2015 03:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mRRp7aUEFi8k for <l3sm@ietfa.amsl.com>; Thu, 23 Jul 2015 03:19:46 -0700 (PDT)
Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2814F1A0338 for <l3sm@ietf.org>; Thu, 23 Jul 2015 03:19:42 -0700 (PDT)
Received: from [86.189.4.239] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <rjs@rob.sh>) id 1ZIDb0-0002m7-6O; Thu, 23 Jul 2015 11:19:22 +0100
Date: Thu, 23 Jul 2015 11:19:29 +0100
From: Rob Shakir <rjs@rob.sh>
To: 'Kireeti Kompella' <kireeti.kompella@gmail.com>, "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "l3sm@ietf.org" <l3sm@ietf.org>
Message-ID: <etPan.55b0bfb1.9ebecdf.17e@corretto.local>
In-Reply-To: <655C07320163294895BBADA28372AF5D484379B9@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk> <10361_1437568788_55AF8F14_10361_7312_1_9E32478DFA9976438E7A22F69B08FF92166A3977@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <655C07320163294895BBADA28372AF5D484379B9@FR712WXCHMBA15.zeu.alcatel-lucent.com>
X-Mailer: Airmail (303)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="55b0bfb1_2096b6f2_17e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/l3sm/FNfvYjH12xnuqAhV7Gw_tOTfsV4>
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 10:19:49 -0000



On 23 July 2015 at 11:15:26, Scharf, Michael (Michael) (michael.scharf@alcatel-lucent.com) wrote:

> > But some early, precautionary modularisation is not going to be a 
> problem so long as we don't spend too long arguing about exactly what 
> to modularise. 
> 
> Fully agree ..., some sections Kireeti was mentioning are evident to be 
> as a reusable component so we can do it now, for more complex things, 
> let's think about it after the module is (almost) finished. 

There is great value in having a consistent model without complex external dependencies, and we should aim at publishing that model soon. This significantly simplifies implementation. 
Can you clarify which implementation you mean here, please? IMHO — there is a set of one off implementation effort to support the model in a network mgmt system - but there is the implementation of changes across a set of services offered by an operator. I expect that more changes happen within the operator’s services (new hardware, new constraints from suppliers or external network dependencies being removed, new customer requirements) than happen for the NMS needing to support different model features (from what I see today), hence, it’d be good to have a debate as to which implementations we want to simplify.

An approach that makes changes to services hard or costly to implement for operators will result in any models produced in the IETF being unusable, or not helping with the current complexities we have.

Best,

r.