From nobody Fri Dec 2 04:37:56 2016 Return-Path: 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 2C14E129659 for ; Fri, 2 Dec 2016 04:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 wSz3VvfKjNOh for ; Fri, 2 Dec 2016 04:37:52 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDD012964B for ; Fri, 2 Dec 2016 04:37:51 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id uB2CbakS009352; Fri, 2 Dec 2016 12:37:36 GMT Received: from 950129200 (58.145.115.87.dyn.plus.net [87.115.145.58]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id uB2CbZT8009346 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2016 12:37:36 GMT From: "Adrian Farrel" To: Date: Fri, 2 Dec 2016 12:37:32 -0000 Message-ID: <057e01d24c98$da480a60$8ed81f20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJMmMOZ16syzBswSee+sYhAiw1zJw== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22736.007 X-TM-AS-Result: No--1.623-10.0-31-10 X-imss-scan-details: No--1.623-10.0-31-10 X-TMASE-MatchedRID: BaB5/ULQv56l4Agrpd+E+uYAh37ZsBDCYVHJqsy5v9ubKItl61J/ycnj LTA/UDoA2/7pivnymGMCU1PRf9o2s+ofmSODT7bz+gtHj7OwNO25V9z3vqk3Ks4i3LBYikVE6zH Aqs4Zhy9fevEqFM5CtZ67PI26KuTE/igrJMpzc3/QBJOxerABUKcoNjoaoOy14/2upwvShuZsiC kF3IgUmYfH/fn3ddET5L5lO4I9n60+J+6OAjXd2j24k3IdKZt+ Archived-At: Cc: Qin Wu Subject: [L2sm] Draft minutes from Seoul uploaded X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 12:37:54 -0000 https://datatracker.ietf.org/doc/minutes-97-l2sm/ Please have a look to see whether I misreported you. Thanks, Adrian From nobody Mon Dec 19 06:32:33 2016 Return-Path: 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 A2619129413 for ; Mon, 19 Dec 2016 06:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 9tpgb9UzabV9 for ; Mon, 19 Dec 2016 06:32:30 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA69129ADF for ; Mon, 19 Dec 2016 06:32:30 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uBJEWSo0001925 for ; Mon, 19 Dec 2016 14:32:28 GMT Received: from 950129200 ([84.92.139.55]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id uBJEWRVY001912 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 19 Dec 2016 14:32:28 GMT From: "Adrian Farrel" To: References: <006901d24d7a$dab3a1c0$901ae540$@olddog.co.uk> In-Reply-To: <006901d24d7a$dab3a1c0$901ae540$@olddog.co.uk> Date: Mon, 19 Dec 2016 14:32:26 -0000 Message-ID: <00e001d25a04$b8a6e4c0$29f4ae40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzhnXMmeQx+83BkWFwNFueoEHlKaDM+9FA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22770.007 X-TM-AS-Result: No--18.257-10.0-31-10 X-imss-scan-details: No--18.257-10.0-31-10 X-TMASE-MatchedRID: Flbf/WcvcD9fxjHOlzzBh51U1lojafr/yeUl7aCTy8isafcFLFlU1Hdx LedBcdq5MXEn4M+GcWuj5ZKI09oqktq72IXmYAV7WteDSXCrUTQjkrgJ37RqjzMVY5itbDoDPlF 5N5t2gL8+DJJcVeM22lcniFgWX3X7/3JlBY4gQT1X0vBPb36vNh9fNWA7SFWq47E6rstCUYuTgB JRkV6RTQbaZTVGPRZaUF72rDLUdzqrSRUfrRMtgBiTH2TyLmz++pkYmVlzZ8urzPs85fwUk5sf8 iX+9Eb6jYNSFOSlOKZRx/KFW5aHPVGrNAIG8dX9qbg9uWhLYLdBldmDYjwlpgzzaIyrVuO8VTqS hhR4st/i8zVgXoAltlwtzewu2M637Tc/WGKLaySx5amWK2anSPoLR4+zsDTtH/zyL+gBqixjR1M EsM3+FgLfB0oodBQMkf/gMvw84IBXQWLUdouU9w== Archived-At: Subject: [L2sm] Draft liaison response X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 14:32:32 -0000 Hi, As you recall, the MEF sent the IETF a communication on the last day of October (https://datatracker.ietf.org/liaison/1498/) Here is a draft response that Qin and I propose to send as WG chairs. Any comments? Thanks, Adrian > Subject: Response to your liaison dated 31st October 2016 > > From: L2SM Chairs > > To: MEF > > Cc: Raghu Ranganathan > Benoit Claise > Joel Jaeggli > L2SM Working Group > Scott Mansfield > Mahesh Jethanandani > > > Thank you for your liaison message of 31st October this year > addressed to the IESG and OPS Area Directors. > > Since your liaison, the Layer 2 VPN Service Model (L2SM) working > group has been formed by the IESG. You can see the working group's > charter at https://datatracker.ietf.org/wg/l2sm/charter/. > > The working group met for the first time at IETF-97 in Seoul and had > a lively discussion about its work including the issues of terminology, > functional boundaries, and potential overlap with or use of MEF work. > You can see the meeting materials and draft minutes at > https://datatracker.ietf.org/meeting/97/materials/ by searching for > "L2SM". Both Mahesh Jethanandani and Scott Mansfield were in the room > during the meeting and can probably give you their views on what > happened. > > Your liaison message is most helpful in pointing out existing and > ongoing MEF work related to the task of the L2SM working group, and the > fact of you making available log-in details for your work-in-progress > is very much appreciated. > > The working group has so far been clear in its intent where possible > and consistent with its own work to re-use by reference any relevant > existing material such as that developed by the MEF Forum. So far it > has identified SLAs, QoS, and Billing as components that may very well > be candidates for such re-use. > > At the moment, the working group is at a very early stage. We welcome > participation by all interested parties, but in particular by service > providers and service customers since they are the principal users of > the YANG model under construction. Participation is open to all via > the mailing list https://www.ietf.org/mailman/listinfo/l2sm. > > We wish you well with your January meeting. > > Qin Wu and Adrian Farrel > L2SM Working Group Chairs From nobody Mon Dec 19 06:53:02 2016 Return-Path: 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 F0C91129B15 for ; Mon, 19 Dec 2016 06:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 jOIDtsOI1eAK for ; Mon, 19 Dec 2016 06:52:58 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E66129997 for ; Mon, 19 Dec 2016 06:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8904; q=dns/txt; s=iport; t=1482159178; x=1483368778; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=s/AkJyXu2RMQw+bSUjfHIrqn2bt3SQPfXo5u4cXTo/k=; b=HUkvktZZgm6kNsxqv4Miu4m/pZdFKLou+vbVEa3elXr1AclSGCoHTv+3 EF+0UL+TvAqNLLw899q1ioazh/YtLILCdnCi5/aAVft9TzO4gHx/NPaXD NGbJmheJCXyU1oYSs2SdZRPL5ccomc9PgoSigOcVEFDc859wam0gZqpsF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AACs81dY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywLAQEBAQF5gQaNT3OVZY9phSWCCh8BCoV4AoJAFAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEEAQEQXAYVCxUCARYBFycoCAcMBgIBAR6ISQ6ZfgGQHi+KXQEBA?= =?us-ascii?q?QEBAQEBAgEBAQEBAQEBAQEBGAWGNoF9glyFCAGFGAWacIZShheES4oehi+KNIN?= =?us-ascii?q?lhA8fN4ECFQ4rg2IXgV0+NIYhDReCFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,374,1477958400"; d="scan'208,217";a="690569590" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2016 14:52:55 +0000 Received: from [10.63.23.112] (dhcp-ensft1-uk-vla370-10-63-23-112.cisco.com [10.63.23.112]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id uBJEqtq7007149; Mon, 19 Dec 2016 14:52:55 GMT To: adrian@olddog.co.uk, l2sm@ietf.org References: <006901d24d7a$dab3a1c0$901ae540$@olddog.co.uk> <00e001d25a04$b8a6e4c0$29f4ae40$@olddog.co.uk> From: David Ball Message-ID: Date: Mon, 19 Dec 2016 14:52:55 +0000 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: <00e001d25a04$b8a6e4c0$29f4ae40$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------060436CA4AE6C5B99CE2B98B" Archived-At: Subject: Re: [L2sm] Draft liaison response X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 14:53:00 -0000 This is a multi-part message in MIME format. --------------060436CA4AE6C5B99CE2B98B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, A few comments: * The most relevant part of the MEF work in progress (i.e. the working drafts of their Yang modules) was attached to the liaison rather than being available via the login; so prob need to tweak the wording a bit to thank them for that as well. * Their liaison asked a for a specific clarification with respect to the charter; it would be helpful to provide the clarification in the reply. * They also suggest that L2SM proceeds by augmenting the MEF modules - it might be useful to address that point specifically in the reply (even if it's only to say that no decision has yet been reached by the WG). Thanks, David On 19/12/2016 14:32, Adrian Farrel wrote: > Hi, > > As you recall, the MEF sent the IETF a communication on the last day of October > (https://datatracker.ietf.org/liaison/1498/) > > Here is a draft response that Qin and I propose to send as WG chairs. Any > comments? > > Thanks, > Adrian > >> Subject: Response to your liaison dated 31st October 2016 >> >> From: L2SM Chairs >> >> To: MEF >> >> Cc: Raghu Ranganathan >> Benoit Claise >> Joel Jaeggli >> L2SM Working Group >> Scott Mansfield >> Mahesh Jethanandani >> >> >> Thank you for your liaison message of 31st October this year >> addressed to the IESG and OPS Area Directors. >> >> Since your liaison, the Layer 2 VPN Service Model (L2SM) working >> group has been formed by the IESG. You can see the working group's >> charter at https://datatracker.ietf.org/wg/l2sm/charter/. >> >> The working group met for the first time at IETF-97 in Seoul and had >> a lively discussion about its work including the issues of terminology, >> functional boundaries, and potential overlap with or use of MEF work. >> You can see the meeting materials and draft minutes at >> https://datatracker.ietf.org/meeting/97/materials/ by searching for >> "L2SM". Both Mahesh Jethanandani and Scott Mansfield were in the room >> during the meeting and can probably give you their views on what >> happened. >> >> Your liaison message is most helpful in pointing out existing and >> ongoing MEF work related to the task of the L2SM working group, and the >> fact of you making available log-in details for your work-in-progress >> is very much appreciated. >> >> The working group has so far been clear in its intent where possible >> and consistent with its own work to re-use by reference any relevant >> existing material such as that developed by the MEF Forum. So far it >> has identified SLAs, QoS, and Billing as components that may very well >> be candidates for such re-use. >> >> At the moment, the working group is at a very early stage. We welcome >> participation by all interested parties, but in particular by service >> providers and service customers since they are the principal users of >> the YANG model under construction. Participation is open to all via >> the mailing list https://www.ietf.org/mailman/listinfo/l2sm. >> >> We wish you well with your January meeting. >> >> Qin Wu and Adrian Farrel >> L2SM Working Group Chairs > > _______________________________________________ > L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm -- David Ball --------------060436CA4AE6C5B99CE2B98B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Adrian,

A few comments:

  • The most relevant part of the MEF work in progress (i.e. the working drafts of their Yang modules) was attached to the liaison rather than being available via the login; so prob need to tweak the wording a bit to thank them for that as well.
  • Their liaison asked a for a specific clarification with respect to the charter; it would be helpful to provide the clarification  in the reply.
  • They also suggest that L2SM proceeds by augmenting the MEF modules - it might be useful to address that point specifically in the reply (even if it's only to say that no decision has yet been reached by the WG).

Thanks,

    David

On 19/12/2016 14:32, Adrian Farrel wrote:
Hi,

As you recall, the MEF sent the IETF a communication on the last day of October
(https://datatracker.ietf.org/liaison/1498/)

Here is a draft response that Qin and I propose to send as WG chairs. Any
comments?

Thanks,
Adrian


Subject: Response to your liaison dated 31st October 2016

From: L2SM Chairs

To: MEF

Cc: Raghu Ranganathan <rraghu@ciena.com>
    Benoit Claise <bclaise@cisco.com>
    Joel Jaeggli <joelja@bogus.com>
    L2SM Working Group <l2sm@ietf.org>
    Scott Mansfield <scott.mansfield@ericsson.com>
    Mahesh Jethanandani <mahesh@cisco.com>


Thank you for your liaison message of 31st October this year
addressed to the IESG and OPS Area Directors.

Since your liaison, the Layer 2 VPN Service Model (L2SM) working
group has been formed by the IESG. You can see the working group's
charter at https://datatracker.ietf.org/wg/l2sm/charter/.

The working group met for the first time at IETF-97 in Seoul and had
a lively discussion about its work including the issues of terminology,
functional boundaries, and potential overlap with or use of MEF work.
You can see the meeting materials and draft minutes at
https://datatracker.ietf.org/meeting/97/materials/ by searching for
"L2SM".  Both Mahesh Jethanandani and Scott Mansfield were in the room
during the meeting and can probably give you their views on what
happened.

Your liaison message is most helpful in pointing out existing and
ongoing MEF work related to the task of the L2SM working group, and the
fact of you making available log-in details for your work-in-progress
is very much appreciated.

The working group has so far been clear in its intent where possible
and consistent with its own work to re-use by reference any relevant
existing material such as that developed by the MEF Forum. So far it
has identified SLAs, QoS, and Billing as components that may very well
be candidates for such re-use.

At the moment, the working group is at a very early stage. We welcome
participation by all interested parties, but in particular by service
providers and service customers since they are the principal users of
the YANG model under construction. Participation is open to all via
the mailing list https://www.ietf.org/mailman/listinfo/l2sm.

We wish you well with your January meeting.

Qin Wu and Adrian Farrel
L2SM Working Group Chairs


_______________________________________________
L2sm mailing list
L2sm@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm


-- 
David Ball
<daviball@cisco.com>
--------------060436CA4AE6C5B99CE2B98B-- From nobody Thu Dec 22 00:15:42 2016 Return-Path: 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 78FBC129420 for ; Thu, 22 Dec 2016 00:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 FBCq2otOrMCh for ; Thu, 22 Dec 2016 00:15:38 -0800 (PST) Received: from COL004-OMC2S13.hotmail.com (col004-omc2s13.hotmail.com [65.55.34.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694E91293D8 for ; Thu, 22 Dec 2016 00:15:38 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com ([65.55.34.73]) by COL004-OMC2S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 22 Dec 2016 00:15:38 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P4fwzn/0cyl/yRSTmKXjVSgec7cKk0sIyaKS0w0nwz0=; b=Ho9L7dH3xqZ+prZ/492X9emnqxIbrvZte8S26ksQ5AUiwAPJy+R4JDWH/orLQru4/onC+6hkc7zmtmMe6jiqyCaBRGQqMF8QOU+IRXWT4Hutm9SZQdpowdHpLsJ9v4yhV3sqA/WlYFmJagMip5ICzqpy88ftrDd0EuvoFTbyBzT1OXVOnuSZ8F2a/CiEIBV2rhLaRKYkUwphsHQBFtplRFH6Pa1K0CZpOnzRn0P6FLuY1QfdKHc7gx0/dYAcE+RuSMQH1Vny+9Toihukt4BrdzdMG8q7mO8gl/u8aec3KOj59OUNjATwBXycY5lZMROtQzFFZjPJKwbhG4Ube+XNNA== Received: from PU1APC01FT034.eop-APC01.prod.protection.outlook.com (10.152.252.52) by PU1APC01HT237.eop-APC01.prod.protection.outlook.com (10.152.253.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.7; Thu, 22 Dec 2016 08:15:28 +0000 Received: from HK2PR0201MB1650.apcprd02.prod.outlook.com (10.152.252.58) by PU1APC01FT034.mail.protection.outlook.com (10.152.252.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.10 via Frontend Transport; Thu, 22 Dec 2016 08:15:28 +0000 Received: from HK2PR0201MB1650.apcprd02.prod.outlook.com ([10.167.68.144]) by HK2PR0201MB1650.apcprd02.prod.outlook.com ([10.167.68.144]) with mapi id 15.01.0803.013; Thu, 22 Dec 2016 08:15:28 +0000 From: =?gb2312?B?ucsgyNY=?= To: "l2sm@ietf.org" Thread-Topic: [L2sm] Draft liaison response Thread-Index: AQHSXCpm020tf0xIREa7A8MR/pQOzQ== Date: Thu, 22 Dec 2016 08:15:27 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:CC0EC0B8D1501B3CFB730F24D909881F8478E7943B6924B43F9E4A2928074D8B; UpperCasedChecksum:6B35AB1F4D663F5EE392EB71491B08B3629E9D89BC5A4EE94AAE991EB31759E9; SizeAsReceived:7305; Count:37 x-tmn: [DLVPKgdjSZvzEkZgdqDxzavIThT0mzfwOirRqUCrXg0=] x-incomingheadercount: 37 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; PU1APC01HT237; 7:LhXgcsmAO6R9euwVyuwqj3xH+N3nGd+EFqg3Wz7ghqDQoDYKM0Ec/eOqNkQLh71wihvUCEkZIhQPkXXWSgD7LEl1eM5ozIb4yEzyVTgTrLxqNfFuYZ+QWM3fs3lTPFrzOpJnRubFBdz4Ssivc+za6uN8uSj/NGrHr0CiDzXoOAf1VfMAGyQOrjuwGhFTKY88YaHzxUHfcxvEDEJ9Y1QfXkDs8P1njcTwgENyyk+vz1XBGrfVZR94ZdmILE3MESbBLmymXtcq5gt1zcthMgc0KvrlTJoycm8adQ7yZtcfMCXnT4iYBVe/0H9+Z6TGZ56/uc9ZDew6YTLZf7H/DhKCMZX5vEGJX8b3wvpyBRQ8hbISeY8aKtEU2Ru7lYZ89IE7lVFyIgbe9Rk1NQbGQX/1+L20beKS/D46tQovXSm6MfY42GseKfFGEo2b7WKxBlE0KLlhtlB5EZfwff+eejOfAA== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:PU1APC01HT237; H:HK2PR0201MB1650.apcprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 9f806e11-811d-4d66-958b-08d42a42b05f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(5061506293)(5061507293)(1603103113)(1603101340)(1601125047); SRVR:PU1APC01HT237; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444111334)(444112120)(432015012)(82015046); SRVR:PU1APC01HT237; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT237; x-forefront-prvs: 01644DCF4A spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HK2PR0201MB165082C9623A0C6665229D4A8B920HK2PR0201MB1650_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2016 08:15:27.6921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT237 X-OriginalArrivalTime: 22 Dec 2016 08:15:38.0064 (UTC) FILETIME=[93D3B500:01D25C2B] Archived-At: Cc: "bclaise@cisco.com" , "adrian@olddog.co.uk" Subject: Re: [L2sm] Draft liaison response X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 08:15:40 -0000 --_000_HK2PR0201MB165082C9623A0C6665229D4A8B920HK2PR0201MB1650_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGRlYXIgYWxsLg0KUGVyc29uYWxseSwgSSB0aGluayBib3RoIE1FRiBtb2RlbCBhbmQgSUVU RiBtb2RlbCBoYXZlIHRoZWlyIHZhbHVlcy4gSG93ZXZlciwgIHRoZXkgdHdvIGZvbGxvdyBkaWZm ZXJlbnQgbW9kZWwgZGVzaWduIHRvIHRoZSBiZXN0IG9mIG15IGtub3dsZWRnZS4gSSdtIG5vdCBz dXJlIHdoZXRoZXIgaXQncyBzdWl0YWJsZSB0byBjb3VwbGUgTUVGIG1vZGVsIHdpdGggSUVURiBt b2RlbC4NCg0KQWN0dWFsbHksIEknbSBtdWNoIG1vcmUgZmFtaWxhciB3aXRoIElFVEYgbW9kZWwg c3VjaCBhcyBMMlZQTiBzZXJ2aWNlIG1vZGVsIGFuZCBMM1ZQTiBzZXJ2aWNlIG1vZGVsLiBTbywg SSB3b3VsZCBzdWdnZXN0IHRoYXQgSUVURiBtb2RlbCBjYW4gY2hvb3NlIHRvIHJlZmVyZW5jZSBN RUYgcmVsZXZhbnQgc3BlY2lmaWNhdGlvbnMuIFRoZXNlIHNwZWNpZmljYXRpb24gbWF5ICBiZSBh bHNvIHJlZmVyZW5jZWQgYnkgTUVGIG1vZGVsIGFzIHdlbGwuIFRoYXQgbWF5IGJlIGEgYmV0dGVy IHdheS4NCg0KR3UgUm9uZw0KZ3Vyb25nX2NtY2NAb3V0bG9vay5jb20NCmd1cm9uZ0BjaGluYW1v YmlsZS5jb20NCg0Kt6K8/sjLOiBMMnNtIFttYWlsdG86bDJzbS1ib3VuY2VzQGlldGYub3JnXSC0 +rHtIERhdmlkIEJhbGwNCreiy83KsbzkOiAyMDE2xOoxMtTCMTnI1SAyMjo1Mw0KytW8/sjLOiBh ZHJpYW5Ab2xkZG9nLmNvLnVrPG1haWx0bzphZHJpYW5Ab2xkZG9nLmNvLnVrPjsgbDJzbUBpZXRm Lm9yZzxtYWlsdG86bDJzbUBpZXRmLm9yZz4NCtb3zOI6IFJlOiBbTDJzbV0gRHJhZnQgbGlhaXNv biByZXNwb25zZQ0KDQoNCkhpIEFkcmlhbiwNCg0KQSBmZXcgY29tbWVudHM6DQoNCiAgKiAgIFRo ZSBtb3N0IHJlbGV2YW50IHBhcnQgb2YgdGhlIE1FRiB3b3JrIGluIHByb2dyZXNzIChpLmUuIHRo ZSB3b3JraW5nIGRyYWZ0cyBvZiB0aGVpciBZYW5nIG1vZHVsZXMpIHdhcyBhdHRhY2hlZCB0byB0 aGUgbGlhaXNvbiByYXRoZXIgdGhhbiBiZWluZyBhdmFpbGFibGUgdmlhIHRoZSBsb2dpbjsgc28g cHJvYiBuZWVkIHRvIHR3ZWFrIHRoZSB3b3JkaW5nIGEgYml0IHRvIHRoYW5rIHRoZW0gZm9yIHRo YXQgYXMgd2VsbC4NCiAgKiAgIFRoZWlyIGxpYWlzb24gYXNrZWQgYSBmb3IgYSBzcGVjaWZpYyBj bGFyaWZpY2F0aW9uIHdpdGggcmVzcGVjdCB0byB0aGUgY2hhcnRlcjsgaXQgd291bGQgYmUgaGVs cGZ1bCB0byBwcm92aWRlIHRoZSBjbGFyaWZpY2F0aW9uICBpbiB0aGUgcmVwbHkuDQogICogICBU aGV5IGFsc28gc3VnZ2VzdCB0aGF0IEwyU00gcHJvY2VlZHMgYnkgYXVnbWVudGluZyB0aGUgTUVG IG1vZHVsZXMgLSBpdCBtaWdodCBiZSB1c2VmdWwgdG8gYWRkcmVzcyB0aGF0IHBvaW50IHNwZWNp ZmljYWxseSBpbiB0aGUgcmVwbHkgKGV2ZW4gaWYgaXQncyBvbmx5IHRvIHNheSB0aGF0IG5vIGRl Y2lzaW9uIGhhcyB5ZXQgYmVlbiByZWFjaGVkIGJ5IHRoZSBXRykuDQoNClRoYW5rcywNCg0KICAg IERhdmlkDQpPbiAxOS8xMi8yMDE2IDE0OjMyLCBBZHJpYW4gRmFycmVsIHdyb3RlOg0KDQpIaSwN Cg0KDQoNCkFzIHlvdSByZWNhbGwsIHRoZSBNRUYgc2VudCB0aGUgSUVURiBhIGNvbW11bmljYXRp b24gb24gdGhlIGxhc3QgZGF5IG9mIE9jdG9iZXINCg0KKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbGlhaXNvbi8xNDk4LykNCg0KDQoNCkhlcmUgaXMgYSBkcmFmdCByZXNwb25zZSB0aGF0 IFFpbiBhbmQgSSBwcm9wb3NlIHRvIHNlbmQgYXMgV0cgY2hhaXJzLiBBbnkNCg0KY29tbWVudHM/ DQoNCg0KDQpUaGFua3MsDQoNCkFkcmlhbg0KDQoNCg0KU3ViamVjdDogUmVzcG9uc2UgdG8geW91 ciBsaWFpc29uIGRhdGVkIDMxc3QgT2N0b2JlciAyMDE2DQoNCg0KDQpGcm9tOiBMMlNNIENoYWly cw0KDQoNCg0KVG86IE1FRg0KDQoNCg0KQ2M6IFJhZ2h1IFJhbmdhbmF0aGFuIDxycmFnaHVAY2ll bmEuY29tPjxtYWlsdG86cnJhZ2h1QGNpZW5hLmNvbT4NCg0KICAgIEJlbm9pdCBDbGFpc2UgPGJj bGFpc2VAY2lzY28uY29tPjxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+DQoNCiAgICBKb2VsIEph ZWdnbGkgPGpvZWxqYUBib2d1cy5jb20+PG1haWx0bzpqb2VsamFAYm9ndXMuY29tPg0KDQogICAg TDJTTSBXb3JraW5nIEdyb3VwIDxsMnNtQGlldGYub3JnPjxtYWlsdG86bDJzbUBpZXRmLm9yZz4N Cg0KICAgIFNjb3R0IE1hbnNmaWVsZCA8c2NvdHQubWFuc2ZpZWxkQGVyaWNzc29uLmNvbT48bWFp bHRvOnNjb3R0Lm1hbnNmaWVsZEBlcmljc3Nvbi5jb20+DQoNCiAgICBNYWhlc2ggSmV0aGFuYW5k YW5pIDxtYWhlc2hAY2lzY28uY29tPjxtYWlsdG86bWFoZXNoQGNpc2NvLmNvbT4NCg0KDQoNCg0K DQpUaGFuayB5b3UgZm9yIHlvdXIgbGlhaXNvbiBtZXNzYWdlIG9mIDMxc3QgT2N0b2JlciB0aGlz IHllYXINCg0KYWRkcmVzc2VkIHRvIHRoZSBJRVNHIGFuZCBPUFMgQXJlYSBEaXJlY3RvcnMuDQoN Cg0KDQpTaW5jZSB5b3VyIGxpYWlzb24sIHRoZSBMYXllciAyIFZQTiBTZXJ2aWNlIE1vZGVsIChM MlNNKSB3b3JraW5nDQoNCmdyb3VwIGhhcyBiZWVuIGZvcm1lZCBieSB0aGUgSUVTRy4gWW91IGNh biBzZWUgdGhlIHdvcmtpbmcgZ3JvdXAncw0KDQpjaGFydGVyIGF0IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvd2cvbDJzbS9jaGFydGVyLy4NCg0KDQoNClRoZSB3b3JraW5nIGdyb3VwIG1l dCBmb3IgdGhlIGZpcnN0IHRpbWUgYXQgSUVURi05NyBpbiBTZW91bCBhbmQgaGFkDQoNCmEgbGl2 ZWx5IGRpc2N1c3Npb24gYWJvdXQgaXRzIHdvcmsgaW5jbHVkaW5nIHRoZSBpc3N1ZXMgb2YgdGVy bWlub2xvZ3ksDQoNCmZ1bmN0aW9uYWwgYm91bmRhcmllcywgYW5kIHBvdGVudGlhbCBvdmVybGFw IHdpdGggb3IgdXNlIG9mIE1FRiB3b3JrLg0KDQpZb3UgY2FuIHNlZSB0aGUgbWVldGluZyBtYXRl cmlhbHMgYW5kIGRyYWZ0IG1pbnV0ZXMgYXQNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9tZWV0aW5nLzk3L21hdGVyaWFscy8gYnkgc2VhcmNoaW5nIGZvcg0KDQoiTDJTTSIuICBCb3Ro IE1haGVzaCBKZXRoYW5hbmRhbmkgYW5kIFNjb3R0IE1hbnNmaWVsZCB3ZXJlIGluIHRoZSByb29t DQoNCmR1cmluZyB0aGUgbWVldGluZyBhbmQgY2FuIHByb2JhYmx5IGdpdmUgeW91IHRoZWlyIHZp ZXdzIG9uIHdoYXQNCg0KaGFwcGVuZWQuDQoNCg0KDQpZb3VyIGxpYWlzb24gbWVzc2FnZSBpcyBt b3N0IGhlbHBmdWwgaW4gcG9pbnRpbmcgb3V0IGV4aXN0aW5nIGFuZA0KDQpvbmdvaW5nIE1FRiB3 b3JrIHJlbGF0ZWQgdG8gdGhlIHRhc2sgb2YgdGhlIEwyU00gd29ya2luZyBncm91cCwgYW5kIHRo ZQ0KDQpmYWN0IG9mIHlvdSBtYWtpbmcgYXZhaWxhYmxlIGxvZy1pbiBkZXRhaWxzIGZvciB5b3Vy IHdvcmstaW4tcHJvZ3Jlc3MNCg0KaXMgdmVyeSBtdWNoIGFwcHJlY2lhdGVkLg0KDQoNCg0KVGhl IHdvcmtpbmcgZ3JvdXAgaGFzIHNvIGZhciBiZWVuIGNsZWFyIGluIGl0cyBpbnRlbnQgd2hlcmUg cG9zc2libGUNCg0KYW5kIGNvbnNpc3RlbnQgd2l0aCBpdHMgb3duIHdvcmsgdG8gcmUtdXNlIGJ5 IHJlZmVyZW5jZSBhbnkgcmVsZXZhbnQNCg0KZXhpc3RpbmcgbWF0ZXJpYWwgc3VjaCBhcyB0aGF0 IGRldmVsb3BlZCBieSB0aGUgTUVGIEZvcnVtLiBTbyBmYXIgaXQNCg0KaGFzIGlkZW50aWZpZWQg U0xBcywgUW9TLCBhbmQgQmlsbGluZyBhcyBjb21wb25lbnRzIHRoYXQgbWF5IHZlcnkgd2VsbA0K DQpiZSBjYW5kaWRhdGVzIGZvciBzdWNoIHJlLXVzZS4NCg0KDQoNCkF0IHRoZSBtb21lbnQsIHRo ZSB3b3JraW5nIGdyb3VwIGlzIGF0IGEgdmVyeSBlYXJseSBzdGFnZS4gV2Ugd2VsY29tZQ0KDQpw YXJ0aWNpcGF0aW9uIGJ5IGFsbCBpbnRlcmVzdGVkIHBhcnRpZXMsIGJ1dCBpbiBwYXJ0aWN1bGFy IGJ5IHNlcnZpY2UNCg0KcHJvdmlkZXJzIGFuZCBzZXJ2aWNlIGN1c3RvbWVycyBzaW5jZSB0aGV5 IGFyZSB0aGUgcHJpbmNpcGFsIHVzZXJzIG9mDQoNCnRoZSBZQU5HIG1vZGVsIHVuZGVyIGNvbnN0 cnVjdGlvbi4gUGFydGljaXBhdGlvbiBpcyBvcGVuIHRvIGFsbCB2aWENCg0KdGhlIG1haWxpbmcg bGlzdCBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wyc20uDQoNCg0KDQpX ZSB3aXNoIHlvdSB3ZWxsIHdpdGggeW91ciBKYW51YXJ5IG1lZXRpbmcuDQoNCg0KDQpRaW4gV3Ug YW5kIEFkcmlhbiBGYXJyZWwNCg0KTDJTTSBXb3JraW5nIEdyb3VwIENoYWlycw0KDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkwyc20g bWFpbGluZyBsaXN0DQoNCkwyc21AaWV0Zi5vcmc8bWFpbHRvOkwyc21AaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbDJzbQ0KDQoNCg0KDQotLQ0KDQpE YXZpZCBCYWxsDQoNCg== --_000_HK2PR0201MB165082C9623A0C6665229D4A8B920HK2PR0201MB1650_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, dear all.

Personally, I think both MEF model and IETF model have their= values. However,  they two follow different model design to= the best of my knowledge. I'm not sure whether it's suitable to couple MEF model with IETF model.&nb= sp;


Actually, I'm much more familar with IETF model such as= L2VPN service model and L3VPN service model. So, I would suggest that IETF model can choose to reference MEF relevant sp= ecifications. These specification may  be also referenced by MEF model= as well. That may be a better way.


Gu Rong

gurong_cmcc@outlook.com

gurong@chinamobile.com


=B7=A2=BC=FE=C8=CB: L2sm [mailto:l2sm-bounces@ietf.org] =B4=FA=B1=ED David Ball
=B7=A2=CB=CD=CA=B1=BC=E4:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;=0A= font-family:=CB=CE=CC=E5;color:windowtext"> 2016=C4=EA12=D4=C219=C8=D5 22:53
=CA=D5=BC=FE=C8=CB: adrian@olddog.co.uk; l2sm@ietf.org=
=D6=F7=CC=E2: Re: [L2sm] Draft liaison response

 <= /span>

Hi Adrian,

A few comments:

  • The most relevant part of the = MEF work in progress (i.e. the working drafts of their Yang modules) was at= tached to the liaison rather than being available via the login; so prob ne= ed to tweak the wording a bit to thank them for that as well.
  • Their liaison asked a for a specific clarific= ation with respect to the charter; it would be helpful to provide the clari= fication  in the reply.
  • They also suggest that L2= SM proceeds by augmenting the MEF modules - it might be useful to address t= hat point specifically in the reply (even if it's only to say that no decis= ion has yet been reached by the WG).

=
Thanks,

    David

On 19/12/2016 14:32, Adrian Far= rel wrote:

Hi,
 
As you recall, the MEF sent the IETF a communicat=
ion on the last day of October
(https://datatracker.ietf.org/liaison/1498/)
 
Here is a draft response that Qin and I propose t=
o send as WG chairs. Any
comments?
 
Thanks,
Adrian
 
Subject: Response to your liaison dated 31st Octo=
ber 2016
 
From: L2SM Chairs<=
/pre>

 


To: MEF


 


Cc: Raghu Ranganathan <rraghu@ciena.com>


    Benoit Claise <bclaise@cisco.com><=
/span>


    Joel Jaeggli <joelja@bogus.com>


    L2SM Working Group <l2sm@ietf.org>


    Scott Mansfield <scott.mansfield@ericsson.com><=
u5:p>


    Mahesh Jethanandani <mahesh@cisco.com>


 


 


Thank you for your liaison message of 31st Octobe=
r this year


addressed to the IESG and OPS Area Directors.


 


Since your liaison, the Layer 2 VPN Service Model=
 (L2SM) working


group has been formed by the IESG. You can see th=
e working group's


charter at https://datatracker.ietf.org/wg/l2sm/charter/.


 


The working group met for the first time at IETF-=
97 in Seoul and had


a lively discussion about its work including the =
issues of terminology,


functional boundaries, and potential overlap with=
 or use of MEF work.


You can see the meeting materials and draft minut=
es at


https://datatracker.ietf.org/meeting/97/materials/ by sea=
rching for


"L2SM".  Both Mahesh Jethanandani =
and Scott Mansfield were in the room


during the meeting and can probably give you thei=
r views on what


happened.


 


Your liaison message is most helpful in pointing =
out existing and


ongoing MEF work related to the task of the L2SM =
working group, and the


fact of you making available log-in details for y=
our work-in-progress


is very much appreciated.=



 


The working group has so far been clear in its in=
tent where possible


and consistent with its own work to re-use by ref=
erence any relevant


existing material such as that developed by the M=
EF Forum. So far it


has identified SLAs, QoS, and Billing as componen=
ts that may very well


be candidates for such re-use.<=
/o:p>


 


At the moment, the working group is at a very ear=
ly stage. We welcome


participation by all interested parties, but in p=
articular by service


providers and service customers since they are th=
e principal users of


the YANG model under construction. Participation =
is open to all via


the mailing list https://www.ietf.org/mailman/listinfo/l2sm.


 


We wish you well with your January meeting.=



 


Qin Wu and Adrian Farrel<=
/span>


L2SM Working Group Chairs=



 


 


_______________________________________________


L2sm mailing list<=
/pre>

L2sm@ietf.org


https://www.ietf.org/mailman/listinfo/l2sm












-- 


David Ball
--_000_HK2PR0201MB165082C9623A0C6665229D4A8B920HK2PR0201MB1650_-- From nobody Thu Dec 22 05:44:40 2016 Return-Path: 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 423D9129A0C for ; Thu, 22 Dec 2016 05:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 AXO0LE91Nsje for ; Thu, 22 Dec 2016 05:44:36 -0800 (PST) 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 0ABDC1299FD for ; Thu, 22 Dec 2016 05:44:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8552; q=dns/txt; s=iport; t=1482414251; x=1483623851; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=CLa1TOWmy4ZWyipLjkW5PnEHQ5IK0WYSuAh6RTjY2H8=; b=ZWWJm8KbSvcoq9SYvwJILSKC2TasUxTapDRKc10dp+5h9qPoHTAbvaVQ JsFGfgVTvxWJrPf6QkxFyS7mKHzHMc1TRmCHlXsyK7yRFYIZLmcwgQMZA CWYsa6nbqb8DX6EvjBiX4uDs6T+V1eaUmh6ZkAeg3gy4I6JMWluw9G+8x 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAQCh11tY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoLAQEBAQF7L1mNUXKVYI9vhSaCCR8BDIV2AoIqFAECAQEBAQE?= =?us-ascii?q?BAWIohGkCAgIBAWwbCxI0JyIOBgEMBgIBAYhpDqtTLopUAQEBAQEBAQECAQEBA?= =?us-ascii?q?QEBAQEbBYZIggKBWYEIhB0RAYV9BZp5iSBEh1aBdYUHgycjhgyKQId1HzdoHxY?= =?us-ascii?q?NLoViPTQBhjqCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,388,1477958400"; d="scan'208,217";a="648100849" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2016 13:44:08 +0000 Received: from [10.60.67.91] (ams-bclaise-89110.cisco.com [10.60.67.91]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id uBMDi8ug031784; Thu, 22 Dec 2016 13:44:08 GMT To: adrian@olddog.co.uk, l2sm@ietf.org, Scott Mansfield References: <0d4501d24132$62ceb590$286c20b0$@olddog.co.uk> From: Benoit Claise Message-ID: <5b6dbba2-d283-8c81-7aaa-152d05ebdb8c@cisco.com> Date: Thu, 22 Dec 2016 14:44:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <0d4501d24132$62ceb590$286c20b0$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------E939A49732DC794D9650F941" Archived-At: Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 13:44:38 -0000 This is a multi-part message in MIME format. --------------E939A49732DC794D9650F941 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, A couple of reflections on L2SM, just before the end of year break. First, I want to quote one chairs slides https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-chairs-slides-01.pdf: We really need this to be driven by Operators - Of course, vendors can and should participate - But be aware of how the data model is use I'm always baffled when vendors 'seem to) know better than the operators what they need. I don't believe we have spent enough time listening to the few operators in the room during the WG meeting. We have here a group of operators who want to do work in the IETF, and we should respect that. Second, on the differences between IETF and MEF service management. MEF wants to go for the full LSO architecture (billing, SLA, order management, etc.). Perfect. L2SM charter wants to do something similar to L3SM: a self-contained service YANG module. It would be nice to try to fit the L2SM service models in the MEF LSO architecture, but the L2SM work follows a different architectural model to LSO, and that there is no value in trying to match the functions across model at all costs. This should not invalidate either approach, only observe that they are different. Third, exactly like the L3SM draft, the L2SM draft includes a number of technology-specific parameters and these have caused people to claim that the I-D must be describing a normalised or configuration model. But (of course?) the parameters are needed to configure the CE-PE access connections. This is a suitable point of differentiation between MEF and L2SM that MEF has worked on CE-based models while L2SM will work on PE-based models. Indeed, the IETF works on the networking aspects. However, when a building is done somewhere else (typical example, SLA management done in MEF), this L2SM YANG module should only contain a place holder or a pointer. Fourth. Discussing those very topics live with Scott Mansfield (our MEF - IETF liaison manager) during a workshop recently, we agree that both IETF and MEF service models have a place. While we start to see some consolidation in terms of YANG modules for device management, we are only at the beginning of YANG service modules. I hope this is useful and that it clarifies the situation. Regards, Benoit > Hi, > > Our charter mandates that we consider basing our work on > draft-wen-l2sm-l2vpn-service-model-03.txt > > As we discussed in the meeting, that draft is not perfect. But when I asked the > room whether we thought that it would provide a good starting point that we > could work with to polish and adapt to become the I-D that we ultimately submit > for publication as an RFC, I believe I heard a good hum in favour and silence in > opposition. > > So this email starts a formal poll for adoption. Please answer: > > Do you think that the WG should adopt draft-wen-l2sm-l2vpn-service-model-03.txt? > > If "yes," it would help if you could indicate whether you have read the draft > and how happy you are with it. > If "no", it is important that you provide reasons. > > This poll will last for two weeks, ending on Saturday 3rd December. > > Just to reassure everyone that adoption does not imply that anything is set in > stone: we expect the WG to continue to develop the content and change whatever > needs to be changed. > > Thanks, > Adrian and Qin > > _______________________________________________ > L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm > . > --------------E939A49732DC794D9650F941 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

A couple of reflections on L2SM, just before the end of year break.

First, I want to quote one chairs slides https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-chairs-slides-01.pdf:
We really need this to be driven by Operators
    - Of course, vendors can and should participate
    - But be aware of how the data model is use  
I'm always baffled when vendors 'seem to) know better than the operators what they need. I don't believe we have spent enough time listening to the few operators in the room during the WG meeting.
We have here a group of operators who want to do work in the IETF, and we should respect that.

Second, on the differences between IETF and MEF service management.
MEF wants to go for the full LSO architecture (billing, SLA, order management, etc.). Perfect.
L2SM charter wants to do something similar to L3SM: a self-contained service YANG module.
It would be nice to try to fit the L2SM service models in the MEF LSO architecture, but the L2SM work follows a different architectural model to LSO, and that there is no value in trying to match the functions across model at all costs. This should not invalidate either approach, only observe that they are different.

Third, exactly like the L3SM draft, the L2SM draft includes a number of technology-specific parameters and these have caused people to claim that the I-D must be describing a normalised or configuration model. But (of course?) the parameters are needed to configure the CE-PE access connections. This is a suitable point of differentiation between MEF and L2SM that MEF has worked on CE-based models while L2SM will work on PE-based models. Indeed, the IETF works on the networking aspects. However, when a building is done somewhere else (typical example, SLA management done in MEF), this L2SM YANG module should only contain a place holder or a pointer.

Fourth. Discussing those very topics live with Scott Mansfield (our MEF - IETF liaison manager) during a workshop recently, we agree that both IETF and MEF service models have a place. While we start to see some consolidation in terms of YANG modules for device management, we are only at the beginning of YANG service modules.

I hope this is useful and that it clarifies the situation.

Regards, Benoit
Hi,

Our charter mandates that we consider basing our work on
draft-wen-l2sm-l2vpn-service-model-03.txt

As we discussed in the meeting, that draft is not perfect. But when I asked the
room whether we thought that it would provide a good starting point that we
could work with to polish and adapt to become the I-D that we ultimately submit
for publication as an RFC, I believe I heard a good hum in favour and silence in
opposition.

So this email starts a formal poll for adoption. Please answer:

Do you think that the WG should adopt draft-wen-l2sm-l2vpn-service-model-03.txt?

If "yes," it would help if you could indicate whether you have read the draft
and how happy you are with it.
If "no", it is important that you provide reasons.

This poll will last for two weeks, ending on Saturday 3rd December.

Just to reassure everyone that adoption does not imply that anything is set in
stone: we expect the WG to continue to develop the content and change whatever
needs to be changed.

Thanks,
Adrian and Qin

_______________________________________________
L2sm mailing list
L2sm@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm
.

--------------E939A49732DC794D9650F941-- From nobody Mon Dec 26 09:55:15 2016 Return-Path: X-Original-To: l2sm@ietf.org Delivered-To: l2sm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9F2128E19; Mon, 26 Dec 2016 09:51:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148277467755.6364.8291014093432013335.idtracker@ietfa.amsl.com> Date: Mon, 26 Dec 2016 09:51:17 -0800 Archived-At: X-Mailman-Approved-At: Mon, 26 Dec 2016 09:55:14 -0800 Cc: Mahesh Jethanandani , L2VPN Service Model Discussion List , Scott Mansfield , Joel Jaeggli , Raghu Ranganathan , Benoit Claise , adrian@olddog.co.uk, Qin Wu Subject: [L2sm] New Liaison Statement, "Response to your liaison dated 31st October 2016" X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2016 17:51:17 -0000 Title: Response to your liaison dated 31st October 2016 Submission Date: 2016-12-26 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1501/ From: "Adrian Farrel" To: rraghu@ciena.com liaisons@mef.net Cc: Joel Jaeggli ,Adrian Farrel ,Benoit Claise ,Qin Wu ,Raghu Ranganathan ,L2VPN Service Model Discussion List ,Scott Mansfield ,Mahesh Jethanandani ,, Response Contacts: Adrian Farrel ,Qin Wu Technical Contacts: adrian@olddog.co.uk Purpose: In response Referenced liaison: Liaison to IETF on proposed Working Group on L2SM (https://datatracker.ietf.org/liaison/1498/) Body: Thank you for your liaison message of 31st October this year addressed to the IESG and OPS Area Directors. Since your liaison, the Layer 2 VPN Service Model (L2SM) working group has been formed by the IESG. This happened right after the L3SM working group succeeded in its goal of describing an L3VPN service as a data model by documenting it in the YANG modeling language. You can see the new working group's charter at https://datatracker.ietf.org/wg/l2sm/charter/ and the product of the L3SM working group at https://datatracker.ietf.org/wg/l3sm/documents/ The L2SM working group met for the first time at IETF-97 in Seoul during November and had a lively discussion about its work including the issues of terminology, functional boundaries, and potential overlap with or use of MEF work. You can see the meeting materials and draft minutes at https://datatracker.ietf.org/meeting/97/materials/ by searching for "L2SM". Both Mahesh Jethanandani and Scott Mansfield were in the room during the meeting and can probably give you their views on what happened. L2SM will follow the same path as was taken for L3SM, and is tasked to do something similar to L3SM. Your liaison message is most helpful in pointing out and supplying copies of existing and on-going MEF work related to the task of the L2SM working group, and the fact of you making available log-in details and material for your work-in-progress is very much appreciated. You asked a specific question in your communication: > Is the focus of L2SM about the internal network technologies and > implementations as opposed to "characteristics of the service as > discussed between the operators and their customers"? The answer is the latter (although it should be noted that there is some debate about whether "operator" or "service provider" is the correct term). Through the discussion during the meeting and on the list, we believe a suitable point of differentiation between MEF and L2SM is that MEF has worked on CE-based models while L2SM will work on PE-based models. PE-based models necessarily include a number of technology-specific details and will focus on the networking aspects of the service while still keeping the realisation of the service within the provider's network as technology agnostic. Furthermore, while the MEF clearly embraces all aspects of the LSO architecture including billing, SLA, order management, life-cycle management, etc, the L2SM working group is tasked to do something much smaller: a self-contained service YANG module similar to tat produced for L3SM. While it would be nice to fit the L2SM work into the MEF LSO architecture, it appears that L2SM follows a different architectural approach, and that there is no value in trying to "fit a square peg in a round hole" by trying to force a match of the functions across the two approaches. This does not invalidate either approach, but only observes that they are different. The working group has so far been clear in its intent to, where possible and consistent with its own work, re-use by reference any relevant existing material such as that developed by the MEF Forum. So far it has identified SLAs, QoS, and Billing as components that may very well be candidates for such re-use. At the moment, the working group is at a very early stage. We welcome participation by all interested parties, but in particular by service providers and service customers since they are the principal users of the YANG model under construction. Participation is open to all via the mailing list https://www.ietf.org/mailman/listinfo/l2sm. We wish you well with your January meeting. Qin Wu and Adrian Farrel L2SM Working Group Chairs Attachments: No document has been attached From nobody Mon Dec 26 11:59:29 2016 Return-Path: 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 0C8331294AD; Mon, 26 Dec 2016 11:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01] 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 LhV5srx7jMxk; Mon, 26 Dec 2016 11:59:25 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A5E1296EF; Mon, 26 Dec 2016 11:59:24 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uBQJxItR005541; Mon, 26 Dec 2016 19:59:18 GMT Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id uBQJxDbo005507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 26 Dec 2016 19:59:14 GMT From: "Adrian Farrel" To: "'Benoit Claise'" , References: <0d4501d24132$62ceb590$286c20b0$@olddog.co.uk> <5b6dbba2-d283-8c81-7aaa-152d05ebdb8c@cisco.com> In-Reply-To: <5b6dbba2-d283-8c81-7aaa-152d05ebdb8c@cisco.com> Date: Mon, 26 Dec 2016 19:59:15 -0000 Message-ID: <003001d25fb2$8a84ebb0$9f8ec310$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01D25FB2.8A88BC40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKr5J3krbFM/YS1TonUwzHGXgh46QGU20fQn1r0KRA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22786.002 X-TM-AS-Result: No--23.828-10.0-31-10 X-imss-scan-details: No--23.828-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCnykMun0J1wpmug812qIbzdsM3mpA5g7JXPwnnY5XL5LQ/ qGZnrEeUYiQZDj0xMK0LAm2pIsyKt0d2G5hiQttMW7gz/Gbgpl4g0L4Xy2OHlbTrab10uqrnvL4 BuAuBsSnzYbug6chYNpbrFFwxb/fFehHR0rDYUtlgP1dNF1ow7R3vBjCQ8n+aRfmFzyKgHb7Akt gDJtZ0Ahuxq0/oHJphycSs9fVCfPRiqZR3e04StWgws6g0ewz2xBgaBynd2vm7qpOHKudqcwAit k7O303Nw4fpofXJzEm66rswlFLG/hBvv3WDz+O1qVdeuk7LerSdtHUoZpvleVfXgfL55invWXOj 3NIpqIr9I7SBHKlogDYA74Rvb6PfxxsF7SoDQIrcWo5Vvs8MQjTbofuc5kuvFJfW7wEu1kAGvzV mOA+OnSmYSq0UBiOoXPhLslnt+0sTY/HRCFabdKfXIl6Cf6Vr1fb4QERdWcDn0eNPmPPe5GmKT/ 2E8HDdZ953sefdXw3Y2grEqMmU0BJkI6WLdk0QsyNb+yeIRArSde/CNbaZJVIEge/2lT8Ar5cH6 L5+Gu/a5HpFN+Z3QaqXbbImsVMS7K35r0y1/56sDodw9yUkxq+LpFmmk3oAs/G/Xv+uK7907+2Q NMSDJFLEWNgJk5q7uOwi+0htYJFd/pNkIrEbEQArNgt5xpQYQrO4XR6BRQMVhrI1wflQjNkKUuy Iqarg+QeHvtsdEokcGy6+e6SNEsAQ0nRNv2K2FyqkfsPWu1ATbU1KYGoQp0iO8DX9hL7R6Tbrq1 sb9rbOwIq0vD8WyFQjKY/I2E1dVcszrzmwgFmeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMlezI0tDTMokcsQPR+jpDgPpY5twODUF6GOWcfOgA+pp+3BndfXUhXQ== Archived-At: Cc: l2sm-chairs@ietf.org Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Dec 2016 19:59:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0031_01D25FB2.8A88BC40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Thanks Benoit for your email and clarifications. Here is my take on where we are and what needs to happen. [tl;dr -- Adoption poll remains open; please review and comment; authors continue work] I think we didn't get enough momentum or support for adoption of this document. At the moment I can't tell whether this resulted from no one caring or from people refraining from commenting after the very strong opposition expressed by David. Having read and re-read David's email I believe he expresses clearly why he thinks the current draft is not suitable for adoption, and offers two suggestions for alternative approaches, but he neither points at not volunteers for work to support those alternatives. Therefore, it seems to me that we still only have one draft on the table. We can either work with that draft or give up. I think it would be unfortunate to abandon the working group when we have a number of operators who believe it is a good idea and who have put in a lot of effort. So I would like to see us move forward with what we have and adapt it as necessary. To do that, however, I think the chairs need to hear more voices in support. I do, however, want to revisit some of the points made in Seoul and by David: 1. This document should not include protocol-specific details. It is my view that when a PE-mode VPN is being discussed the service offered includes the CE-PE link (access circuit) and the technology details of that link must be represented in the service model. Clearly when the service is a CE-mode VPN those details don't apply. In Seoul, we received an offer to go through the current document and flag the protocol parameters that are a concern. I hope that this can be done so that those of us who don't think there is a problem can better understand what the concern is. 2. We should not redevelop work already done by the MEF I could not agree more, and it seems that the authors of the draft in hand have adopted a similar philosophy intending to point at (or provide containers for) at least QoS, SLA, and billing models developed by the MEF. On the other hand, attempts to map this service modelling approach into the MEF LSO architecture have not been entirely successful (with lots of differing opinions and some suggestions that parts of multiple LSO reference points are captured in this model). That suggests to me that what is going on in L2SM is closer to a parallel with L3SM than a duplication of MEF work. It may be a different approach or a different thing. As Benoit said in Seoul (quoting from the minutes) and applying to both of these points: > Don't want this WG to do too much. The MEF already > working on SLA. This model can point to that. This model tries > to be technology agnostic, but if there is some information > needed from the customer then it should be in the model. Bottom line: - The authors of draft-wen-l2sm-l2vpn-service-model-03.txt should continue their work. - Address specific issues raised in Seoul - Revisit all protocol-specific parameters to be sure they are needed - Adding examples in Section 7 would be most helpful to aid others to see how the model is used - Make clearer and more explicit references to use of existing or in- progress MEF work. - The working group should again look at this document and say whether it is currently something that we can use for a starting point for our work. I would particularly like to hear from network operators (service providers) who offer L2VPN services, and from consumers (such as enterprises) who purchase such services. As the chairs said in Seoul, this work really needs to be led by the operators and not dominated by the vendors. Thanks, Adrian From: Benoit Claise [mailto:bclaise@cisco.com] Sent: 22 December 2016 13:44 To: adrian@olddog.co.uk; l2sm@ietf.org; Scott Mansfield Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt Dear all, A couple of reflections on L2SM, just before the end of year break. First, I want to quote one chairs slides https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-chairs-slides-01.pdf: We really need this to be driven by Operators - Of course, vendors can and should participate - But be aware of how the data model is use I'm always baffled when vendors 'seem to) know better than the operators what they need. I don't believe we have spent enough time listening to the few operators in the room during the WG meeting. We have here a group of operators who want to do work in the IETF, and we should respect that. Second, on the differences between IETF and MEF service management. MEF wants to go for the full LSO architecture (billing, SLA, order management, etc.). Perfect. L2SM charter wants to do something similar to L3SM: a self-contained service YANG module. It would be nice to try to fit the L2SM service models in the MEF LSO architecture, but the L2SM work follows a different architectural model to LSO, and that there is no value in trying to match the functions across model at all costs. This should not invalidate either approach, only observe that they are different. Third, exactly like the L3SM draft, the L2SM draft includes a number of technology-specific parameters and these have caused people to claim that the I-D must be describing a normalised or configuration model. But (of course?) the parameters are needed to configure the CE-PE access connections. This is a suitable point of differentiation between MEF and L2SM that MEF has worked on CE-based models while L2SM will work on PE-based models. Indeed, the IETF works on the networking aspects. However, when a building is done somewhere else (typical example, SLA management done in MEF), this L2SM YANG module should only contain a place holder or a pointer. Fourth. Discussing those very topics live with Scott Mansfield (our MEF - IETF liaison manager) during a workshop recently, we agree that both IETF and MEF service models have a place. While we start to see some consolidation in terms of YANG modules for device management, we are only at the beginning of YANG service modules. I hope this is useful and that it clarifies the situation. Regards, Benoit Hi, Our charter mandates that we consider basing our work on draft-wen-l2sm-l2vpn-service-model-03.txt As we discussed in the meeting, that draft is not perfect. But when I asked the room whether we thought that it would provide a good starting point that we could work with to polish and adapt to become the I-D that we ultimately submit for publication as an RFC, I believe I heard a good hum in favour and silence in opposition. So this email starts a formal poll for adoption. Please answer: Do you think that the WG should adopt draft-wen-l2sm-l2vpn-service-model-03.txt? If "yes," it would help if you could indicate whether you have read the draft and how happy you are with it. If "no", it is important that you provide reasons. This poll will last for two weeks, ending on Saturday 3rd December. Just to reassure everyone that adoption does not imply that anything is set in stone: we expect the WG to continue to develop the content and change whatever needs to be changed. Thanks, Adrian and Qin _______________________________________________ L2sm mailing list L2sm@ietf.org https://www.ietf.org/mailman/listinfo/l2sm . ------=_NextPart_000_0031_01D25FB2.8A88BC40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

Thanks Benoit for your email = and clarifications. Here is my take on where we are and what needs to = happen.

 

[tl;dr -- Adoption poll = remains open; please review and comment; authors continue = work]

 

I think we didn't get enough = momentum or support for adoption of this = document.

 

At the moment I can't tell = whether this resulted from no one caring or from people refraining from = commenting after the very strong opposition expressed by = David.

 

Having read and re-read = David's email I believe he expresses clearly why he thinks the current = draft is not suitable for adoption, and offers two suggestions for = alternative approaches, but he neither points at not volunteers for work = to support those alternatives.

 

Therefore, it seems to me that = we still only have one draft on the table. We can either work with that = draft or give up. I think it would be unfortunate to abandon the working = group when we have a number of operators who believe it is a good idea = and who have put in a lot of effort. So I would like to see us move = forward with what we have and adapt it as necessary. To do that, = however, I think the chairs need to hear more voices in = support.

 

I do, however, want to revisit = some of the points made in Seoul and by David:

 

1. This document should not = include protocol-specific details.

It is my view that when a = PE-mode VPN is being discussed the service offered includes the CE-PE = link (access circuit) and the technology details of that link must be = represented in the service model.

Clearly when the service is a = CE-mode VPN those details don't apply.

In Seoul, we received an offer = to go through the current document and flag the protocol parameters that = are a concern. I hope that this can be done so that those of us who = don't think there is a problem can better understand what the concern = is.

 

2. We should not redevelop = work already done by the MEF

I could not agree more, and it = seems that the authors of the draft in hand have adopted a similar = philosophy intending to point at (or provide containers for) at least = QoS, SLA, and billing models developed by the = MEF.

On the other hand, attempts to = map this service modelling approach into the MEF LSO architecture have = not been entirely successful (with lots of differing opinions and some = suggestions that parts of multiple LSO reference points are captured in = this model). That suggests to me that what is going on in L2SM is closer = to a parallel with L3SM than a duplication of MEF work. It may be a = different approach or a different thing.

 

As Benoit said in Seoul = (quoting from the minutes) and applying to both of these = points:

>   Don't want this WG to do = too much. The MEF already

>   working on SLA. This = model can point to that. This model tries

>   to be technology = agnostic, but if there is some information

>   needed from the customer = then it should be in the model.

 

Bottom = line:

 

- The authors of = draft-wen-l2sm-l2vpn-service-model-03.txt should

   continue their work. =

   - Address specific = issues raised in Seoul

   - Revisit all = protocol-specific parameters to be sure they are = needed

   - Adding examples in = Section 7 would be most helpful to aid others to =

     see how = the model is used

   - Make clearer and more = explicit references to use of existing or in-

      = progress MEF work.

 

- The working group should = again look at this document and say whether

   it is currently something = that we can use for a starting point for our = work.

   I would particularly like = to hear from network operators (service = providers)

   who offer L2VPN services, = and from consumers (such as enterprises) who

   purchase such services. = As the chairs said in Seoul, this work really needs = to

   be led by the operators = and not dominated by the vendors.

 

Thanks,

Adrian

 

From: = Benoit Claise [mailto:bclaise@cisco.com]
Sent: 22 December = 2016 13:44
To: adrian@olddog.co.uk; l2sm@ietf.org; Scott = Mansfield
Subject: Re: [L2sm] Adoption poll for = draft-wen-l2sm-l2vpn-service-model-03.txt

 

Dear all,

A couple of reflections on L2SM, just before = the end of year break.

First, I want to quote one chairs slides = https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-= chairs-slides-01.pdf:

We really need this to be driven by = Operators
    - Of course, vendors can and should = participate
    - But be aware of how the data model = is use  

I'm always baffled = when vendors 'seem to) know better than the operators what they need. I = don't believe we have spent enough time listening to the few operators = in the room during the WG meeting.
We have here a group of operators = who want to do work in the IETF, and we should respect = that.

Second, on the differences between IETF and MEF service = management.
MEF wants to go for the full LSO architecture (billing, = SLA, order management, etc.). Perfect.
L2SM charter wants to do = something similar to L3SM: a self-contained service YANG module.
It = would be nice to try to fit the L2SM service models in the MEF LSO = architecture, but the L2SM work follows a different architectural model = to LSO, and that there is no value in trying to match the functions = across model at all costs. This should not invalidate either approach, = only observe that they are different.

Third, exactly like the = L3SM draft, the L2SM draft includes a number of technology-specific = parameters and these have caused people to claim that the I-D must be = describing a normalised or configuration model. But (of course?) the = parameters are needed to configure the CE-PE access connections. This is = a suitable point of differentiation between MEF and L2SM that MEF has = worked on CE-based models while L2SM will work on PE-based models. = Indeed, the IETF works on the networking aspects. However, when a = building is done somewhere else (typical example, SLA management done in = MEF), this L2SM YANG module should only contain a place holder or a = pointer.

Fourth. Discussing those very topics live with Scott = Mansfield (our MEF - IETF liaison manager) during a workshop recently, = we agree that both IETF and MEF service models have a place. While we = start to see some consolidation in terms of YANG modules for device = management, we are only at the beginning of YANG service modules. =

I hope this is useful and that it clarifies the = situation.

Regards, Benoit

Hi,
<= pre> 
Our charter mandates that we consider =
basing our work =
on
draft-wen-l2sm-l2vpn-service-model-03.txt
 
As we discussed in the =
meeting, that draft is not perfect. But when I asked =
the
room whether we thought that it would provide a =
good starting point that we
could work with to =
polish and adapt to become the I-D that we ultimately =
submit
for publication as an RFC, I believe I heard =
a good hum in favour and silence =
in
opposition.
 
So this email starts a formal poll for adoption. Please =
answer:
 
Do you think =
that the WG should adopt =
draft-wen-l2sm-l2vpn-service-model-03.txt?
&nbs=
p;
If "yes," it would help if you could =
indicate whether you have read the draft
and how =
happy you are with it.
If "no", it is =
important that you provide =
reasons.
 
This poll will =
last for two weeks, ending on Saturday 3rd =
December.
 
Just to =
reassure everyone that adoption does not imply that anything is set =
in
stone: we expect the WG to continue to develop =
the content and change whatever
needs to be =
changed.
 
Thanks,
Adrian and =
Qin
 
____________________=
___________________________
L2sm mailing =
list
L2sm@ietf.org
https://www.ietf.org/=
mailman/listinfo/l2sm
.
 

 

------=_NextPart_000_0031_01D25FB2.8A88BC40-- From nobody Tue Dec 27 10:29:13 2016 Return-Path: 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 58FCA1296B2 for ; Tue, 27 Dec 2016 10:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cienacorp.onmicrosoft.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 8MGNY-g86Ro2 for ; Tue, 27 Dec 2016 10:29:08 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0055.outbound.protection.outlook.com [104.47.41.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F33A12948C for ; Tue, 27 Dec 2016 10:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sfl/LYpLpVu6hYXRL5rMr+rSjfurHxwK0taR8G1/OCk=; b=PZfQo3Cw55zc6vLoA0YcfL7BewXkqV5rTfjIRK7SzqZD9Yf4yUQBJCcLiazc2PHVkuKah8KFVraUmheNWfeUKrGVxFa0Y4rtmMeWi4UACyk9UmpHfAUa425zYPoh8VIOncBhxlGDNKcHcJDtPYsPiRFNJh/Bob6hphiABdlyTn4= Received: from MWHPR04MB0385.namprd04.prod.outlook.com (10.173.48.14) by MWHPR04MB0383.namprd04.prod.outlook.com (10.173.48.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 27 Dec 2016 18:29:05 +0000 Received: from MWHPR04MB0385.namprd04.prod.outlook.com ([10.173.48.14]) by MWHPR04MB0385.namprd04.prod.outlook.com ([10.173.48.14]) with mapi id 15.01.0803.021; Tue, 27 Dec 2016 18:29:05 +0000 From: "Ranganathan, Raghu" To: Liaison Statement Management Tool Thread-Topic: New Liaison Statement, "Response to your liaison dated 31st October 2016" Thread-Index: AQHSYB8OVBLFDiJ7QEi17dz8r8urBaEcHfcj Date: Tue, 27 Dec 2016 18:29:05 +0000 Message-ID: References: <148277467755.6364.8291014093432013335.idtracker@ietfa.amsl.com> In-Reply-To: <148277467755.6364.8291014093432013335.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rraghu@ciena.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [25.169.208.4] x-ms-office365-filtering-correlation-id: d60c7c21-cb1b-4c46-5c6e-08d42e863d8e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR04MB0383; x-microsoft-exchange-diagnostics: 1; MWHPR04MB0383; 7:gzXMvqhOJQNRmsb9fXh6bDaDBHcwBbmlYMr3jAN4eP3mbGTR7+L40LEvli/AWIafuAeKXAb0eszNILisA1SmgzJgsSfjtIe5qc6Om8y8e+ek38aocX/Kn0qYKniTqorB00AjFNgxqfqXX37m0hZv5AIAaSNDTSpv6Kwek++/9SuT4OHDaedMe0robAqzY0kzZ+6sUKUoDxEcQVF/YftKAjVMv1JOZk3XRHYOnOREDKluw7iUREcVcammz7ptVOIYi8mRFVuZllwXlm58Csn3URhaDTqpmoUf8lw1/neCffB5hdHIqHhQEZvYg+kPe4e/xGnGGO0y83AEddrSXUHXWjFMiLQyvxRyTtN9O+WE5GT1WU8DAwZJwCeVMSIMGXwIXhkcjEFp14jFFm2Z2SiBhavWKCpaIjvgOF4VyVWNMqcErOihfobEG5sdD5LLgxTUMHX6moo6IJOUXtYVWA3OjQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123558021)(20161123564025)(20161123562025)(6072148); SRVR:MWHPR04MB0383; BCL:0; PCL:0; RULEID:; SRVR:MWHPR04MB0383; x-forefront-prvs: 0169092318 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377424004)(377454003)(199003)(189002)(81156014)(189998001)(81166006)(8676002)(4001150100001)(97736004)(66066001)(5890100001)(50986999)(101416001)(76176999)(54356999)(99286002)(305945005)(106116001)(106356001)(31430400001)(105586002)(5660300001)(68736007)(92566002)(6116002)(102836003)(3846002)(76576001)(38730400001)(2906002)(25786008)(7736002)(6436002)(4326007)(9686002)(6916009)(345774005)(6506006)(77096006)(122556002)(8936002)(74316002)(2900100001)(229853002)(3660700001)(7696004)(86362001)(33656002)(3280700002)(110136003)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR04MB0383; H:MWHPR04MB0385.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR04MB03853ECB0712E2D13E8BBD6FCE690MWHPR04MB0385namp_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2016 18:29:05.6985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR04MB0383 Archived-At: Cc: "liaisons@mef.net" , Mahesh Jethanandani , L2VPN Service Model Discussion List , Scott Mansfield , Joel Jaeggli , Benoit Claise , Adrian Farrel , Qin Wu Subject: Re: [L2sm] New Liaison Statement, "Response to your liaison dated 31st October 2016" X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 18:29:11 -0000 --_000_MWHPR04MB03853ECB0712E2D13E8BBD6FCE690MWHPR04MB0385namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Qin Wu and Adrian, Thanks. I will post it to the attention of our Members. --Raghu (Sent from Phone) From: Liaison Statement Management Tool Sent: Tuesday, December 27, 2:56 AM Subject: New Liaison Statement, "Response to your liaison dated 31st Octobe= r 2016" To: Ranganathan, Raghu Cc: Ranganathan, Raghu, Mahesh Jethanandani, Scott Mansfield, L2VPN Service= Model Discussion List, Benoit Claise, Joel Jaeggli, Adrian Farrel, Qin Wu,= Adrian Farrel Title: Response to your liaison dated 31st October 2016 Submission Date: 20= 16-12-26 URL of the IETF Web page: https://datatracker.ietf.org/liaison/150= 1/ From: "Adrian Farrel" To: rraghu@ciena.com liaisons@mef.net Cc: Joel Jae= ggli ,Adrian Farrel ,Benoit Claise ,Qin Wu ,Raghu Ranganathan ,L2VPN Servic= e Model Discussion List ,Scott Mansfield ,Mahesh Jethanandani ,, Response C= ontacts: Adrian Farrel ,Qin Wu Technical Contacts: adrian@olddog.co.uk Purp= ose: In response Referenced liaison: Liaison to IETF on proposed Working Gr= oup on L2SM (https://datatracker.ietf.org/liaison/1498/) Body: Thank you fo= r your liaison message of 31st October this year addressed to the IESG and = OPS Area Directors. Since your liaison, the Layer 2 VPN Service Model (L2SM= ) working group has been formed by the IESG. This happened right after the = L3SM working group succeeded in its goal of describing an L3VPN service as = a data model by documenting it in the YANG modeling language. You can see t= he new working group's charter at https://datatracker.ietf.org/wg/l2sm/char= ter/ and the product of the L3SM working group at https://datatracker.ietf.= org/wg/l3sm/documents/ The L2SM working group met for the first time at IET= F-97 in Seoul during November and had a lively discussion about its work in= cluding the issues of terminology, functional boundaries, and potential ove= rlap with or use of MEF work. You can see the meeting materials and draft m= inutes at https://datatracker.ietf.org/meeting/97/materials/ by searching f= or "L2SM". Both Mahesh Jethanandani and Scott Mansfield were in the room du= ring the meeting and can probably give you their views on what happened. L2= SM will follow the same path as was taken for L3SM, and is tasked to do som= ething similar to L3SM. Your liaison message is most helpful in pointing ou= t and supplying copies of existing and on-going MEF work related to the tas= k of the L2SM working group, and the fact of you making available log-in de= tails and material for your work-in-progress is very much appreciated. You = asked a specific question in your communication: > Is the focus of L2SM abo= ut the internal network technologies and > implementations as opposed to "c= haracteristics of the service as > discussed between the operators and thei= r customers"? The answer is the latter (although it should be noted that th= ere is some debate about whether "operator" or "service provider" is the co= rrect term). Through the discussion during the meeting and on the list, we = believe a suitable point of differentiation between MEF and L2SM is that ME= F has worked on CE-based models while L2SM will work on PE-based models. PE= -based models necessarily include a number of technology-specific details a= nd will focus on the networking aspects of the service while still keeping = the realisation of the service within the provider's network as technology = agnostic. Furthermore, while the MEF clearly embraces all aspects of the LS= O architecture including billing, SLA, order management, life-cycle managem= ent, etc, the L2SM working group is tasked to do something much smaller: a = self-contained service YANG module similar to tat produced for L3SM. While = it would be nice to fit the L2SM work into the MEF LSO architecture, it app= ears that L2SM follows a different architectural approach, and that there i= s no value in trying to "fit a square peg in a round hole" by trying to for= ce a match of the functions across the two approaches. This does not invali= date either approach, but only observes that they are different. The workin= g group has so far been clear in its intent to, where possible and consiste= nt with its own work, re-use by reference any relevant existing material su= ch as that developed by the MEF Forum. So far it has identified SLAs, QoS, = and Billing as components that may very well be candidates for such re-use.= At the moment, the working group is at a very early stage. We welcome part= icipation by all interested parties, but in particular by service providers= and service customers since they are the principal users of the YANG model= under construction. Participation is open to all via the mailing list http= s://www.ietf.org/mailman/listinfo/l2sm. We wish you well with your January = meeting. Qin Wu and Adrian Farrel L2SM Working Group Chairs Attachments: No= document has been attached --_000_MWHPR04MB03853ECB0712E2D13E8BBD6FCE690MWHPR04MB0385namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Qin Wu and Adrian,
Thanks. I will post it to the attention of our Members.

--Raghu (Sent from Phone)

From: Liaison Statement Management Tool
Sent: Tuesday, December 27, 2:56 AM
Subject: New Liaison Statement, "Response to your liaison dated 31st O= ctober 2016"
To: Ranganathan, Raghu
Cc: Ranganathan, Raghu, Mahesh Jethanandani, Scott Mansfield, L2VPN Service= Model Discussion List, Benoit Claise, Joel Jaeggli, Adrian Farrel, Qin Wu,= Adrian Farrel

Title: Response to your liaison dated 31st October 2016 Submission Date: 20= 16-12-26 URL of the IETF Web page: https://datatracker.ietf.org/liaison/150= 1/ From: "Adrian Farrel" To: rraghu@ciena.com liaisons@mef.net Cc= : Joel Jaeggli ,Adrian Farrel ,Benoit Claise ,Qin Wu ,Raghu Ranganathan ,L2VPN Service Model Discussion List ,Scott Man= sfield ,Mahesh Jethanandani ,, Response Contacts: Adrian Farrel ,Qin Wu Tec= hnical Contacts: adrian@olddog.co.uk Purpose: In response Referenced liaiso= n: Liaison to IETF on proposed Working Group on L2SM (https://datatracker.ietf.org/liaison/1498/) Body: Thank you= for your liaison message of 31st October this year addressed to the IESG a= nd OPS Area Directors. Since your liaison, the Layer 2 VPN Service Model (L= 2SM) working group has been formed by the IESG. This happened right after the L3SM working group succeeded in= its goal of describing an L3VPN service as a data model by documenting it = in the YANG modeling language. You can see the new working group's charter = at https://datatracker.ietf.org/wg/l2sm/charter/ and the product of the L3SM working group at https://datatracker.ietf.org/= wg/l3sm/documents/ The L2SM working group met for the first time at IETF-97= in Seoul during November and had a lively discussion about its work includ= ing the issues of terminology, functional boundaries, and potential overlap with or use of MEF work. You can see the= meeting materials and draft minutes at https://datatracker.ietf.org/meetin= g/97/materials/ by searching for "L2SM". Both Mahesh Jethanandani= and Scott Mansfield were in the room during the meeting and can probably give you their views on what happened. L2SM w= ill follow the same path as was taken for L3SM, and is tasked to do somethi= ng similar to L3SM. Your liaison message is most helpful in pointing out an= d supplying copies of existing and on-going MEF work related to the task of the L2SM working group, and the f= act of you making available log-in details and material for your work-in-pr= ogress is very much appreciated. You asked a specific question in your comm= unication: > Is the focus of L2SM about the internal network technologies and > implementations as oppose= d to "characteristics of the service as > discussed between the ope= rators and their customers"? The answer is the latter (although it sho= uld be noted that there is some debate about whether "operator" or "service provider" is the correct term).= Through the discussion during the meeting and on the list, we believe a su= itable point of differentiation between MEF and L2SM is that MEF has worked= on CE-based models while L2SM will work on PE-based models. PE-based models necessarily include a number of technology-specifi= c details and will focus on the networking aspects of the service while sti= ll keeping the realisation of the service within the provider's network as = technology agnostic. Furthermore, while the MEF clearly embraces all aspects of the LSO architecture includi= ng billing, SLA, order management, life-cycle management, etc, the L2SM wor= king group is tasked to do something much smaller: a self-contained service= YANG module similar to tat produced for L3SM. While it would be nice to fit the L2SM work into the MEF LSO arc= hitecture, it appears that L2SM follows a different architectural approach,= and that there is no value in trying to "fit a square peg in a round = hole" by trying to force a match of the functions across the two approaches. This does not invalidate either appro= ach, but only observes that they are different. The working group has so fa= r been clear in its intent to, where possible and consistent with its own w= ork, re-use by reference any relevant existing material such as that developed by the MEF Forum. So far it has i= dentified SLAs, QoS, and Billing as components that may very well be candid= ates for such re-use. At the moment, the working group is at a very early s= tage. We welcome participation by all interested parties, but in particular by service providers and service= customers since they are the principal users of the YANG model under const= ruction. Participation is open to all via the mailing list https://www.ietf= .org/mailman/listinfo/l2sm. We wish you well with your January meeting. Qin Wu and Adrian Farrel L2SM Working = Group Chairs Attachments: No document has been attached

--_000_MWHPR04MB03853ECB0712E2D13E8BBD6FCE690MWHPR04MB0385namp_--