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

"Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com> Thu, 23 July 2015 10:41 UTC

Return-Path: <michael.scharf@alcatel-lucent.com>
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 09D501A1A34 for <l3sm@ietfa.amsl.com>; Thu, 23 Jul 2015 03:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.309
X-Spam-Level:
X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, 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 e1lhYR_UZfwg for <l3sm@ietfa.amsl.com>; Thu, 23 Jul 2015 03:41:26 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3481A0370 for <l3sm@ietf.org>; Thu, 23 Jul 2015 03:41:26 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C04846F8694D4; Thu, 23 Jul 2015 10:41:22 +0000 (GMT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6NAdHVI011662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 12:41:10 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 12:39:55 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: Rob Shakir <rjs@rob.sh>, 'Kireeti Kompella' <kireeti.kompella@gmail.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "l3sm@ietf.org" <l3sm@ietf.org>
Thread-Topic: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model
Thread-Index: AQHQw8X4DW+4qcfGmUmoUTaDVwVcyZ3nSqKAgAADRgCAAYdm0P//472AgAAh7JA=
Date: Thu, 23 Jul 2015 10:39:54 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48437A4F@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> <etPan.55b0bfb1.9ebecdf.17e@corretto.local>
In-Reply-To: <etPan.55b0bfb1.9ebecdf.17e@corretto.local>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D48437A4FFR712WXCHMBA15z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/l3sm/eO0EQRo3Z1x8oeZEGcqB8gJM3e0>
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:41:29 -0000

Hi Rob,

My understanding is that the abstract L3SM model would be offered by a network management system software. Being in R&D, I mean the software “implementation” of the L3SM model.

I fully agree that deploying a corresponding NMS solution is not trivial, in particular if the network operator’s services change. But I don’t really understand why a more modular abstract service model in L3SM would simplify these challenges. But for these type of questions we would really appreciate input from network service providers.

Thanks

Michael


From: Rob Shakir [mailto:rjs@rob.sh]
Sent: Thursday, July 23, 2015 12:19 PM
To: 'Kireeti Kompella'; Scharf, Michael (Michael); adrian@olddog.co.uk; stephane.litkowski@orange.com; l3sm@ietf.org
Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model





On 23 July 2015 at 11:15:26, Scharf, Michael (Michael) (michael.scharf@alcatel-lucent.com<mailto: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.