From nobody Tue Oct 4 12:23:48 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 681AC12944E for ; Tue, 4 Oct 2016 12:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 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=-2.996, 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 vwt6hYA6WgyQ for ; Tue, 4 Oct 2016 12:23:40 -0700 (PDT) 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 E74DB129450 for ; Tue, 4 Oct 2016 12:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49; q=dns/txt; s=iport; t=1475609019; x=1476818619; h=subject:references:to:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Vr81kUj49qnajl6sm+lcfZReylpaqzBn8IemOap6q08=; b=Mf6hIrlcXXIu2tUTe1nkTRck1qjFcS+VBzAd2ooCge1Ew7nnPe8oK0RO g57UjwUIQgtYp1FYFCrukoPoDOvdNhab+8htwM75dzHqol0xMmRnMeZNO yMgCe4NsTakcwVre9L5TVdXU1LLeWupBJTUZUkuWdQs0Q9cQ6dCGLWD3U c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAgBYAPRX/xbLJq1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBgz0BAQEBAYEfjgSrI4IHhhUBCAKCJxQBAgEBAQEBAQFeJ4RiAgQZChVRJQI?= =?us-ascii?q?mAgJXEwgBAYhJsTqMeAEBAQcCJYEHhTWBfYZxEQFogjiCWgEElCCFWY90gVgBi?= =?us-ascii?q?A+GCokgh04eNhomBQeEVTyFbYIgAQEB?= X-IronPort-AV: E=Sophos;i="5.31,444,1473120000"; d="scan'208";a="688698347" 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; 04 Oct 2016 19:23:36 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u94JNa5e015738 for ; Tue, 4 Oct 2016 19:23:36 GMT References: <9511e4ef-cd2d-b3c5-bb4a-42d1ca6df660@cisco.com> To: l2sm@ietf.org From: Benoit Claise X-Forwarded-Message-Id: <9511e4ef-cd2d-b3c5-bb4a-42d1ca6df660@cisco.com> Message-ID: <1e1eb0d9-e897-dc51-e050-8703dd22693d@cisco.com> Date: Tue, 4 Oct 2016 21:23:36 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <9511e4ef-cd2d-b3c5-bb4a-42d1ca6df660@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [L2sm] first email: test 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, 04 Oct 2016 19:23:46 -0000 Hi, This is a first test. Regards, Benoit From nobody Thu Oct 6 09:25: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 33D46129715 for ; Thu, 6 Oct 2016 09:25:55 -0700 (PDT) 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 y2AlcHOMo6DL for ; Thu, 6 Oct 2016 09:25:53 -0700 (PDT) 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 04CC51296CF for ; Thu, 6 Oct 2016 09:25:49 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u96GPcaD008216; Thu, 6 Oct 2016 17:25:38 +0100 Received: from 950129200 (dsl-dp-81-140-96-139.in-addr.broadbandscope.com [81.140.96.139]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u96GPaCq008189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 6 Oct 2016 17:25:37 +0100 From: "Adrian Farrel" To: Date: Thu, 6 Oct 2016 17:25:31 +0100 Message-ID: <063c01d21fee$433ffc30$c9bff490$@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: AdIf7fMs9WzEPb3ERrCofyMyEbe6UQ== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22622.000 X-TM-AS-Result: No--9.071-10.0-31-10 X-imss-scan-details: No--9.071-10.0-31-10 X-TMASE-MatchedRID: pwTEgW5td+3RPzDVklhMnbiMC5wdwKqdI5K4Cd+0ao+ceNzxeuJ3qZc1 qCkooZMTQ87BF4UeCrfmDVJEzjQzH5NPnS9GFVSgSEQN/D/3cG7v6kiVCTIVSkYx760ONDcWIZn pVU5Vh5aiLvBn/MzImj1HDJdScNRYeW+cAT8xD1OGuzokAQvW7p6KYa03LCO2myiLZetSf8nJ4y 0wP1A6AKutWpVAulZH5MIx11wv+CM7AFczfjr/7KZ0I9PvyNFeIXVsqtez7CTBbQPhVr7vIhemu vJu+4Gq/lcQTQc56aQ= Archived-At: Cc: Qin Wu Subject: [L2sm] Welcome message 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: Thu, 06 Oct 2016 16:25:55 -0000 Welcome to L2SM, This list is for discussion of a potential new working group: Layer 2 VPN Service Model. A *draft* charter has been posted at https://datatracker.ietf.org/wg/l2sm/charter/ and is open for discussion and revision. There is also a candidate I-D that has been worked on by some service providers available at https://datatracker.ietf.org/doc/draft-wen-l2sm-l2vpn-service-model/ This is very much a work in progress with new revisions expected between now and IETF-97. If all goes well we hope to meet in Seoul to discuss the draft and open up the work to the community. We are particularly interested in input from the operator community. Thanks, Adrian From nobody Thu Oct 6 11:20: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 8C03A120726; Thu, 6 Oct 2016 11:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 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=-2.996, 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 d290TjRdzU8i; Thu, 6 Oct 2016 11:19:58 -0700 (PDT) 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 54A05129757; Thu, 6 Oct 2016 11:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=833; q=dns/txt; s=iport; t=1475777997; x=1476987597; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=W/b0d9pXBUhEy1grLZImYguPsBc+E0T4zi8gdtgYBvA=; b=W+0hxxBifTISOMx9Pag54oPnUcn+h96PBNhhMx52hTKSdLpQNUnyCfdD hgCtEVATSYW+fu1nLQI5/lNsD3PGM9RQYqcqMmSOiyjdEcfvhc8fsqXAR dOdUOlKqs6++X5IiJA5JHV3N4GLOABzNAXgHSNAVM71+YjzfKrNzJ22nO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgAQC4lPZX/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz0BAQEBAXUqUo0ylwCULIILGwuFegKCLBQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?iAQEEAQEBIBU2CxALGAICCB4CAicwBgEMBgIBAYhKDrIojG0BAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARkFgQeFNYF9CIJQhBkRAYMgglsBBJl/hiiJU4FuhGeDFIYLiSe?= =?us-ascii?q?DUIN/HjY/BQeCZjqBPDw0hiCCIAEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,454,1473120000"; d="scan'208";a="688748373" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Oct 2016 18:19:55 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u96IJt1g025162; Thu, 6 Oct 2016 18:19:55 GMT To: ietf@ietf.org, IETF Announcement List References: <147577007690.16143.4783119820318783360.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <01cced69-802e-7035-5db8-0bcbda4b6fe1@cisco.com> Date: Thu, 6 Oct 2016 20:19:55 +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: <147577007690.16143.4783119820318783360.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: l2sm@ietf.org Subject: Re: [L2sm] New Non-WG Mailing List: L2sm -- The Layer Two Virtual Private Network Service Model (L2SM) 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, 06 Oct 2016 18:20:00 -0000 On 10/6/2016 6:07 PM, IETF Secretariat wrote: > A new IETF non-working group email list has been created. > > List address: l2sm@ietf.org > Archive: https://mailarchive.ietf.org/arch/search/?email_list=l2sm > To subscribe: https://www.ietf.org/mailman/listinfo/l2sm > > Purpose: The Layer Two Virtual Private Network Service Model (L3SM) It should say: Purpose: The Layer Two Virtual Private Network Service Model (L2SM). Now corrected in the mailer. Regards, Benoit > focuses > on the creation of a YANG data model that describes a L2VPN service > (a L2VPN service model) that can be used for communication between > customers and network operators, and to provide input to automated > control and configuration applications. > > For additional information, please contact the list administrators. > . > From nobody Thu Oct 6 11:40:34 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 E43871296FD; Thu, 6 Oct 2016 09:07:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147577007690.16143.4783119820318783360.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 09:07:56 -0700 Archived-At: X-Mailman-Approved-At: Thu, 06 Oct 2016 11:40:34 -0700 Cc: bclaise@cisco.com, l2sm@ietf.org Subject: [L2sm] New Non-WG Mailing List: L2sm -- The Layer Two Virtual Private Network Service Model (L2SM) X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 06 Oct 2016 16:07:57 -0000 A new IETF non-working group email list has been created. List address: l2sm@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=l2sm To subscribe: https://www.ietf.org/mailman/listinfo/l2sm Purpose: The Layer Two Virtual Private Network Service Model (L3SM) focuses on the creation of a YANG data model that describes a L2VPN service (a L2VPN service model) that can be used for communication between customers and network operators, and to provide input to automated control and configuration applications. For additional information, please contact the list administrators. From nobody Thu Oct 6 11:40:42 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 188FE12975B; Thu, 6 Oct 2016 11:36:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147577896809.23938.14167603819369280701.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 11:36:08 -0700 Archived-At: X-Mailman-Approved-At: Thu, 06 Oct 2016 11:40:34 -0700 Cc: bclaise@cisco.com, l2sm-chairs@ietf.org, smccammon@amsl.com, l2sm@ietf.org Subject: [L2sm] l2sm - New Meeting Session Request for IETF 97 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: Thu, 06 Oct 2016 18:36:12 -0000 A new meeting session request has just been submitted by Stephanie McCammon, on behalf of the l2sm working group. --------------------------------------------------------- Working Group Name: L2VPN Service Model Area Name: Operations and Management Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: opsawg netmod netconf i2nsf bess pals idr rtgwg Special Requests: --------------------------------------------------------- From nobody Mon Oct 10 05:27:18 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 79E76129610 for ; 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 ; 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 ; 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 ; 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 ; 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 ; 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)" To: "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: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 YAN= G > models for network element and protocol onfiguration. This is an essentia= l first Nit: s/onfiguration/configuration/ > step, but the end goal is full system configuration that enable service a= gility > to speed service creation and delivery and allows the deployment of innov= ative > new services across networks. Services are built from a combination of ne= twork > 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 custom= ers 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 netwo= rk architectures? > network operators, and to provide input to automated control and configur= ation > applications. The working group will attempt to derive a single data mode= l that > includes support for point-to-point Virtual Private Wire Services (VPWS) = and > multipoint Virtual Private LAN services (VPLS) that use Pseudowires signa= led > using the Label Distribution Protocol (LDP) and the Border Gateway Protoc= ol > (BGP) as described in RFC4761 and RFC6624. To me, "includes support for" is not a very specific wording. Will the deli= verable of a working group be limited to VPWS and VPLS? If yes, why not sta= te 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 conta= ins the > characteristics of the service as discussed between the operators and the= ir > customers. A separate process is responsible for mapping this service mod= el 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 evalu= ate the > set of YANG models that have already been developed or are under developm= ent, 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 dr= aft-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 oth= er IETF WGs. This sentence could be understood as an evaluation and gap ana= lysis 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 t= he > 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 ma= naged 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 grou= p and > it is expected that the L2SM data model will have similar structure to th= e L3SM > data model. I am not sure what the first part of this sentence would imply? Unless it i= s spelt out what these lessons learnt are, I think it can be removed. The c= harter wording of L2SM itself may obviously leverage lessons learnt from L3= SM ;-) The second part of the sentence results in quite a number of constraints re= garding the model design. I think this warrants a dedicated sentence, and p= ossibly 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 f= or > 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-mo= del includes the following sentence: "Rather than introducing a new set of = terminologies, the L2SM will align with existing MEF attributes when it's a= pplicable." That wording may be a starting point. Albeit the question is wh= ether some sort of liaison would be limited to terminology reuse only. Also, I wonder if MEF is really the only other relevant standardization bod= y for L2VPNs. >From an implementer's perspective, lack of alignment between standardizatio= n 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 L= 3SM didn't have to consider e.g. other standardization bodies... Thanks Michael From nobody Tue Oct 11 01:55:48 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 482E11295F6 for ; Tue, 11 Oct 2016 01:55:47 -0700 (PDT) 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 jOdQ5QBQ4Lw4 for ; Tue, 11 Oct 2016 01:55:44 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490031295F8 for ; Tue, 11 Oct 2016 01:55:43 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9B8teFt015673; Tue, 11 Oct 2016 09:55:40 +0100 Received: from 950129200 (107.99.200.146.dyn.plus.net [146.200.99.107]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9B8tdPc015629 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2016 09:55:40 +0100 From: "Adrian Farrel" To: "'Scharf, Michael \(Nokia - DE\)'" , References: <655C07320163294895BBADA28372AF5D48AE8AEE@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48AE8AEE@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Tue, 11 Oct 2016 09:55:38 +0100 Message-ID: <0c1f01d2239d$3d98fe00$b8cafa00$@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: AQHSL1hpGJNIX7Ubrhppm3Lchr8OL6ChzweA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22630.005 X-TM-AS-Result: No--24.226-10.0-31-10 X-imss-scan-details: No--24.226-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtFqJ1y0VLNhDvHkpkyUphL9fkuZtv/FS5ok4mHxl56uoTpI hhonTuyPwEQUFc9DW+p2TdMGhtDwkHLFfK847zViYD9XTRdaMO3MkdpJzbMUEZ722hDqHosTl0Q OeyQOr5aDs5wCilw3pvgUJC7eeNvUIwcT1+JwmfkR0Wxq9RAoB0Crr/LkAQ46N5MweVYx4nPwlk QTCImQ1iox7EaiAex/f2hXVkB0xQNOl2U7KP8K+YlmrWVDo+jr4b+uxQ/rA9b+7KZICEbEstEsc e2q1YBxUVEoq3zZyJNpvP576cmHxVUOzv+ERMvrVCdVHe0/FP74uJ1REX4MHSOLgGNGKq09UERR bb9D/2SaBYkYvXyB2JoI7wuYym4xusJ9aDYpDbwuLk8NfSpYei2ROkkJykWDanAotzDzATZnLab I67VZfP+8jJSdT/tR8LtGviKVkTUqan1mnGyLa6DKPaVrGhelzJmqByfAaS3428K/caKTzy+RlK pTJ8VeCHJo7ta/UhUUpJWR65gtD5AUd3RwaM3HA9GEZfTBPeWhSP4ToSntololpxQb2cwlVWgYd lhHXLEcOISwwBw6f0JeCpTVcKp1QyNrw2ay5cZ5TJVlfiK+u7Q0n3DEfu2TlRDMdYEo4UCakfDM pROBkvKVG1c3L1qfi3ug77cCOTIEaWdDwEtJ5vKTUscHwZBb0w14HFJQjaPKY//WmIj/oWj+be3 xqTi59RzkM0/MzhNyx6j6IqCJlLtTC+IyK7OhaK+MsTwM+1mP/EshoNKyEWAVT+Skopy8ezYC/k iT9SZckfCAECj1Gugjtd30JF+k9x0Dj5eS6pueAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= Archived-At: Subject: Re: [L2sm] L2SM charter proposal 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: Tue, 11 Oct 2016 08:55:47 -0000 Hello Michael, > I am not sure where the charter wording on > https://datatracker.ietf.org/wg/l2sm/charter/ has been discussed. Anyway, I had > a look... Don't think it has. I think the creation of this list gives us all the chance, and it seems like you took it correctly :-) Looking at the status of the charter, it hasn't been to the IESG yet, and after that it will go to the whole IETF. So now is not a bad time for discussions. > > 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? Yeah. You're right that there was a lot of discussion and confusion about what a service model is. Qin Wu, Will Liu, and I wrote draft-wu-opsawg-service-model-explained to try to get some consensus around the different meanings. But that document is not a WG document (yet?) and certainly can't claim to have consensus. So I see the problem, but I don't see a solution. To me (of course) it is clear what a "service model" is. Is there a form of words that you would find helpful to scope the L2SM work to the same type of "service model" that L3SM addressed? > > 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? I read this as: - MUST include VPWS and VPLS - MAY include other things The text could be clearer. Which way would you like it to go: exclusive or inclusive? > BTW, that long sentence is hard to parse. Agree. > > It needs to be clearly understood that this L2VPN service model is not an L2VPN > > 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. Hmmm, I do not believe that L3SM was chartered to provide that evaluation. Instead (and as you note, exactly as the text is proposed for L2SM) the charter states: |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. I took this to mean that the L3SM could be used by those working on models "lower down the stack" (such as in BESS, RTGWG, IDR, etc.) to see whether they had captured all of the details that would be needed to deliver the services that operators want to sell to customers. Looked at another way, implementers building automated service delivery systems (who might want to support L3SM or some proprietary variant) would use L3SM to determine whether they could map a customer's service request to the YANG models that are used within the network to deliver the service. I'm not aware of this work having been done in a public forum, however, since there are implementations of L3SM, I assume that the work has been done and that perhaps some of the changes proposed to other models over time have arisen have come from this work. > 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. I think that is exactly the correct understanding. The question is, however, who does that gap analysis. As I say, I don't think the L3SM WG was asked to do the analysis, and this charter text is not asking a potential L2SM WG to do that. Gap analyses are, IMHO, best done by the people who propose to fill the gaps not by an "external authority" that might try to instruct someone else to fill the gaps. > > 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? As above. > > 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 benefits of aligning structure with L3SM would seem to be: - a "service orchestrator" could use common or similar code - customers will have familiarity across services - there is future potential to generalise into a common service model - discussions that led to the L3SM structure are not repeated leading to more rapid development Other models with which L2SM might align are presumably the service delivery models being worked on in BESS. There is absolutely value in looking at these models, but they are technology specific and it is risky to force the service as offered by the operator to be too dependent on how the network is operated. Orchestration and mapping will be required. > > 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. I agree that the relationship with MEF will be very important. Liaison relationships are created and maintained by the IAB. In the absence of such a relationship a WG can only communicate and coordinate. > Also, I wonder if MEF is really the only other relevant standardization body for > L2VPNs. Ah, that's important. Which other bodies or forums have you got in mind? >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... When have WG milestones ever not been ambitious? . But you make a good point. L3SM was close to its dates until it hit the tail. It had a very long tail and I do know why except that perhaps the largest volume of review comments didn't come until right at the end of the work - perhaps a feature of caring about the output but not caring to contribute to the development? Anyway, that is my $0.02 to add to yours. Hopefully the AD is listening. Cheers, Adrian From nobody Tue Oct 11 04:18:35 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 9A0731294EE for ; Tue, 11 Oct 2016 04:18:34 -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 A-13uncKa2hi for ; Tue, 11 Oct 2016 04:18:32 -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 032AA1294E7 for ; Tue, 11 Oct 2016 04:18:32 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 9E26EFD7EB60F; Tue, 11 Oct 2016 11:18:27 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9BBIToL017236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2016 11:18:30 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u9BBI45j015412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Oct 2016 13:18:29 +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; Tue, 11 Oct 2016 13:18:25 +0200 From: "Scharf, Michael (Nokia - DE)" To: "adrian@olddog.co.uk" , "l2sm@ietf.org" Thread-Topic: [L2sm] L2SM charter proposal Thread-Index: AdIi8Z34b8Gws0BeT72D6VuLqSadbAAmtsMAAAZR2lA= Date: Tue, 11 Oct 2016 11:18:24 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48AEBA0D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D48AE8AEE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0c1f01d2239d$3d98fe00$b8cafa00$@olddog.co.uk> In-Reply-To: <0c1f01d2239d$3d98fe00$b8cafa00$@olddog.co.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 11:18:34 -0000 Inline... > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, October 11, 2016 10:56 AM > To: Scharf, Michael (Nokia - DE); l2sm@ietf.org > Subject: RE: [L2sm] L2SM charter proposal >=20 > Hello Michael, >=20 > > I am not sure where the charter wording on > > https://datatracker.ietf.org/wg/l2sm/charter/ has been discussed. Anywa= y, I > had > > a look... >=20 > Don't think it has. I think the creation of this list gives us all the ch= ance, > and it seems like you took it correctly :-) >=20 > Looking at the status of the charter, it hasn't been to the IESG yet, and > after > that it will go to the whole IETF. So now is not a bad time for discussio= ns. >=20 > > > The Layer Two Virtual Private Network Service Model (L2SM) working gr= oup > is > a > > > short-lived WG tasked to create a YANG data model that describes a L2= VPN > > > service (a L2VPN service model) that can be used for communication be= tween > > > 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 netwo= rk > > architectures? >=20 > Yeah. You're right that there was a lot of discussion and confusion about= what > a > service model is. >=20 > Qin Wu, Will Liu, and I wrote draft-wu-opsawg-service-model-explained to = try > to > get some consensus around the different meanings. But that document is no= t a > WG > document (yet?) and certainly can't claim to have consensus. >=20 > So I see the problem, but I don't see a solution. To me (of course) it is > clear > what a "service model" is. Is there a form of words that you would find > helpful > to scope the L2SM work to the same type of "service model" that L3SM > addressed? I think the charter could use the term "customer service model". We can cer= tainly argue whether this is the best term, but to me it is better than "se= rvice model".=20 > > > applications. The working group will attempt to derive a single data = model > that > > > includes support for point-to-point Virtual Private Wire Services (VP= WS) > 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? >=20 > I read this as: > - MUST include VPWS and VPLS > - MAY include other things >=20 > The text could be clearer. Which way would you like it to go: exclusive o= r > inclusive? I think a better alternative would be to list examples what MAY be included= as well, provided there is WG consensus etc. But under the assumption that= this WG shall be driven by operators, I suspect it is up to them to decide= . Potential implementations could probably deal with L2VPN services beyond VP= WS and VPLS. Having a common base model could have benefits. > > BTW, that long sentence is hard to parse. >=20 > Agree. >=20 > > > It needs to be clearly understood that this L2VPN service model is no= t an > L2VPN > > > 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 ind= eed > > delivered an evaluation of existing YANG models? Also, I am not sure ho= w > draft- > > wen-l2sm-l2vpn-service-model addresses this requirement. >=20 > Hmmm, I do not believe that L3SM was chartered to provide that evaluation= . > Instead (and as you note, exactly as the text is proposed for L2SM) the > charter > states: >=20 > |The deliverable from this working group will provide information to eval= uate > the set of > |YANG models that have already been developed or are under development, a= nd > will > |help identify any missing models or details. The deliverable can be view= ed as > driving > |requirements for protocol configuration model so that the service parame= ters > can be > |mapped into inputs used by the protocol models. >=20 > I took this to mean that the L3SM could be used by those working on model= s > "lower down the stack" (such as in BESS, RTGWG, IDR, etc.) to see whether= they > had captured all of the details that would be needed to deliver the servi= ces > that operators want to sell to customers. Looked at another way, impleme= nters > building automated service delivery systems (who might want to support L3= SM or > some proprietary variant) would use L3SM to determine whether they could = map a > customer's service request to the YANG models that are used within the ne= twork > to deliver the service. >=20 > I'm not aware of this work having been done in a public forum, however, s= ince > there are implementations of L3SM, I assume that the work has been done a= nd > that > perhaps some of the changes proposed to other models over time have arise= n > have > come from this work. If that sort of work is expected to happen outside the L2SM WG, I wonder wh= y the charter needs wording on it. Or if it is expected to happen inside the L2SM WG, maybe a process differen= t to L3SM would be needed? I may be fine either way but I think a charter should have clear wording. > > 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 IE= TF > WGs. > > This sentence could be understood as an evaluation and gap analysis of > existing > > YANG models. >=20 > I think that is exactly the correct understanding. > The question is, however, who does that gap analysis. > As I say, I don't think the L3SM WG was asked to do the analysis, and thi= s > charter text is not asking a potential L2SM WG to do that. For L2SM there are comparable modeling activities in other standardization = bodies, in open source projects (e.g., for orchestrators), etc. When L3SM w= as chartered, I think related work was less mature. So, the situation regar= ding a gap analysis is not exactly the same. I think the charter should clearly explain whether a gap analysis is to be = performed by the WG, or not. If the WG is not asked to perform a gap analys= is, I think the charter wording can be cleaned up accordingly. =20 > Gap analyses are, IMHO, best done by the people who propose to fill the g= aps > not > by an "external authority" that might try to instruct someone else to fil= l the > gaps. >=20 > > > and will help identify any missing models or details. The deliverable= can > be > > > viewed as driving requirements for protocol configuration model so th= at > the > > > service parameters can be mapped into inputs used by the protocol mod= els. > > > > Again, I wonder if this WG really plans to deliver this? Has L3SM reall= y > managed to > > provide good requirements for parameter mapping, e.g., for the non-triv= ial > > service parameters such as QoS? >=20 > As above. >=20 > > > 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 structu= re 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 chart= er > wording > > of L2SM itself may obviously leverage lessons learnt from L3SM ;-) > > > > The second part of the sentence results in quite a number of constraint= s > > regarding the model design. I think this warrants a dedicated sentence,= and > > possibly even some further discussion on the priority of aligning struc= ture > with > > L3SM vs. aligning with other YANG models. >=20 > The benefits of aligning structure with L3SM would seem to be: > - a "service orchestrator" could use common or similar code > - customers will have familiarity across services > - there is future potential to generalise into a common service > model > - discussions that led to the L3SM structure are not repeated > leading to more rapid development I agree that there could be benefits and therefore I think this design obje= ctive should be stressed. BTW, this argument does not apply to VPWS and VPL= S only, as orchestrators may not be limited to that sort of services only. > Other models with which L2SM might align are presumably the service deliv= ery > models being worked on in BESS. There is absolutely value in looking at t= hese > models, but they are technology specific and it is risky to force the ser= vice > as > offered by the operator to be too dependent on how the network is operate= d. > Orchestration and mapping will be required. > > > > The working group should consider draft-wen-l2sm-l2vpn-service-model = as a > > > starting point. > > > > > > The working group will coordinate with other working groups responsib= le > for > > > L2VPN protocol work (most notably with BESS and PALS) and with the ME= F. > > > > 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 wo= rks > on > > quite related YANG models. For instance, draft-wen-l2sm-l2vpn-service-m= odel > > 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. >=20 > I agree that the relationship with MEF will be very important. > Liaison relationships are created and maintained by the IAB. > In the absence of such a relationship a WG can only communicate and > coordinate. >=20 > > Also, I wonder if MEF is really the only other relevant standardization= body > for > > L2VPNs. >=20 > Ah, that's important. > Which other bodies or forums have you got in mind? I don't follow IEEE and BBF, but both have Ethernet YANG modeling activitie= s. Couldn't this matter? And, as far as I know, MEF has liaisons with TMF, ONF, ITU-T, etc. on custo= mer service models. Is there no need to look into this? As L2VPNs are covered by multiple organizations, I'd really like to underst= and how the IAB plans to handle this. Wouldn't a charter be a good place to= provide some guidance to the WG? > >From an implementer's perspective, lack of alignment between standardiza= tion > > 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. A= nd > L3SM > > didn't have to consider e.g. other standardization bodies... >=20 > When have WG milestones ever not been ambitious? . > But you make a good point. L3SM was close to its dates until it hit the t= ail. > It > had a very long tail and I do know why except that perhaps the largest vo= lume > of > review comments didn't come until right at the end of the work - perhaps = a > feature of caring about the output but not caring to contribute to the > development? This is normal WG business. I am more concerned about the impact of externa= l dependencies. Michael =20 > Anyway, that is my $0.02 to add to yours. > Hopefully the AD is listening. >=20 > Cheers, > Adrian From nobody Wed Oct 12 00:13:06 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 A532012947E for ; Wed, 12 Oct 2016 00:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 OjenjbYuABy2 for ; Wed, 12 Oct 2016 00:13:03 -0700 (PDT) Received: from BAY004-OMC2S17.hotmail.com (bay004-omc2s17.hotmail.com [65.54.190.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81044129421 for ; Wed, 12 Oct 2016 00:13:03 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com ([65.54.190.124]) by BAY004-OMC2S17.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 12 Oct 2016 00:13:03 -0700 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=QigS8ZHRpVHYuFWQL3QBoUKDPJcPKcbC9FcU/lRT51I=; b=B8szzt6xyd7tqXCXG2RFBmP3PeWhZlZ03yIVR6U5Ui8rLNBlxu8AgqwXjsB4FnjNEx4RS/fgkFbkWmGeHU6/gj2nCAwUXxIX+aCMy9ConsEtDE96qRbK4fPT+OFfoeRehl6JDVpVowhDNFihkqYkuVXEcuFtdNkzOPNK/4LKn89N411cuJWa1/tVzOy/91bxeMrHK083e82WRWPrAo1XI4Duj+v/RcR7F2/rNsArCr7ROLCMcZDuj5mOzP2oiaUm+Br+DTR6YqBYWV+FC98gP1hjWj+n3JOTqJO6aUef0eZojoZHe+kS6VyGboF6sWbb30OVSq0UAOb/T6OSnj+ChA== Received: from HK2APC01FT032.eop-APC01.prod.protection.outlook.com (10.152.248.58) by HK2APC01HT211.eop-APC01.prod.protection.outlook.com (10.152.248.239) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5; Wed, 12 Oct 2016 07:13:00 +0000 Received: from KL1PR0201MB1656.apcprd02.prod.outlook.com (10.152.248.59) by HK2APC01FT032.mail.protection.outlook.com (10.152.248.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.5 via Frontend Transport; Wed, 12 Oct 2016 07:12:59 +0000 Received: from KL1PR0201MB1656.apcprd02.prod.outlook.com ([10.167.58.150]) by KL1PR0201MB1656.apcprd02.prod.outlook.com ([10.167.58.150]) with mapi id 15.01.0659.020; Wed, 12 Oct 2016 07:12:59 +0000 From: =?gb2312?B?ucsgyNY=?= To: "l2sm@ietf.org" Thread-Topic: [L2sm] L2SM charter proposal Thread-Index: AQHSJFcqBaX0p7+KvUi7UmWASOd//w== Date: Wed, 12 Oct 2016 07:12:59 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=outlook.com; x-tmn: [8tmA9uL4d3gjapYbIAgrQ0clNzj8qfQX] x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; HK2APC01HT211; 6:XZjpz3lkAXwNB1B4Eg1PB1ughOkwh+okhRMLCRzMc+fFs2mIbu3wloLIDZqf+g6JpmM92Y66wOjw7UHxdZpCOLTSk14nKPWVa0XR69djxWyOgMYCWHS+cqmVzJAZdxB6Nh8F/aqBKLtHeWkLONiI0TjQtabi55ovWuR28ZGN+I6zTiJGue7ctS0zJgdunJP7kpTozQ/1tgccrk/KzQbLm8y4VNFCQvtWdfxy6pCfxS5LBKDkrvgytaThA2z34MzdtUah2qfYyHx8w1qMYNle7x/AEADDVtcfYwM2yAbg+20=; 5:HE/91BMyC6j1z5D65Mn7qeHoTelPvrjOfzDpQtGFu2xb5e0YXYbw3vEpjMedCnWIiEUNdc7ozReVv7uNJXi/leXDC7U6H7j3Eya/Az1rnQ5YmfdurMS9P7BTCs+Gv+I5GeKOUTq/q2Fg+ud+m6qSUw==; 24:IYIN/A67sRoIDV70wFVYnIqOVQwDkG6mixDHs5/0WBIbLHNqnQ6yhRokLXDW/H5+qN8a7Eu1MbPNSEU/C5Hg3xlkT6DOzBP8XyGCzgzivm8=; 7:DK/8tO+Mm0abCkXmnTK690DX9WySzREHBoOVJeVd4Y0eaf3nz2M0qcyu9L4ztbvElVHNdaX9XHGtCC3XCGmOjMo1AvE9AY4RSQ/4z27Zj4lG+XTM+ioBJ7O3CFv1HSsvxxnkAdoCgI0zNEspbhp0UYsSIbWSMGj3z5HLlMREGKegKeUEXvGqgJ6WGM2kSUinYlw/rmqltE+SxW9vwfgRLTn4yG099QQn+OoLlACkImThK+36LUbqMchicyUW80w3P5ClkE6FSGojNl+SRvbHDvwodr9Tii7ns7tieQ8zl1U2SMb8a9NGaZ0Mmf/tMIiv66FBJAE3VpGqeViWQG2YrQ== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:HK2APC01HT211; H:KL1PR0201MB1656.apcprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: b54bc7b9-4b98-4852-f038-08d3f26f32d9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:HK2APC01HT211; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:HK2APC01HT211; BCL:0; PCL:0; RULEID:; SRVR:HK2APC01HT211; x-forefront-prvs: 0093C80C01 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_KL1PR0201MB16567B11096AB45D66528A458BDD0KL1PR0201MB1656_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 07:12:59.4844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT211 X-OriginalArrivalTime: 12 Oct 2016 07:13:03.0288 (UTC) FILETIME=[127A1B80:01D22458] Archived-At: Cc: "adrian@olddog.co.uk" , "bill.wu@huawei.com" 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 07:13:06 -0000 --_000_KL1PR0201MB16567B11096AB45D66528A458BDD0KL1PR0201MB1656_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGRlYXIgYWxsLg0KDQoNCkdsYWQgdG8gZmluZCBMMlNNIGhlcmUuIFBlcnNvbmFsbHksIEkg dGhpbmsgWUFORyBkYXRhIG1vZGVsIGRldmVsb3BtZW50IGhhcyBtdWNoIGxhZ2dlZCBiZWhpbmQg b3BlbiBzb3VyY2UgcHJvamVjdC4gVGh1cyBpdCdzIHJlc3BvbnNpYmxlIGZvciBzdGFuZGFyZGl6 YXRpb24gb3JnYW5pemF0aW9uIHRvIHNwZWVkIHVwLg0KDQoNCkFzIEkgZm9sbG93ZWQgTDNTTSBh Y3Rpdml0eSBpbiB0aGUgbGFzdCBJRVRGIG1lZXRpbmdzLCBJIHdpdG5lc3NlZCB0aGUgc3VjY2Vz cyBvZiBMM1NNIGJlaW5nIGRlbGl2ZXJlZC4gQWJvdXQgdGhlIEwyU00gY2hhcnRlciwgSSBoYXZl IHJldmlld2VkIGFzIGl0J3MgaW4gdGhlIHNhbWUgZm9ybWF0IGludHJvZHVjaW5nIG1vcmUgc2Vy dmljZSBpbm5vdmF0aW9uLg0KDQoNClRvIGJlIGhvbmVzdCwgSSB0aGluayBMMlNNIGlzIHZhbHVh YmxlIGFuZCBjYW4gaGVscCBmaWxsIHRoZSBnYXAgd2hpY2ggTDNTTSBpcyBub3QgY292ZXJlZC4N Cg0KQmVzdCByZWdhcmRzLg0KDQoNCkd1IFJvbmcNCg0KZ3Vyb25nQGNoaW5hbW9iaWxlLmNvbQ0K DQpndXJvbmdfY21jY0BvdXRsb29rLmNvbQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KV2VsY29tZSB0 byBMMlNNLA0KDQpUaGlzIGxpc3QgaXMgZm9yIGRpc2N1c3Npb24gb2YgYSBwb3RlbnRpYWwgbmV3 IHdvcmtpbmcgZ3JvdXA6IExheWVyIDIgVlBODQpTZXJ2aWNlIE1vZGVsLg0KDQpBICpkcmFmdCog Y2hhcnRlciBoYXMgYmVlbiBwb3N0ZWQgYXQNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv d2cvbDJzbS9jaGFydGVyLyBhbmQgaXMgb3BlbiBmb3IgZGlzY3Vzc2lvbiBhbmQNCnJldmlzaW9u Lg0KDQpUaGVyZSBpcyBhbHNvIGEgY2FuZGlkYXRlIEktRCB0aGF0IGhhcyBiZWVuIHdvcmtlZCBv biBieSBzb21lIHNlcnZpY2UgcHJvdmlkZXJzDQphdmFpbGFibGUgYXQNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdlbi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwvIFRo aXMgaXMNCnZlcnkgbXVjaCBhIHdvcmsgaW4gcHJvZ3Jlc3Mgd2l0aCBuZXcgcmV2aXNpb25zIGV4 cGVjdGVkIGJldHdlZW4gbm93IGFuZA0KSUVURi05Ny4NCg0KSWYgYWxsIGdvZXMgd2VsbCB3ZSBo b3BlIHRvIG1lZXQgaW4gU2VvdWwgdG8gZGlzY3VzcyB0aGUgZHJhZnQgYW5kIG9wZW4gdXAgdGhl DQp3b3JrIHRvIHRoZSBjb21tdW5pdHkuIFdlIGFyZSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBp biBpbnB1dCBmcm9tIHRoZSBvcGVyYXRvcg0KY29tbXVuaXR5Lg0KDQpUaGFua3MsDQpBZHJpYW4N Cg0KDQoNCmRyYWZ0LXdlbi1sMnNtLWwydnBuLXNlcnZpY2UtbW9kZWwtMDAgLSBkYXRhdHJhY2tl ci5pZXRmLm9yZzxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13ZW4tbDJz bS1sMnZwbi1zZXJ2aWNlLW1vZGVsLz4NCmRhdGF0cmFja2VyLmlldGYub3JnDQpBIFlBTkcgRGF0 YSBNb2RlbCBmb3IgTDJWUE4gU2VydmljZSBEZWxpdmVyeSAoSW50ZXJuZXQtRHJhZnQsIDIwMTYp DQoNCg0KDQo= --_000_KL1PR0201MB16567B11096AB45D66528A458BDD0KL1PR0201MB1656_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, dear all.


Glad to find L2SM here. Personally, I think YANG data model development = has much lagged behind open source project. Thus it's responsible for stand= ardization organization to speed up.


As I followed L3SM activity in the last IETF meetings, I witnessed the s= uccess of L3SM being delivered. About the L2SM charter, I have reviewed as = it's in the same format introducing more service innovation.


To be honest, I think L2SM is valuable and can help fill the gap which L= 3SM is not covered. 


Best regards. 


Gu Rong

gurong@chinamobile.com

gurong_cmcc@outlook.com

------------------------------------------------------------------------= ---------------------------------------------------------

Welcome to L2SM,=0A=
=0A=
This list is for discussion of a potential new working group: Layer 2 VPN=
=0A=
Service Model.=0A=
=0A=
A *draft* charter has been posted at=0A=
https://datatracker.ietf.org/wg/=
l2sm/charter/ and is open for discussion and=0A=
revision.=0A=
=0A=
There is also a candidate I-D that has been worked on by some service provi=
ders=0A=
available at=0A=
https://d=
atatracker.ietf.org/doc/draft-wen-l2sm-l2vpn-service-model/ This is=0A=
very much a work in progress with new revisions expected between now and=0A=
IETF-97.=0A=
=0A=
If all goes well we hope to meet in Seoul to discuss the draft and open up =
the=0A=
work to the community. We are particularly interested in input from the ope=
rator=0A=
community.=0A=
=0A=
Thanks,=0A=
Adrian=0A=
=0A=
datatracker.ietf.org
A YANG Data Model for L2VPN Service Delivery (Internet-Draft, 2016)


--_000_KL1PR0201MB16567B11096AB45D66528A458BDD0KL1PR0201MB1656_-- From nobody Wed Oct 12 13:45:35 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 EB22B129400; Wed, 12 Oct 2016 13:45:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147630513092.6289.10161653064426528790.idtracker@ietfa.amsl.com> Date: Wed, 12 Oct 2016 13:45:30 -0700 Archived-At: Cc: l2sm-chairs@ietf.org, l2sm@ietf.org Subject: [L2sm] Kathleen Moriarty's No Objection on charter-ietf-l2sm-00-00: (with COMMENT) 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: Wed, 12 Oct 2016 20:45:31 -0000 Kathleen Moriarty has entered the following ballot position for charter-ietf-l2sm-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-l2sm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- There is a typo in the first paragraph s/onfiguration/configuration/ From nobody Thu Oct 13 00:12:53 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 EA2341298AB; Thu, 13 Oct 2016 00:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 htwG4h4-YZFK; Thu, 13 Oct 2016 00:12:50 -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 8A5D01298A0; Thu, 13 Oct 2016 00:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=730; q=dns/txt; s=iport; t=1476342770; x=1477552370; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=sy1x4Y3Wzu03Ex1PPllfNfuPhG7CPzq+CKto1ziCcVE=; b=UQIatD4xlcBD6rTzh9olF/LeAsnwQbwUjly1vtaARWT9GlHRMIGN8ovN Xo8pgDPF12yINKWPpSG2S3b7ZRwK+rn6ll++ZTNbCG80T7+FAacBGLQOm nBSdPvsmaipl2SCofii90wJ350jlA9zCXuJFv4Vo2mZ51Fe6YEGZaGzY1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsAQCuMv9X/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAXQqjgapKoIPggonhXoCgjQUAQIBAQEBAQEBXieEYgE?= =?us-ascii?q?BBCMVQRALGgImAgJXBgEMCAEBiEwOtiaNBAEBAQEBAQEBAQEBAQEBAQEBAQEBG?= =?us-ascii?q?QWBB4U2gX2CWIQZEQGDIIJbAQSIPItshVqGJ4lWgW6EZ4MUhgyJKYdPHjZDBQi?= =?us-ascii?q?EZjyGeIIgAQEB?= X-IronPort-AV: E=Sophos;i="5.31,339,1473120000"; d="scan'208";a="646343082" 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; 13 Oct 2016 07:12:44 +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 u9D7CiB8021898; Thu, 13 Oct 2016 07:12:44 GMT To: Kathleen Moriarty , The IESG References: <147630513092.6289.10161653064426528790.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: Date: Thu, 13 Oct 2016 09:12:46 +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: <147630513092.6289.10161653064426528790.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: l2sm-chairs@ietf.org, l2sm@ietf.org Subject: Re: [L2sm] Kathleen Moriarty's No Objection on charter-ietf-l2sm-00-00: (with COMMENT) 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, 13 Oct 2016 07:12:52 -0000 Thanks Kathleen, Corrected. B. > Kathleen Moriarty has entered the following ballot position for > charter-ietf-l2sm-00-00: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-l2sm/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > There is a typo in the first paragraph > s/onfiguration/configuration/ > > > . > From nobody Thu Oct 13 06:19:57 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 58DED129454; Thu, 13 Oct 2016 06:19:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147636479632.2894.7376748604935262928.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 06:19:56 -0700 Archived-At: Cc: l2sm-chairs@ietf.org, l2sm@ietf.org Subject: [L2sm] Alia Atlas' No Objection on charter-ietf-l2sm-00-01: (with COMMENT) 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: Thu, 13 Oct 2016 13:19:56 -0000 Alia Atlas has entered the following ballot position for charter-ietf-l2sm-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-l2sm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am surprised not to see EVPN included in the list of technologies, since it is a replacement for VPLS. I understand that the service model should be fairly technology independent, but if it can't handle EVPN, that'll be an issue. Could you please update it to at least mention EVPN as one of the technologies? From nobody Fri Oct 14 09:32:22 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 6F85B12984F; Fri, 14 Oct 2016 09:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.518 X-Spam-Level: X-Spam-Status: No, score=-17.518 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, 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 d1sk7Bsg_8Gl; Fri, 14 Oct 2016 09:32:14 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5E051297B8; Fri, 14 Oct 2016 09:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1518; q=dns/txt; s=iport; t=1476462734; x=1477672334; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=j4Agq/PGiVoUX2hz/ufXU1QzmzF6GUJArvhgO7B2YQU=; b=Y41Z6gSg/fYmo37KCqif05G2wVv4FrVHutCTHcTUJfzFEz52bVcmf62z GwBrm3tn36qiaTaI27PiLwDFL4Vz36Iyg/ugEsmhCcxKDMwVXsuWCahIo UVIsDYanvUwQU/hWk8JtegDsOslgHLYUnvQxCsRxd7o5tcOyHxCv17pwO M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CFAQCnBwFY/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAXQqUo00lwWUOIIIHQiFfQKCSxQBAgEBAQEBAQFeJ4R?= =?us-ascii?q?iAQEDAQEBATU2CwULCw4fGScwBgEMBgIBAYhGCA7DHAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBGQWGPYF9CIJQhBkRAVuFIAEEiDyRSoYoiViBboRngxSGDIcQghmHTx4?= =?us-ascii?q?2RAYIhGs8NAEBAQGGEYIgAQEB?= X-IronPort-AV: E=Sophos;i="5.31,493,1473120000"; d="scan'208";a="647402503" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Oct 2016 16:32:11 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9EGWA5e024272; Fri, 14 Oct 2016 16:32:11 GMT To: Alia Atlas , The IESG References: <147636479632.2894.7376748604935262928.idtracker@ietfa.amsl.com> From: Benoit Claise Message-ID: <10ffe913-16c3-5675-2378-10154234e3f2@cisco.com> Date: Fri, 14 Oct 2016 18:32:07 +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: <147636479632.2894.7376748604935262928.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: l2sm-chairs@ietf.org, l2sm@ietf.org Subject: Re: [L2sm] Alia Atlas' No Objection on charter-ietf-l2sm-00-01: (with COMMENT) 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: Fri, 14 Oct 2016 16:32:16 -0000 Hi Alia, Added. https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-l2sm%2Fwithmilestones-00-01.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-l2sm%2Fwithmilestones-00-03.txt Sending this charter to external review now. From here, we'll take into account all feedback, including for the L2SM mailing list (I have seen Michael's feedback, for example). Regards, Benoit > Alia Atlas has entered the following ballot position for > charter-ietf-l2sm-00-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-l2sm/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am surprised not to see EVPN included in the list of technologies, > since it is a replacement for VPLS. > I understand that the service model should be fairly technology > independent, but if it can't handle EVPN, > that'll be an issue. Could you please update it to at least mention > EVPN as one of the technologies? > > > _______________________________________________ > L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm > . > From nobody Fri Oct 14 09:33: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 1978F129855; Fri, 14 Oct 2016 09:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 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_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TBmXbJEJR6HV; Fri, 14 Oct 2016 09:33:30 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F6A129516; Fri, 14 Oct 2016 09:33:29 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id t193so78115994ywc.2; Fri, 14 Oct 2016 09:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ibv/nz7oiVJqF6HYokzmxtXYQDqNv7wb7dNTkBgswxU=; b=qXfeVBG4ifjTZZQmvd0yrPqxbEnPU7pctaI0a5qqhcR422UDrbhpgtnsr9yHzZK/IX jaQxaSQ1N5HhRxwWKc6s8Ttu9sbTYpQLwIdIbYqnU9T2FzyVmvjgP3M6Jen2A6LN7/De Cv+svDqezTK1vjtXFM+5yMZw6ssMvZaGxl1kqOsN3oikeX3y+TvjiX0OTRXm8WVJ8olK 7bCYQkAZVqyTa8OsGlaoWNVQFQdl5O85Iek1SXpRxu+pW+2DDILa4PgBR1TVDPCWkZ+/ td7x+pSebvvvr1G9HNuWoU1+7KAz5C2mWGQCDZZNiLYGA4KViencxhpIweydVZEuRsN6 2zVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ibv/nz7oiVJqF6HYokzmxtXYQDqNv7wb7dNTkBgswxU=; b=fCD2H5B8a5oAplg/YkyYHBbyoWT7GlvZ88ndK5/plVVRD3WStLIaMvOB4YMe/upZyw lPAuv11jAeWYnh0iBpqOJBZQfe2NuqKiszf58BPU/wANH1S/TJdhpKPvw5u0KjmF2uUK BGFBK0QW4qBSSaN+6ghvKvwmMJkt/jYFb36KBC8QIwGdV5QZ61M63gzp9dNkZJCEcG69 A3cmArm5lvOFgfP2nm8QnwVIDc+ZoBtaa0I5kt0dvAYFK8QAzFdi/JAX9uDAsGc5Ho9F dJT/5zqUgN0Ran4JwufDPAZ4mrc4Z9QTtQ8eyNycAkA+HGPlPNpNRT6Z7BhFCBkFyd61 9Hjw== X-Gm-Message-State: AA6/9RnZQSHBUa0Mx24ALu1i8ZXDUX1F8g9TjGIZ3x0dHYCx0wk2liyl2a7VdMVrwX4ALlniOcK5WGbxufx6NQ== X-Received: by 10.129.50.10 with SMTP id y10mr11030398ywy.136.1476462809107; Fri, 14 Oct 2016 09:33:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.56.133 with HTTP; Fri, 14 Oct 2016 09:33:28 -0700 (PDT) In-Reply-To: <10ffe913-16c3-5675-2378-10154234e3f2@cisco.com> References: <147636479632.2894.7376748604935262928.idtracker@ietfa.amsl.com> <10ffe913-16c3-5675-2378-10154234e3f2@cisco.com> From: Alia Atlas Date: Fri, 14 Oct 2016 12:33:28 -0400 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11414f0642e27d053ed5c91f Archived-At: Cc: l2sm-chairs@ietf.org, The IESG , l2sm@ietf.org Subject: Re: [L2sm] Alia Atlas' No Objection on charter-ietf-l2sm-00-01: (with COMMENT) 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: Fri, 14 Oct 2016 16:33:32 -0000 --001a11414f0642e27d053ed5c91f Content-Type: text/plain; charset=UTF-8 Hi Benoit, Thank you. I look forward to a good WG. Regards, Alia On Fri, Oct 14, 2016 at 12:32 PM, Benoit Claise wrote: > Hi Alia, > > Added. > https://www.ietf.org/rfcdiff?url1=https%3A%2F%2Fdatatracker. > ietf.org%2Fdoc%2Fcharter-ietf-l2sm%2Fwithmilestones-00-01. > txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter- > ietf-l2sm%2Fwithmilestones-00-03.txt > > Sending this charter to external review now. > From here, we'll take into account all feedback, including for the L2SM > mailing list (I have seen Michael's feedback, for example). > > Regards, Benoit > > Alia Atlas has entered the following ballot position for >> charter-ietf-l2sm-00-01: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-l2sm/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I am surprised not to see EVPN included in the list of technologies, >> since it is a replacement for VPLS. >> I understand that the service model should be fairly technology >> independent, but if it can't handle EVPN, >> that'll be an issue. Could you please update it to at least mention >> EVPN as one of the technologies? >> >> >> _______________________________________________ >> L2sm mailing list >> L2sm@ietf.org >> https://www.ietf.org/mailman/listinfo/l2sm >> . >> >> > --001a11414f0642e27d053ed5c91f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit,

Thank you.=C2=A0 I look forw= ard to a good WG.

Regards,
Alia

On Fri, Oct 14= , 2016 at 12:32 PM, Benoit Claise <bclaise@cisco.com> wrote:=
Hi Alia,

Added.
https://www.ietf.org/rfcdiff= ?url1=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-<= wbr>l2sm%2Fwithmilestones-00-01.txt&url2=3Dhttps%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-l2sm%2Fwithmilestones-00-03= .txt

Sending this charter to external review now.
>From here, we'll take into account all feedback, including for the L2SM= mailing list (I have seen Michael's feedback, for example).

Regards, Benoit

Alia Atlas has entered the following ballot position for
charter-ietf-l2sm-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-iet= f-l2sm/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I am surprised not to see EVPN included in the list of technologies,
since it is a replacement for VPLS.
I understand that the service model should be fairly technology
independent, but if it can't handle EVPN,
that'll be an issue.=C2=A0 =C2=A0Could you please update it to at least= mention
EVPN as one of the technologies?


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



--001a11414f0642e27d053ed5c91f-- From nobody Fri Oct 14 10:36:31 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 DE43712987D; Fri, 14 Oct 2016 10:36:23 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147646658390.18536.18425921764162438932.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2016 10:36:23 -0700 Archived-At: Cc: l2sm@ietf.org Subject: [L2sm] WG Review: L2VPN Service Model (l2sm) 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: Fri, 14 Oct 2016 17:36:24 -0000 A new IETF WG has been proposed in the Operations and Management Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-10-24. L2VPN Service Model (l2sm) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Benoit Claise Operations and Management Area Directors: Benoit Claise Joel Jaeggli Mailing list: Address: l2sm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/l2sm Archive: https://mailarchive.ietf.org/arch/browse/l2sm/ Charter: https://datatracker.ietf.org/doc/charter-ietf-l2sm/ The IETF and the industry in general is currently specifying a set of YANG models for network element and protocol configuration. This is an essential first 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 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), 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, and Ethernet VPNs in RFC 7432. 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, 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. 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. 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. Milestones: Dec 2016 - Adopt WG draft for data model Oct 2017 - Request publication of data model as Standards Track RFC Dec 2017 - Close working group From nobody Mon Oct 17 06:43:14 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 D69AD129668 for ; Mon, 17 Oct 2016 06:43:12 -0700 (PDT) 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 ndUiElAfv8F0 for ; Mon, 17 Oct 2016 06:43:10 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93A9129665 for ; Mon, 17 Oct 2016 06:43:09 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9HDh7Nl015665; Mon, 17 Oct 2016 14:43:07 +0100 Received: from 950129200 (GUEST-NATout-192-5-215-211.myguests.gmu.edu [192.5.215.211]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9HDh5Z3015626 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2016 14:43:07 +0100 From: "Adrian Farrel" To: "'Scharf, Michael \(Nokia - DE\)'" , References: <655C07320163294895BBADA28372AF5D48AE8AEE@FR712WXCHMBA15.zeu.alcatel-lucent.com> <0c1f01d2239d$3d98fe00$b8cafa00$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48AEBA0D@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48AEBA0D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Mon, 17 Oct 2016 14:43:03 +0100 Message-ID: <051301d2287c$62ff9b20$28fed160$@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: AQHSL1hpGJNIX7Ubrhppm3Lchr8OLwGLJ841AffrbxOgkHT/8A== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22644.000 X-TM-AS-Result: No--20.546-10.0-31-10 X-imss-scan-details: No--20.546-10.0-31-10 X-TMASE-MatchedRID: 8HTFlOrbAtFqJ1y0VLNhDlfS8E9vfq82cMpWln4QlpzagsZM0qVv10Gd 9Hthb4Jj0sdysRfisBS+PLMV3BTV1UA+ach/g/NPiWatZUOj6OudtHUoZpvleQFbHA9TqNLQFPa ZjySxV2uZZ283zuxSsnmvKJMhYTxxAwGTXi1PrVHEO0jjSgczboLsLasl5ROhf7FDYGpyXq2W9N tLiLXlC238cWGnxJR4ojUaM4PADfdcRvbyyNfmpUhEDfw/93BuT7iS5InK23p0TRq4bcxmHyBPb +3cNbWuNZR+I8+05PU486vsentZ77kYizK5Be96Yx1jPJKy+Dx6PxDI06UtHTGnMWgJkpRoZwKf T86BI+HVI6PSpJtXSwURoDPeeL2R/02XRYC/8eu7335YZAh4C/i4nVERfgwdPcFkClcmQNvN6oa SBNupL0zAXyT/NMg7C9sF0BZZ7VjmzYT8cOkbWV2036HHwFm/0KTi2mJgJ0j6hwZlO71ee9O/Y9 RMDWyUaVnwHGu5c2MfFgxUL4UhUbUa2ZmPoVStpNFSZ+CYM84UkWvaqUqLH33hz57t9YhwMn80v yaSGGKyoZJQIFju80jlAbyv2DCcJX/6wXlfbdGrVklnbP5JtmKaLwu81+avq8z7POX8FJMGk2pT PAu+9zAjWV5ocso1VGx3F9ZmbgAmjnL9+4HNShLuW4a3q2WGrrEvQogcy/GCsBeCv8CM/dw74MT Xnc/BXlhjI2Nz/SO+NwzfST/kYQZjkqX65viXEhGH3CRdKUV/9Mg6o+wMixSVYgoSgYGZzVLQfF yKuot5qkAZWOajm/ml2k1/1fpYriNjw9LoWjueAiCmPx4NwLTrdaH1ZWqCpvI8UZOf47jUZxEAl FPo846HM5rqDwqtlExlQIQeRG0= Archived-At: Subject: Re: [L2sm] L2SM charter proposal 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, 17 Oct 2016 13:43:13 -0000 Hi again, Michael, Now that the IESG has sent out asking for comments on the charter, I wanted to make sure we don't lose your input from this thread. > I think the charter could use the term "customer service model". We can certainly > argue whether this is the best term, but to me it is better than "service model". Yup, I can agree with that. Although draft-wu-opsawg-service-model-explained can't claim consensus, I hope that this term is less ambiguous and slightly more focused. >>>> 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? >> >> I read this as: >> - MUST include VPWS and VPLS >> - MAY include other things >> >> The text could be clearer. Which way would you like it to go: exclusive or >> inclusive? > > I think a better alternative would be to list examples what MAY be included as > well, provided there is WG consensus etc. But under the assumption that this WG > shall be driven by operators, I suspect it is up to them to decide. > > Potential implementations could probably deal with L2VPN services beyond > VPWS and VPLS. Having a common base model could have benefits. I think Alia had a similar take-away in IESG review as she wanted to add EVPN to the list of service types covered in the charter (it is already in the draft). I see that Benoit has updated the text to... == 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 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), 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, and Ethernet VPNs in RFC 7432. == I would suggest we pick up both of your points and re-work as... == The Layer Two Virtual Private Network Service Model (L2SM) working group is a short-lived WG. It is tasked to create a YANG data model that describes a L2VPN service (a L2VPN customer service model). The model can be used for communication between customers and network operators, and to provide input to automated control and configuration applications. It is recognized it would be beneficial to have a common base model that addresses multiple popular L2VPN service types. The working group will attempt to derive a single data model that includes support for point-to-point Virtual Private Wire Services (VPWS), 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, and Ethernet VPNs in RFC 7432. Other L2VPN service types may be included if there is consensus in the working group. == >>>> 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. >>> >>> 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. >> >> Hmmm, I do not believe that L3SM was chartered to provide that evaluation. [snip] >> I took this to mean that the L3SM could be used by those working on models >> "lower down the stack" (such as in BESS, RTGWG, IDR, etc.) to see whether >> they had captured all of the details that would be needed to deliver the >> services that operators want to sell to customers. Looked at another way, >> implementers building automated service delivery systems (who might >> want to support L3SM or some proprietary variant) would use L3SM to >> determine whether they could map a customer's service request to the >> YANG models that are used within the network to deliver the service. >> >> I'm not aware of this work having been done in a public forum, however, since >> there are implementations of L3SM, I assume that the work has been done and >> that perhaps some of the changes proposed to other models over time have >> arisen have come from this work. > > If that sort of work is expected to happen outside the L2SM WG, I wonder why > the charter needs wording on it. > > Or if it is expected to happen inside the L2SM WG, maybe a process different to > L3SM would be needed? > > I may be fine either way but I think a charter should have clear wording. 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 >>> 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. >> >> I think that is exactly the correct understanding. >> The question is, however, who does that gap analysis. >> As I say, I don't think the L3SM WG was asked to do the analysis, and this >> charter text is not asking a potential L2SM WG to do that. > > For L2SM there are comparable modeling activities in other standardization > bodies, in open source projects (e.g., for orchestrators), etc. When L3SM was > chartered, I think related work was less mature. So, the situation regarding a gap > analysis is not exactly the same. > > I think the charter should clearly explain whether a gap analysis is to be > performed by the WG, or not. If the WG is not asked to perform a gap analysis, I > think the charter wording can be cleaned up accordingly. Personally, I still like "coordinate" as a word to describe what a WG should attempt to do. I think formal gap analysis work often degrades into a beauty contest. 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 >>>> 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 ;-) It reduces to "harmless", I think. And if it makes the AD happy... :-) >>> 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 benefits of aligning structure with L3SM would seem to be: >> - a "service orchestrator" could use common or similar code >> - customers will have familiarity across services >> - there is future potential to generalise into a common service >> model >> - discussions that led to the L3SM structure are not repeated > > leading to more rapid development > > I agree that there could be benefits and therefore I think this design objective > should be stressed. BTW, this argument does not apply to VPWS and VPLS only, > as orchestrators may not be limited to that sort of services only. So, perhaps... OLD ...and it is expected that the L2SM data model will have similar structure to the L3SM data model. NEW ... . It is expected that the L2SM data model will have similar structure to the L3SM data model to enable benefits of common code, provide shared user experience, and leverage discussions that took place during the L3SM development. END [snip] > As L2VPNs are covered by multiple organizations, I'd really like to understand > how the IAB plans to handle this. Wouldn't a charter be a good place to provide > some guidance to the WG? Hopefully addressed by my suggestion above. Cheers, Adrian From nobody Tue Oct 18 04:13: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 3E6BB129A0E for ; Tue, 18 Oct 2016 04:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 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, 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 Em6lzlb27UHV for ; Tue, 18 Oct 2016 04:13:09 -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 1844E129A0B for ; Tue, 18 Oct 2016 04:13:09 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 99B769B0ECAE4; Tue, 18 Oct 2016 11:13:05 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u9IBD79d026548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Oct 2016 11:13:07 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u9IBD1xQ012885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Oct 2016 13:13:07 +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; Tue, 18 Oct 2016 13:13:06 +0200 From: "Scharf, Michael (Nokia - DE)" To: "adrian@olddog.co.uk" , "l2sm@ietf.org" Thread-Topic: [L2sm] L2SM charter proposal Thread-Index: AdIi8Z34b8Gws0BeT72D6VuLqSadbAAmtsMAAAZR2lABMXd5gAAv1CAw Date: Tue, 18 Oct 2016 11:13:05 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48AFA88A@FR712WXCHMBA15.zeu.alcatel-lucent.com> 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> In-Reply-To: <051301d2287c$62ff9b20$28fed160$@olddog.co.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 11:13:11 -0000 Inline (removing some text)... > > Potential implementations could probably deal with L2VPN services beyon= d > > VPWS and VPLS. Having a common base model could have benefits. >=20 > I think Alia had a similar take-away in IESG review as she wanted to add = EVPN > to > the list of service types covered in the charter (it is already in the dr= aft). >=20 > I see that Benoit has updated the text to... >=20 > =3D=3D > 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 custom= ers > and > network operators, and to provide input to automated control and configur= ation > applications. The working group will attempt to derive a single data mode= l > that > includes support for point-to-point Virtual Private Wire Services (VPWS), > multipoint Virtual Private LAN services (VPLS) that use Pseudowires signa= led > using the Label Distribution Protocol (LDP) and the Border Gateway Protoc= ol > (BGP) as described in RFC4761 and RFC6624, and Ethernet VPNs in RFC 7432. > =3D=3D >=20 > I would suggest we pick up both of your points and re-work as... >=20 > =3D=3D > The Layer Two Virtual Private Network Service Model (L2SM) working group = is a > short-lived WG. It is tasked to create a YANG data model that describes a > L2VPN > service (a L2VPN customer service model). The model can be used for > communication between customers and network operators, and to provide inp= ut to > automated control and configuration applications. >=20 > It is recognized it would be beneficial to have a common base model that > addresses multiple popular L2VPN service types. The working group will at= tempt > to derive a single data model that includes support for point-to-point Vi= rtual > Private Wire Services (VPWS), multipoint Virtual Private LAN services (VP= LS) > that use Pseudowires signaled using the Label Distribution Protocol (LDP)= and > the Border Gateway Protocol (BGP) as described in RFC4761 and RFC6624, an= d > Ethernet VPNs in RFC 7432. Other L2VPN service types may be included if t= here > is > consensus in the working group. > =3D=3D That wording seems better to me. Albeit the sentence is still long. To me, = "described/specified/standardized in RFC 7432" would be easier to parse. BTW, I believe that a charter is allowed to include bullet lists and this l= ooks like a good candidate to me. > How about... >=20 > OLD > The deliverable from this working group will provide information to evalu= ate > the > set of YANG models that have already been developed or are under developm= ent, > and will help identify any missing models or details. The deliverable can= be > viewed as driving requirements for protocol configuration model so that t= he > service parameters can be mapped into inputs used by the protocol models. > NEW > The deliverable from this working group will provide information that oth= er > 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 c= onfiguration models, i.e., it only includes a subset of parameters. It seem= s a bit strange to me that the charter assumes that missing model details i= n protocol configuration will be derived from an abstract representation. A= nd I am not sure if this has ever happened in the L3SM case. In my experience, the real-world question is whether a customer service mod= el indeed includes all the relevant parameters e.g. from a protocol configu= ration 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 charte= r. 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 f= or > L2VPN protocol work (most notably with BESS and PALS) and with the MEF. > NEW > The working group will coordinate with other working groups responsible f= or > L2VPN protocol work (most notably with BESS and PALS). It will also coord= inate > with other organizations working on related L2VPN data models (such as th= e > 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 th= e overlapping work in MEF? > So, perhaps... > OLD > ...and it is expected that the L2SM data model will have similar structur= e to > the L3SM data model. > NEW > ... . It is expected that the L2SM data model will have similar structure= to > the > L3SM data model to enable benefits of common code, provide shared user > experience, and leverage discussions that took place during the L3SM > development. > END That is better. > > As L2VPNs are covered by multiple organizations, I'd really like to > understand > > how the IAB plans to handle this. Wouldn't a charter be a good place to > provide > > some guidance to the WG? >=20 > Hopefully addressed by my suggestion above. I still don't understand how this relates to MEF and I suspect that questio= n is pretty obvious. Michael From nobody Wed Oct 19 08:54: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 40B5E129670 for ; 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 ; 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 ; 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)" , "adrian@olddog.co.uk" , "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 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: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Fri Oct 21 16:23:56 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 E0EED129860; Fri, 21 Oct 2016 16:21:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207091.28214.12767577536924254918.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:10 -0700 Archived-At: Cc: bclaise@cisco.com, l2sm@ietf.org Subject: [L2sm] l2sm - Requested session has been scheduled for IETF 97 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: Fri, 21 Oct 2016 23:21:11 -0000 Dear Stephanie McCammon, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. l2sm Session 1 (1:30:00) Thursday, Morning Session I 0930-1100 Room Name: Studio 2 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: L2VPN Service Model Area Name: Operations and Management Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: opsawg netmod netconf i2nsf bess pals idr rtgwg Special Requests: --------------------------------------------------------- From nobody Wed Oct 26 02:13:52 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 0A358129A58 for ; Wed, 26 Oct 2016 02:13:51 -0700 (PDT) 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 KNsEi0pb_UAY for ; Wed, 26 Oct 2016 02:13:49 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA773129A61 for ; Wed, 26 Oct 2016 02:13:48 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9Q9DkUB027237 for ; Wed, 26 Oct 2016 10:13:46 +0100 Received: from 950129200 (28.200.114.87.dyn.plus.net [87.114.200.28]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9Q9Djo8027189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 26 Oct 2016 10:13:45 +0100 From: "Adrian Farrel" To: References: <147746871576.18922.7891329538459663746.idtracker@ietfa.amsl.com> In-Reply-To: <147746871576.18922.7891329538459663746.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2016 10:13:44 +0100 Message-ID: <052301d22f69$40e55a90$c2b00fb0$@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: AQFk6aqPZFt4bb4lNRaeNbUMXz7CvqGU/xog Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22660.006 X-TM-AS-Result: No--19.368-10.0-31-10 X-imss-scan-details: No--19.368-10.0-31-10 X-TMASE-MatchedRID: tdruJpgvEk8O0G36v8LMKszWN98iBBeGDZlTFg+eXzvqFlTg1wFn3Fiq Ayk7LkbkdS/l9fGXMz0fzXumXQL3DJe0PI+kV0yjVo6mn+xXmdUPyDogld2OtIzZ6FNX6KaLvL4 BuAuBsSmFWYc1c3/uLLstgAv0KIkmtvbNMC/z32UXKqR+w9a7UJZ6zKu0q4rtfUOf4Mp5xtY+xn rY8SIOUhj7QnflgFtxPEj484mD3U7yvcecKfVZZtxajlW+zwxCPdMav3GPkJ5nw+QUp8qYOAB71 tCo2/1BQIdYpsvMFQeOxKr3dVsjzskwYM+oZdHXgOqr/r0d+CwPaWzG/2S2hszvOkSymob/mEGg ID3cKkOrGLQYOnkPd+9EJt2F5OksTX7PJ/OU3vL+xOhjarOnHv1vTGBiuZrt1GcRAJRT6POOhzO a6g8KrZRMZUCEHkRt Archived-At: Subject: [L2sm] FW: I-D Action: draft-wen-l2sm-l2vpn-service-model-02.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: Wed, 26 Oct 2016 09:13:51 -0000 FYI > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 26 October 2016 08:59 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-wen-l2sm-l2vpn-service-model-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A YANG Data Model for L2VPN Service Delivery > Authors : Bin Wen > Giuseppe Fioccola > Chongfeng Xie > Luay Jalil > Filename : draft-wen-l2sm-l2vpn-service-model-02.txt > Pages : 79 > Date : 2016-10-25 > > Abstract: > This document defines a YANG data model that can be used to configure > a Layer 2 Provider Provisioned VPN service. > > This model is intended to be instantiated at management system to > deliver the overall service. This model is not a configuration model > to be used directly on network elements, but provides an abstracted > view of the Layer 2 VPN service configuration components. It is up > to a management system to take this as an input and use specific > configurations models to configure the different network elements to > deliver the service. How configuration of network elements is done > is out of scope of the document. > > The data model in this document 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. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-wen-l2sm-l2vpn-service-model/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-wen-l2sm-l2vpn-service-model-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-wen-l2sm-l2vpn-service-model-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Oct 26 08:13:53 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 20A541295B6 for ; Wed, 26 Oct 2016 08:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 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] 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 y3MbDgeSX7Gk for ; Wed, 26 Oct 2016 08:13:49 -0700 (PDT) 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 B56501295A2 for ; Wed, 26 Oct 2016 08:13:46 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9QFDigA004357 for ; Wed, 26 Oct 2016 16:13:44 +0100 Received: from 950129200 (28.200.114.87.dyn.plus.net [87.114.200.28]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9QFDhD5004341 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 26 Oct 2016 16:13:44 +0100 From: "Adrian Farrel" To: References: <201610262137532695733@ctbri.com.cn> In-Reply-To: <201610262137532695733@ctbri.com.cn> Date: Wed, 26 Oct 2016 16:13:43 +0100 Message-ID: <063d01d22f9b$8ab12ff0$a0138fd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_063E_01D22FA3.EC826930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIWH4Xai9aEDKW8q425LbMHWS4I16Ay978Q Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22660.007 X-TM-AS-Result: No--17.195-10.0-31-10 X-imss-scan-details: No--17.195-10.0-31-10 X-TMASE-MatchedRID: 5H0h97/a1s4vp9R9KwuJgPDZVqBPJTWp8N9iKSAkgue1eX0jEQ9c6jIe U12C5aCfzjqJngvc26g+nprjbuUrtfH17GX1hHxkaDCzqDR7DPYZKp0SZ4P+dcsIWSRjI55eBpN qUzwLvvcVqN1n3pdLRuaA90At0MqwjxpcxIMfRJRbd1zMnVGjF3B3Uqg8syIULM8X1Jd+PEqjt6 +WJiLXsIXzTWxs0D/dbROt13bZFDjjI7SZVGHDqsFWmsryu9ZfcpgI8ixgsxxGG2hYiBKddJrAS HsnChAHNtrqBJtuOX5BVgr5vOsPONLF6Y0L7R/QcFEiuPxHjsW0X0Yw27VuouQ45nVtPqmx7KBB Z2QBUyxYAerJK6HhgiG6q3sO1y16PisfwAlA31KdCtkMrsOtOg/i8FY2vTOBIDp4740OYDElncP TMo+HsfXTJA26jU4lkhRShy60CjQzG8Dg48sJ/vIVL3+KSNgwkTzAgHG5eNKgJH974mpbq6gTkL gTtTggXql2hIcwl2sTHy/6jlpjHX7qNYdKZkwaFlT/KggLyj0lWygvtTclwPAEgpQDXwIHADRMo ifoBfkzmpYx+UKjh3C2KyYp/H7vWYqLLUX2mAu6kMgL3jbYOtMxD/3e8TxdRtqpRW8sWyKakVWY YDXrTswMS4ODXmCsnuOhtEsGi0ZP5mzaUz6wQBD3+0w1DhqKmRKFhwukYf1kzblkBbANhmAQRn3 L+ljhjSJ3SkiGrFPXkuVVlJMsPZx6Ilif8OzGb/5HBZ6dvRgl3afZehJEWXjQ0NqHYhIhDlnNRf 5gnN8g839dkIFeJEADtkoa9d0A6t1guSoQ4UOeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMxGc0fHRhivO52j+LUF80f27EzoZGOPuR0tTsdQuKqVp+3BndfXUhXQ== Archived-At: Subject: [L2sm] FW: L2SM charter proposal 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: Wed, 26 Oct 2016 15:13:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_063E_01D22FA3.EC826930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Forwarding for ChongFeng who is having list subscription problems. Adrian From: chongfeng.xie@foxmail.com [mailto:1848418658@qq.com] Sent: 26 October 2016 14:39 To: l2sm Cc: adrian; bclaise Subject: Re: [L2sm] L2SM charter proposal >> 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? Sorry for late reply, talking with our delegate in MEF,I think the collaboration is needed if the detailed performance parameters, performance metric, performance objective should be modeled in l2sm model, but the debate point is how much details we should cover, since I don't believe we should focus on enumerating a large list of perf measurement related data, if it is healthy to have them, I think we should create a sla container for placeholder to include these parameters that are defined by MEF 23.2,definitely MEF reference is needed, right now we authors still debate on details we should cover. Chongfeng Xie _____ ------=_NextPart_000_063E_01D22FA3.EC826930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Forwarding for ChongFeng who = is having list subscription problems.

Adrian

 

From: = chongfeng.xie@foxmail.com [mailto:1848418658@qq.com]
Sent: 26 = October 2016 14:39
To: l2sm
Cc: adrian; = bclaise
Subject: Re: [L2sm] L2SM charter = proposal

 




>> But we could...>> OLD
>> The working group wil= l coordinate with other working groups resp= onsible for
>> L2VPN protocol work (mos= t notably with BESS and PALS) and with=  the MEF.
>> NEW
>> The workin= g group will coordinate with other working&= nbsp;groups responsible for
>> L2VPN protoco= l work (most notably with BESS and PAL= S). It will also coordinate
>> with&nbs= p;other organizations working on related L2VPN&n= bsp;data models (such as the
>> MEF).>> END
 
>Noting external dependenci= es in a separate sentence is better.
&nb= sp;
>Do the WG proponents plan to sha= re details on how they plan to deal&nb= sp;with the overlapping work in MEF?
 = ;


Sorry for late reply, talking=  with our delegate in MEF,I think the&= nbsp;collaboration is needed if the detailed&nbs= p;performance parameters, performance metric, perform= ance objective should be modeled in l2sm&nb= sp;model, but the debate point is how = much details we should cover, since I = don't believe we should focus on enumeratin= g a large list of perf measurement rel= ated data, if it is healthy to have&nb= sp;them, I think we should create a sl= a container for placeholder to include thes= e parameters that are defined by MEF 2= 3.2,definitely MEF reference is needed, right&nb= sp;now we authors still debate on details&n= bsp;we should cover.



Chongfeng Xie

 

 

<= /body> ------=_NextPart_000_063E_01D22FA3.EC826930-- From nobody Sat Oct 29 08:47:15 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 8F2FB129511 for ; Sat, 29 Oct 2016 08:47:13 -0700 (PDT) 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 fgQzLJTueLrN for ; Sat, 29 Oct 2016 08:47:11 -0700 (PDT) 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 34C9F1293EE for ; Sat, 29 Oct 2016 08:47:11 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9TFl9b2022479 for ; Sat, 29 Oct 2016 16:47:09 +0100 Received: from 950129200 (89.152.200.146.dyn.plus.net [146.200.152.89]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u9TFl8pg022467 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 29 Oct 2016 16:47:08 +0100 From: "Adrian Farrel" To: Date: Sat, 29 Oct 2016 16:47:06 +0100 Message-ID: <0c2f01d231fb$b3eb4ba0$1bc1e2e0$@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: AdIx+6wvRqUgteasSw+q16JOuq7U2g== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22668.000 X-TM-AS-Result: No--17.200-10.0-31-10 X-imss-scan-details: No--17.200-10.0-31-10 X-TMASE-MatchedRID: 76wzPmgPaLBCBQieSpAGz4GU23hVIa8hLdLfmiFS7fuabNoYojBQdqiZ aOZUGVmqMelH7qhnqUE/0YJS2+Uc1rRgLeduNs8xwgzEIaHq7pclUwMLwz1Qz142zm1Zi+MJVPt 4gQaCtT9NYvDaO9t+nPE/T9QKeKEb/E5CAZnt+vmVUcz8XpiS9FF5adRR2Ej12dP9ypSe+fcHxd 1BFu3mhXXIB4Kbq3PF0ilNRkcx6qkzwJ7ADkakn6ngbqTYC4GHE21NSmBqEKefxCiPZwNg9utlD D5mGP+X3f0e/BgwI9DShDtGsKTJ7TJWdXdBBzCxsyNb+yeIRAoHg23OuPl1dFfXgfL55inv59C6 Q63XTRJczJ2DyxDKXUb8xPtfEbnHCGqH67UhpHudVNZaI2n6/5hkkqJeFHotDO+DX+rUwfZncpG Qs7S9GTRzIRIo4G/0Bc5l05FO6qvk18JBpE0OqjAoNxJKRrVrfS0Ip2eEHny+qryzYw2E8M8943 oc3p3s3t//bkkogL4LbigRnpKlKSPzRlrdFGDw2bvcKqLZMIy8aWQPtDUnXRWu9GwlDf3zWrVk1 WVBh31Qb0W4rFkT0Q== Archived-At: Subject: [L2sm] FW: I-D Action: 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: Sat, 29 Oct 2016 15:47:13 -0000 All, The previous version had a small YANG error (thanks Benoit for catching it) and is fixed in this revision. Adrian -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen MORE new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: 29 October 2016 11:14 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-wen-l2sm-l2vpn-service-model-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : A YANG Data Model for L2VPN Service Delivery > Authors : Bin Wen > Giuseppe Fioccola > Chongfeng Xie > Luay Jalil > Filename : draft-wen-l2sm-l2vpn-service-model-03.txt > Pages : 79 > Date : 2016-10-29 > > Abstract: > This document defines a YANG data model that can be used to configure > a Layer 2 Provider Provisioned VPN service. > > This model is intended to be instantiated at management system to > deliver the overall service. This model is not a configuration model > to be used directly on network elements, but provides an abstracted > view of the Layer 2 VPN service configuration components. It is up > to a management system to take this as an input and use specific > configurations models to configure the different network elements to > deliver the service. How configuration of network elements is done > is out of scope of the document. > > The data model in this document 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. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-wen-l2sm-l2vpn-service-model/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-wen-l2sm-l2vpn-service-model-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-wen-l2sm-l2vpn-service-model-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt