[L2sm] L2SM charter proposal

"Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com> Mon, 10 October 2016 12:27 UTC

Return-Path: <michael.scharf@nokia.com>
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E76129610 for <l2sm@ietfa.amsl.com>; Mon, 10 Oct 2016 05:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Level:
X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 u-W_ed6OkwRs for <l2sm@ietfa.amsl.com>; Mon, 10 Oct 2016 05:27:14 -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 4B2CE12953D for <l2sm@ietf.org>; Mon, 10 Oct 2016 05:27:14 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 255C4A7C134E2 for <l2sm@ietf.org>; Mon, 10 Oct 2016 12:27:10 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9ACRBbW012240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <l2sm@ietf.org>; Mon, 10 Oct 2016 12:27:12 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u9ACRBcw006379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <l2sm@ietf.org>; Mon, 10 Oct 2016 14:27:11 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.135]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 14:27:11 +0200
From: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>
To: "l2sm@ietf.org" <l2sm@ietf.org>
Thread-Topic: L2SM charter proposal
Thread-Index: AdIi8Z34b8Gws0BeT72D6VuLqSadbA==
Date: Mon, 10 Oct 2016 12:27:10 +0000
Message-ID: <655C07320163294895BBADA28372AF5D48AE8AEE@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/DEeAAIXlV2VTCPN6bjWeCB_sAWs>
Subject: [L2sm] L2SM charter proposal
X-BeenThere: l2sm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" <l2sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm>, <mailto:l2sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l2sm/>
List-Post: <mailto:l2sm@ietf.org>
List-Help: <mailto:l2sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2sm>, <mailto:l2sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Oct 2016 12:27:16 -0000

I am not sure where the charter wording on https://datatracker.ietf.org/wg/l2sm/charter/ has been discussed. Anyway, I had a look...

> The IETF and the industry in general is currently specifying a set of YANG
> models for network element and protocol onfiguration. This is an essential first

Nit: s/onfiguration/configuration/

> step, but the end goal is full system configuration that enable service agility
> to speed service creation and delivery and allows the deployment of innovative
> new services across networks. Services are built from a combination of network
> element and protocol configuration, but are specified to service
> users in more abstract terms.

> The Layer Two Virtual Private Network Service Model (L2SM) working group is a
> short-lived WG tasked to create a YANG data model that describes a L2VPN service
> (a L2VPN service model) that can be used for communication between customers and

Isn't one of the lessons learnt from L3SM that the term "service model" can be understood in quite different ways, in particular in hierarchical network architectures?

> network operators, and to provide input to automated control and configuration
> applications. The working group will attempt to derive a single data model that
> includes support for point-to-point Virtual Private Wire Services (VPWS) and
> multipoint Virtual Private LAN services (VPLS) that use Pseudowires signaled
> using the Label Distribution Protocol (LDP) and the Border Gateway Protocol
> (BGP) as described in RFC4761 and RFC6624.

To me, "includes support for" is not a very specific wording. Will the deliverable of a working group be limited to VPWS and VPLS? If yes, why not state it? If no, why not be more explicit about what else may be in scope, or not in scope?

BTW, that long sentence is hard to parse.

> It needs to be clearly understood that this L2VPN service model is not an L2VPN
> configuration model. That is, it does not provide details for configuring
> network elements or protocols (that work is expected to be carried out in other
> protocol-specific working groups). Instead, the L2VPN service model contains the
> characteristics of the service as discussed between the operators and their
> customers. A separate process is responsible for mapping this service model onto
> the protocols and network elements depending on how the network operator chooses
> to realise the service.

> The deliverable from this working group will provide information to evaluate the
> set of YANG models that have already been developed or are under development,

That sentence is also in the L3SM charter. But I wonder if L3SM has indeed delivered an evaluation of existing YANG models? Also, I am not sure how draft-wen-l2sm-l2vpn-service-model addresses this requirement.

I believe for L2VPNs there are other ongoing modeling activities, e.g., in MEF, and there may also be overlap with some transport-oriented work in other IETF WGs. This sentence could be understood as an evaluation and gap analysis of existing YANG models.

> and will help identify any missing models or details. The deliverable can be
> viewed as driving requirements for protocol configuration model so that the
> service parameters can be mapped into inputs used by the protocol models.

Again, I wonder if this WG really plans to deliver this? Has L3SM really managed to provide good requirements for parameter mapping, e.g., for the non-trivial service parameters such as QoS?

> The working group will learn from the experience of the L3SM working group and
> it is expected that the L2SM data model will have similar structure to the L3SM
> data model.

I am not sure what the first part of this sentence would imply? Unless it is spelt out what these lessons learnt are, I think it can be removed. The charter wording of L2SM itself may obviously leverage lessons learnt from L3SM ;-)

The second part of the sentence results in quite a number of constraints regarding the model design. I think this warrants a dedicated sentence, and possibly even some further discussion on the priority of aligning structure with L3SM vs. aligning with other YANG models.

> The working group should consider draft-wen-l2sm-l2vpn-service-model as a
> starting point.

> The working group will coordinate with other working groups responsible for
> L2VPN protocol work (most notably with BESS and PALS) and with the MEF.

I think there is a difference between BESS/PALS and MEF. The models in BESS and PALS don't overlap significantly with the scope of the L2SM charter.

I think a more explicit statement regarding MEF would be useful. MEF works on quite related YANG models. For instance, draft-wen-l2sm-l2vpn-service-model includes the following sentence: "Rather than introducing a new set of terminologies, the L2SM will align with existing MEF attributes when it's applicable." That wording may be a starting point. Albeit the question is whether some sort of liaison would be limited to terminology reuse only.

Also, I wonder if MEF is really the only other relevant standardization body for L2VPNs.

>From an implementer's perspective, lack of alignment between standardization bodies is an issue.

> Milestones

> December 2016   Adopt WG draft for data model
> October  2017   Request publication of data model as Standards Track RFC
> December 2017   Close working group

Well, this seems a bit ambitious to me, given the experience in L3SM. And L3SM didn't have to consider e.g. other standardization bodies...

Thanks

Michael