Re: [L2sm] L2SM charter proposal

Benoit Claise <bclaise@cisco.com> Wed, 19 October 2016 15:54 UTC

Return-Path: <bclaise@cisco.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 40B5E129670 for <l2sm@ietfa.amsl.com>; Wed, 19 Oct 2016 08:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.953
X-Spam-Level:
X-Spam-Status: No, score=-14.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2_4Ru-Yjckyx for <l2sm@ietfa.amsl.com>; Wed, 19 Oct 2016 08:54:54 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F071295D2 for <l2sm@ietf.org>; Wed, 19 Oct 2016 08:54:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2931; q=dns/txt; s=iport; t=1476892493; x=1478102093; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=jPzXR6azXtzPCLC5sBV/uPkZxHXsSbxO62XVijJry0s=; b=HtaDg+GeOdQN1SH+1WLAZM8QhguVm3BiMD+iNDta/qsj+LQnPqlAX6x8 TSZkcqV5mlzK3gVL7fCggXxOvnpS0YXrg58zzwbPcbl2AsdzTcJvd9EUp uL3absjyaDaUKzYhn5lEWTJDKG29mIvfr9CT/5qmqDCjenotGxxLI9YZd A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C1AQA7lgdY/xbLJq1SChoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYM+AQEBAQF0Ko4HqzaCCCeFegKCOBQBAgEBAQEBAQFiKIRjAQEEOFE?= =?us-ascii?q?LRlcGAQwIAQGITg7DbwEBAQEBAQEBAQEBAQEBAQEBARoFhj2BfYJYhB+GBwEEm?= =?us-ascii?q?g2GKYlhiWuGDoksh1IeNkcGCIMFHIFVPIhxAQEB?=
X-IronPort-AV: E=Sophos;i="5.31,367,1473120000"; d="scan'208";a="646501782"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Oct 2016 15:54:51 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u9JFsoMq005211; Wed, 19 Oct 2016 15:54:51 GMT
To: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "l2sm@ietf.org" <l2sm@ietf.org>
References: <655C07320163294895BBADA28372AF5D48AE8AEE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0c1f01d2239d$3d98fe00$b8cafa00$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48AEBA0D@FR712WXCHMBA15.zeu.alcatel-lucent.com> <051301d2287c$62ff9b20$28fed160$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48AFA88A@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <872d3048-4c1f-d7f3-543e-05473c2adba4@cisco.com>
Date: Wed, 19 Oct 2016 17:54:50 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <655C07320163294895BBADA28372AF5D48AFA88A@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/l2sm/wWgTBYULUQfZvDHU4VwXRMV_B0I>
Subject: Re: [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: Wed, 19 Oct 2016 15:54:56 -0000

Michael, Adrian,

Thank you for the discussion, and the text proposal.
That lead to this new charter text, v00-05: 
https://datatracker.ietf.org/doc/charter-ietf-l2sm/
See in line (removing some text)...
>
>> How about...
>>
>> OLD
>> 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,
>> 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.
>> NEW
>> The deliverable from this working group will provide information that other
>> working groups can use to evaluate the set of YANG models that they have
>> already
>> developed or that are under development. This will help them to identify any
>> missing models or details. Thus, the deliverable can be viewed as driving
>> requirements for service delivery models so that the customer service
>> parameters
>> can be mapped into inputs used by the protocol configuration models.
>> END
> In practice, a customer service model is much more abstract than specific configuration models, i.e., it only includes a subset of parameters. It seems a bit strange to me that the charter assumes that missing model details in protocol configuration will be derived from an abstract representation. And I am not sure if this has ever happened in the L3SM case.
If we look at the L3SM customer service model, we can deduce which 
technologies  orchestrator/controller will have to configure on devices: 
routing, interface, multicast, etc. This is the idea behind this text. 
Note that it doesn't have to be a formal WG deliverable.
>
> In my experience, the real-world question is whether a customer service model indeed includes all the relevant parameters e.g. from a protocol configuration model, e.g., if a customer of a service provider has specific needs. This is exactly the opposite of the workflow that is assumed in the charter.
>
> Of course, it doesn't do harm to make void statements.
>
>> But we could...
>> OLD
>> The working group will coordinate with other working groups responsible for
>> L2VPN protocol work (most notably with BESS and PALS) and with the MEF.
>> NEW
>> The working group will coordinate with other working groups responsible for
>> L2VPN protocol work (most notably with BESS and PALS). It will also coordinate
>> with other organizations working on related L2VPN data models (such as the
>> MEF).
>> END
> Noting external dependencies in a separate sentence is better.
>
> Do the WG proponents plan to share details on how they plan to deal with the overlapping work in MEF?
That's a good questions for the draft authors.
 From a process point of view, the communication with MEF started.

Regards, Benoit