From nobody Tue Jan 3 08:11:45 2017 Return-Path: <1848418658@qq.com> X-Original-To: l2sm@ietfa.amsl.com Delivered-To: l2sm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F252B1299B0 for ; Tue, 3 Jan 2017 06:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.841 X-Spam-Level: X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qq.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 km8iS18HOG3m for ; Tue, 3 Jan 2017 06:34:03 -0800 (PST) Received: from smtpbgbr2.qq.com (smtpbgbr2.qq.com [54.207.22.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907CD1299B7 for ; Tue, 3 Jan 2017 06:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1483454037; bh=9ThkxZd26fdKCPV4uk6F/+oeuuhmG/MHKOsbln56HGg=; h=Date:From:To:Cc:Subject:References:Mime-Version:Message-ID:Content-Type; b=seM+0r5NIlYH8/hOxMIul1jitmjWryS9tVaCSL3K5Ik8C1VFGuZz5xlUdRRyGKWH8 1QyaYeOt51kAmBL7ghVsmK52WJsTkfyBcYDA47yNwm0UyEd551dVxGBitkbQR0PSVf D76FWo5wG9eEYjGvtzSeahDS++ENf2+aFQLUjK00= X-QQ-mid: esmtp11t1483454035txmc8c6wg Received: from Xiechf (unknown [123.122.154.161]) by esmtp4.qq.com (ESMTP) with id ; Tue, 03 Jan 2017 22:33:54 +0800 (CST) X-QQ-SSF: 0100000000000020FF100000000000B X-QQ-FEAT: TikaAqnq9r8lE+XyG7ajbzTcJv/L//Oh/vDbbtW59AEgwVhNezxW/HH3MrHeT ZZBME9sy2FnQ+R2tAUwImVRI3ldzMx7bY6Z7GrM5gcLQWqHi/mRa/OlztZRdOTvRSmlzH0S j0ChOe8fB6cWWI9O51hr0iiyDi4FcUw7/iXI4axcylB7fCTei4MUE/wM/L6SibRE9UF9Z+e 702kIETirPafp6LhWtOHfrBGQ1MVVN0X69FNPx3jHshK6zf9aL/DuckLIo10h1lsiaOyqOx ipR2EiQJZBWD0uSr5HPFQipZ/vjapwa0HTr3eGkNRNyUgn X-QQ-GoodBg: 0 Date: Tue, 3 Jan 2017 22:34:04 +0800 From: "chongfeng.xie@foxmail.com" <1848418658@qq.com> To: adrian , bclaise , l2sm References: <0d4501d24132$62ceb590$286c20b0$@olddog.co.uk>, <5b6dbba2-d283-8c81-7aaa-152d05ebdb8c@cisco.com>, <003001d25fb2$8a84ebb0$9f8ec310$@olddog.co.uk> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 166[cn] Mime-Version: 1.0 Message-ID: <201701032234041478456@qq.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart505020173620_=----" X-QQ-SENDSIZE: 520 Feedback-ID: esmtp:qq.com:bgforeign:bgforeign3 X-QQ-Bgrelay: 1 Archived-At: X-Mailman-Approved-At: Tue, 03 Jan 2017 08:11:43 -0800 Cc: l2sm-chairs Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 14:34:09 -0000 This is a multi-part message in MIME format. ------=_001_NextPart505020173620_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIEFkcmlhbiwNCg0KRmlyc3RseSwgdGhhbmsgeW91IGZvciB3cml0aW5nIHRoZSBsb25nIG1h aWwgdG8gaWxsdXN0cmF0ZSBvZiB0aGUgc3RhdHVzIG9mIHRoZSBsMnNtLiANClNlY29uZGx5LCBJ IHN1cHBvcnQgdGhpcyBkcmFmdCBjYW4gYmUgYWRvcHRlZCBhcyBlYXJseSBhcyBwb3NzaWJsZS4g Q2hpbmEgVGVsZWNvbSBpcyBvbmUgb2YgdGhlIG9wZXJhdG9ycyB3aG8gb2ZmZXIgTDJWUE4gc2Vy dmljZSwgaW4gbW9zdCBjYXNlcywgaW4gam9pbnQgd2l0aCBmb3JlaWduIG9wZXJhdG9ycy4gVGhl IHNlcnZpY2UgbW9kZWwgbGlrZSBMMlNNIHdpbGwgbWFrZSB0aGUgc2VydmljZSBwcm92aXNpb25p bmcgbW9yZSBmbGV4aWJsZSBhbmQgcXVpY2tlci4NCg0KVGhhbmsgeW91IQ0KQ2hvbmdmZW5nICAN CiANCkZyb206IEFkcmlhbiBGYXJyZWwNCkRhdGU6IDIwMTYtMTItMjcgMDM6NTkNClRvOiAnQmVu b2l0IENsYWlzZSc7IGwyc21AaWV0Zi5vcmcNCkNDOiBsMnNtLWNoYWlycw0KU3ViamVjdDogUmU6 IFtMMnNtXSBBZG9wdGlvbiBwb2xsIGZvciBkcmFmdC13ZW4tbDJzbS1sMnZwbi1zZXJ2aWNlLW1v ZGVsLTAzLnR4dA0KSGkgYWxsLA0KIA0KVGhhbmtzIEJlbm9pdCBmb3IgeW91ciBlbWFpbCBhbmQg Y2xhcmlmaWNhdGlvbnMuIEhlcmUgaXMgbXkgdGFrZSBvbiB3aGVyZSB3ZSBhcmUgYW5kIHdoYXQg bmVlZHMgdG8gaGFwcGVuLg0KIA0KW3RsO2RyIC0tIEFkb3B0aW9uIHBvbGwgcmVtYWlucyBvcGVu OyBwbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50OyBhdXRob3JzIGNvbnRpbnVlIHdvcmtdDQogDQpJ IHRoaW5rIHdlIGRpZG4ndCBnZXQgZW5vdWdoIG1vbWVudHVtIG9yIHN1cHBvcnQgZm9yIGFkb3B0 aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQogDQpBdCB0aGUgbW9tZW50IEkgY2FuJ3QgdGVsbCB3aGV0 aGVyIHRoaXMgcmVzdWx0ZWQgZnJvbSBubyBvbmUgY2FyaW5nIG9yIGZyb20gcGVvcGxlIHJlZnJh aW5pbmcgZnJvbSBjb21tZW50aW5nIGFmdGVyIHRoZSB2ZXJ5IHN0cm9uZyBvcHBvc2l0aW9uIGV4 cHJlc3NlZCBieSBEYXZpZC4NCiANCkhhdmluZyByZWFkIGFuZCByZS1yZWFkIERhdmlkJ3MgZW1h aWwgSSBiZWxpZXZlIGhlIGV4cHJlc3NlcyBjbGVhcmx5IHdoeSBoZSB0aGlua3MgdGhlIGN1cnJl bnQgZHJhZnQgaXMgbm90IHN1aXRhYmxlIGZvciBhZG9wdGlvbiwgYW5kIG9mZmVycyB0d28gc3Vn Z2VzdGlvbnMgZm9yIGFsdGVybmF0aXZlIGFwcHJvYWNoZXMsIGJ1dCBoZSBuZWl0aGVyIHBvaW50 cyBhdCBub3Qgdm9sdW50ZWVycyBmb3Igd29yayB0byBzdXBwb3J0IHRob3NlIGFsdGVybmF0aXZl cy4NCiANClRoZXJlZm9yZSwgaXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBzdGlsbCBvbmx5IGhhdmUg b25lIGRyYWZ0IG9uIHRoZSB0YWJsZS4gV2UgY2FuIGVpdGhlciB3b3JrIHdpdGggdGhhdCBkcmFm dCBvciBnaXZlIHVwLiBJIHRoaW5rIGl0IHdvdWxkIGJlIHVuZm9ydHVuYXRlIHRvIGFiYW5kb24g dGhlIHdvcmtpbmcgZ3JvdXAgd2hlbiB3ZSBoYXZlIGEgbnVtYmVyIG9mIG9wZXJhdG9ycyB3aG8g YmVsaWV2ZSBpdCBpcyBhIGdvb2QgaWRlYSBhbmQgd2hvIGhhdmUgcHV0IGluIGEgbG90IG9mIGVm Zm9ydC4gU28gSSB3b3VsZCBsaWtlIHRvIHNlZSB1cyBtb3ZlIGZvcndhcmQgd2l0aCB3aGF0IHdl IGhhdmUgYW5kIGFkYXB0IGl0IGFzIG5lY2Vzc2FyeS4gVG8gZG8gdGhhdCwgaG93ZXZlciwgSSB0 aGluayB0aGUgY2hhaXJzIG5lZWQgdG8gaGVhciBtb3JlIHZvaWNlcyBpbiBzdXBwb3J0Lg0KIA0K SSBkbywgaG93ZXZlciwgd2FudCB0byByZXZpc2l0IHNvbWUgb2YgdGhlIHBvaW50cyBtYWRlIGlu IFNlb3VsIGFuZCBieSBEYXZpZDoNCiANCjEuIFRoaXMgZG9jdW1lbnQgc2hvdWxkIG5vdCBpbmNs dWRlIHByb3RvY29sLXNwZWNpZmljIGRldGFpbHMuDQpJdCBpcyBteSB2aWV3IHRoYXQgd2hlbiBh IFBFLW1vZGUgVlBOIGlzIGJlaW5nIGRpc2N1c3NlZCB0aGUgc2VydmljZSBvZmZlcmVkIGluY2x1 ZGVzIHRoZSBDRS1QRSBsaW5rIChhY2Nlc3MgY2lyY3VpdCkgYW5kIHRoZSB0ZWNobm9sb2d5IGRl dGFpbHMgb2YgdGhhdCBsaW5rIG11c3QgYmUgcmVwcmVzZW50ZWQgaW4gdGhlIHNlcnZpY2UgbW9k ZWwuDQpDbGVhcmx5IHdoZW4gdGhlIHNlcnZpY2UgaXMgYSBDRS1tb2RlIFZQTiB0aG9zZSBkZXRh aWxzIGRvbid0IGFwcGx5Lg0KSW4gU2VvdWwsIHdlIHJlY2VpdmVkIGFuIG9mZmVyIHRvIGdvIHRo cm91Z2ggdGhlIGN1cnJlbnQgZG9jdW1lbnQgYW5kIGZsYWcgdGhlIHByb3RvY29sIHBhcmFtZXRl cnMgdGhhdCBhcmUgYSBjb25jZXJuLiBJIGhvcGUgdGhhdCB0aGlzIGNhbiBiZSBkb25lIHNvIHRo YXQgdGhvc2Ugb2YgdXMgd2hvIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgcHJvYmxlbSBjYW4gYmV0 dGVyIHVuZGVyc3RhbmQgd2hhdCB0aGUgY29uY2VybiBpcy4NCiANCjIuIFdlIHNob3VsZCBub3Qg cmVkZXZlbG9wIHdvcmsgYWxyZWFkeSBkb25lIGJ5IHRoZSBNRUYNCkkgY291bGQgbm90IGFncmVl IG1vcmUsIGFuZCBpdCBzZWVtcyB0aGF0IHRoZSBhdXRob3JzIG9mIHRoZSBkcmFmdCBpbiBoYW5k IGhhdmUgYWRvcHRlZCBhIHNpbWlsYXIgcGhpbG9zb3BoeSBpbnRlbmRpbmcgdG8gcG9pbnQgYXQg KG9yIHByb3ZpZGUgY29udGFpbmVycyBmb3IpIGF0IGxlYXN0IFFvUywgU0xBLCBhbmQgYmlsbGlu ZyBtb2RlbHMgZGV2ZWxvcGVkIGJ5IHRoZSBNRUYuDQpPbiB0aGUgb3RoZXIgaGFuZCwgYXR0ZW1w dHMgdG8gbWFwIHRoaXMgc2VydmljZSBtb2RlbGxpbmcgYXBwcm9hY2ggaW50byB0aGUgTUVGIExT TyBhcmNoaXRlY3R1cmUgaGF2ZSBub3QgYmVlbiBlbnRpcmVseSBzdWNjZXNzZnVsICh3aXRoIGxv dHMgb2YgZGlmZmVyaW5nIG9waW5pb25zIGFuZCBzb21lIHN1Z2dlc3Rpb25zIHRoYXQgcGFydHMg b2YgbXVsdGlwbGUgTFNPIHJlZmVyZW5jZSBwb2ludHMgYXJlIGNhcHR1cmVkIGluIHRoaXMgbW9k ZWwpLiBUaGF0IHN1Z2dlc3RzIHRvIG1lIHRoYXQgd2hhdCBpcyBnb2luZyBvbiBpbiBMMlNNIGlz IGNsb3NlciB0byBhIHBhcmFsbGVsIHdpdGggTDNTTSB0aGFuIGEgZHVwbGljYXRpb24gb2YgTUVG IHdvcmsuIEl0IG1heSBiZSBhIGRpZmZlcmVudCBhcHByb2FjaCBvciBhIGRpZmZlcmVudCB0aGlu Zy4NCiANCkFzIEJlbm9pdCBzYWlkIGluIFNlb3VsIChxdW90aW5nIGZyb20gdGhlIG1pbnV0ZXMp IGFuZCBhcHBseWluZyB0byBib3RoIG9mIHRoZXNlIHBvaW50czoNCj4gICBEb24ndCB3YW50IHRo aXMgV0cgdG8gZG8gdG9vIG11Y2guIFRoZSBNRUYgYWxyZWFkeQ0KPiAgIHdvcmtpbmcgb24gU0xB LiBUaGlzIG1vZGVsIGNhbiBwb2ludCB0byB0aGF0LiBUaGlzIG1vZGVsIHRyaWVzDQo+ICAgdG8g YmUgdGVjaG5vbG9neSBhZ25vc3RpYywgYnV0IGlmIHRoZXJlIGlzIHNvbWUgaW5mb3JtYXRpb24N Cj4gICBuZWVkZWQgZnJvbSB0aGUgY3VzdG9tZXIgdGhlbiBpdCBzaG91bGQgYmUgaW4gdGhlIG1v ZGVsLg0KIA0KQm90dG9tIGxpbmU6DQogDQotIFRoZSBhdXRob3JzIG9mIGRyYWZ0LXdlbi1sMnNt LWwydnBuLXNlcnZpY2UtbW9kZWwtMDMudHh0IHNob3VsZA0KICAgY29udGludWUgdGhlaXIgd29y ay4gDQogICAtIEFkZHJlc3Mgc3BlY2lmaWMgaXNzdWVzIHJhaXNlZCBpbiBTZW91bA0KICAgLSBS ZXZpc2l0IGFsbCBwcm90b2NvbC1zcGVjaWZpYyBwYXJhbWV0ZXJzIHRvIGJlIHN1cmUgdGhleSBh cmUgbmVlZGVkDQogICAtIEFkZGluZyBleGFtcGxlcyBpbiBTZWN0aW9uIDcgd291bGQgYmUgbW9z dCBoZWxwZnVsIHRvIGFpZCBvdGhlcnMgdG8gDQogICAgIHNlZSBob3cgdGhlIG1vZGVsIGlzIHVz ZWQNCiAgIC0gTWFrZSBjbGVhcmVyIGFuZCBtb3JlIGV4cGxpY2l0IHJlZmVyZW5jZXMgdG8gdXNl IG9mIGV4aXN0aW5nIG9yIGluLQ0KICAgICAgcHJvZ3Jlc3MgTUVGIHdvcmsuDQogDQotIFRoZSB3 b3JraW5nIGdyb3VwIHNob3VsZCBhZ2FpbiBsb29rIGF0IHRoaXMgZG9jdW1lbnQgYW5kIHNheSB3 aGV0aGVyDQogICBpdCBpcyBjdXJyZW50bHkgc29tZXRoaW5nIHRoYXQgd2UgY2FuIHVzZSBmb3Ig YSBzdGFydGluZyBwb2ludCBmb3Igb3VyIHdvcmsuDQogICBJIHdvdWxkIHBhcnRpY3VsYXJseSBs aWtlIHRvIGhlYXIgZnJvbSBuZXR3b3JrIG9wZXJhdG9ycyAoc2VydmljZSBwcm92aWRlcnMpDQog ICB3aG8gb2ZmZXIgTDJWUE4gc2VydmljZXMsIGFuZCBmcm9tIGNvbnN1bWVycyAoc3VjaCBhcyBl bnRlcnByaXNlcykgd2hvDQogICBwdXJjaGFzZSBzdWNoIHNlcnZpY2VzLiBBcyB0aGUgY2hhaXJz IHNhaWQgaW4gU2VvdWwsIHRoaXMgd29yayByZWFsbHkgbmVlZHMgdG8NCiAgIGJlIGxlZCBieSB0 aGUgb3BlcmF0b3JzIGFuZCBub3QgZG9taW5hdGVkIGJ5IHRoZSB2ZW5kb3JzLg0KIA0KVGhhbmtz LA0KQWRyaWFuDQogDQpGcm9tOiBCZW5vaXQgQ2xhaXNlIFttYWlsdG86YmNsYWlzZUBjaXNjby5j b21dIA0KU2VudDogMjIgRGVjZW1iZXIgMjAxNiAxMzo0NA0KVG86IGFkcmlhbkBvbGRkb2cuY28u dWs7IGwyc21AaWV0Zi5vcmc7IFNjb3R0IE1hbnNmaWVsZA0KU3ViamVjdDogUmU6IFtMMnNtXSBB ZG9wdGlvbiBwb2xsIGZvciBkcmFmdC13ZW4tbDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTAzLnR4 dA0KIA0KRGVhciBhbGwsDQoNCkEgY291cGxlIG9mIHJlZmxlY3Rpb25zIG9uIEwyU00sIGp1c3Qg YmVmb3JlIHRoZSBlbmQgb2YgeWVhciBicmVhay4NCg0KRmlyc3QsIEkgd2FudCB0byBxdW90ZSBv bmUgY2hhaXJzIHNsaWRlcyBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ny9zbGlk ZXMvc2xpZGVzLTk3LWwyc20tY2hhaXJzLXNsaWRlcy0wMS5wZGY6IA0KV2UgcmVhbGx5IG5lZWQg dGhpcyB0byBiZSBkcml2ZW4gYnkgT3BlcmF0b3JzDQogICAgLSBPZiBjb3Vyc2UsIHZlbmRvcnMg Y2FuIGFuZCBzaG91bGQgcGFydGljaXBhdGUNCiAgICAtIEJ1dCBiZSBhd2FyZSBvZiBob3cgdGhl IGRhdGEgbW9kZWwgaXMgdXNlICAgDQpJJ20gYWx3YXlzIGJhZmZsZWQgd2hlbiB2ZW5kb3JzICdz ZWVtIHRvKSBrbm93IGJldHRlciB0aGFuIHRoZSBvcGVyYXRvcnMgd2hhdCB0aGV5IG5lZWQuIEkg ZG9uJ3QgYmVsaWV2ZSB3ZSBoYXZlIHNwZW50IGVub3VnaCB0aW1lIGxpc3RlbmluZyB0byB0aGUg ZmV3IG9wZXJhdG9ycyBpbiB0aGUgcm9vbSBkdXJpbmcgdGhlIFdHIG1lZXRpbmcuIA0KV2UgaGF2 ZSBoZXJlIGEgZ3JvdXAgb2Ygb3BlcmF0b3JzIHdobyB3YW50IHRvIGRvIHdvcmsgaW4gdGhlIElF VEYsIGFuZCB3ZSBzaG91bGQgcmVzcGVjdCB0aGF0Lg0KDQpTZWNvbmQsIG9uIHRoZSBkaWZmZXJl bmNlcyBiZXR3ZWVuIElFVEYgYW5kIE1FRiBzZXJ2aWNlIG1hbmFnZW1lbnQuDQpNRUYgd2FudHMg dG8gZ28gZm9yIHRoZSBmdWxsIExTTyBhcmNoaXRlY3R1cmUgKGJpbGxpbmcsIFNMQSwgb3JkZXIg bWFuYWdlbWVudCwgZXRjLikuIFBlcmZlY3QuDQpMMlNNIGNoYXJ0ZXIgd2FudHMgdG8gZG8gc29t ZXRoaW5nIHNpbWlsYXIgdG8gTDNTTTogYSBzZWxmLWNvbnRhaW5lZCBzZXJ2aWNlIFlBTkcgbW9k dWxlLg0KSXQgd291bGQgYmUgbmljZSB0byB0cnkgdG8gZml0IHRoZSBMMlNNIHNlcnZpY2UgbW9k ZWxzIGluIHRoZSBNRUYgTFNPIGFyY2hpdGVjdHVyZSwgYnV0IHRoZSBMMlNNIHdvcmsgZm9sbG93 cyBhIGRpZmZlcmVudCBhcmNoaXRlY3R1cmFsIG1vZGVsIHRvIExTTywgYW5kIHRoYXQgdGhlcmUg aXMgbm8gdmFsdWUgaW4gdHJ5aW5nIHRvIG1hdGNoIHRoZSBmdW5jdGlvbnMgYWNyb3NzIG1vZGVs IGF0IGFsbCBjb3N0cy4gVGhpcyBzaG91bGQgbm90IGludmFsaWRhdGUgZWl0aGVyIGFwcHJvYWNo LCBvbmx5IG9ic2VydmUgdGhhdCB0aGV5IGFyZSBkaWZmZXJlbnQuDQoNClRoaXJkLCBleGFjdGx5 IGxpa2UgdGhlIEwzU00gZHJhZnQsIHRoZSBMMlNNIGRyYWZ0IGluY2x1ZGVzIGEgbnVtYmVyIG9m IHRlY2hub2xvZ3ktc3BlY2lmaWMgcGFyYW1ldGVycyBhbmQgdGhlc2UgaGF2ZSBjYXVzZWQgcGVv cGxlIHRvIGNsYWltIHRoYXQgdGhlIEktRCBtdXN0IGJlIGRlc2NyaWJpbmcgYSBub3JtYWxpc2Vk IG9yIGNvbmZpZ3VyYXRpb24gbW9kZWwuIEJ1dCAob2YgY291cnNlPykgdGhlIHBhcmFtZXRlcnMg YXJlIG5lZWRlZCB0byBjb25maWd1cmUgdGhlIENFLVBFIGFjY2VzcyBjb25uZWN0aW9ucy4gVGhp cyBpcyBhIHN1aXRhYmxlIHBvaW50IG9mIGRpZmZlcmVudGlhdGlvbiBiZXR3ZWVuIE1FRiBhbmQg TDJTTSB0aGF0IE1FRiBoYXMgd29ya2VkIG9uIENFLWJhc2VkIG1vZGVscyB3aGlsZSBMMlNNIHdp bGwgd29yayBvbiBQRS1iYXNlZCBtb2RlbHMuIEluZGVlZCwgdGhlIElFVEYgd29ya3Mgb24gdGhl IG5ldHdvcmtpbmcgYXNwZWN0cy4gSG93ZXZlciwgd2hlbiBhIGJ1aWxkaW5nIGlzIGRvbmUgc29t ZXdoZXJlIGVsc2UgKHR5cGljYWwgZXhhbXBsZSwgU0xBIG1hbmFnZW1lbnQgZG9uZSBpbiBNRUYp LCB0aGlzIEwyU00gWUFORyBtb2R1bGUgc2hvdWxkIG9ubHkgY29udGFpbiBhIHBsYWNlIGhvbGRl ciBvciBhIHBvaW50ZXIuDQoNCkZvdXJ0aC4gRGlzY3Vzc2luZyB0aG9zZSB2ZXJ5IHRvcGljcyBs aXZlIHdpdGggU2NvdHQgTWFuc2ZpZWxkIChvdXIgTUVGIC0gSUVURiBsaWFpc29uIG1hbmFnZXIp IGR1cmluZyBhIHdvcmtzaG9wIHJlY2VudGx5LCB3ZSBhZ3JlZSB0aGF0IGJvdGggSUVURiBhbmQg TUVGIHNlcnZpY2UgbW9kZWxzIGhhdmUgYSBwbGFjZS4gV2hpbGUgd2Ugc3RhcnQgdG8gc2VlIHNv bWUgY29uc29saWRhdGlvbiBpbiB0ZXJtcyBvZiBZQU5HIG1vZHVsZXMgZm9yIGRldmljZSBtYW5h Z2VtZW50LCB3ZSBhcmUgb25seSBhdCB0aGUgYmVnaW5uaW5nIG9mIFlBTkcgc2VydmljZSBtb2R1 bGVzLiANCg0KSSBob3BlIHRoaXMgaXMgdXNlZnVsIGFuZCB0aGF0IGl0IGNsYXJpZmllcyB0aGUg c2l0dWF0aW9uLg0KDQpSZWdhcmRzLCBCZW5vaXQNCkhpLCBPdXIgY2hhcnRlciBtYW5kYXRlcyB0 aGF0IHdlIGNvbnNpZGVyIGJhc2luZyBvdXIgd29yayBvbmRyYWZ0LXdlbi1sMnNtLWwydnBuLXNl cnZpY2UtbW9kZWwtMDMudHh0IEFzIHdlIGRpc2N1c3NlZCBpbiB0aGUgbWVldGluZywgdGhhdCBk cmFmdCBpcyBub3QgcGVyZmVjdC4gQnV0IHdoZW4gSSBhc2tlZCB0aGVyb29tIHdoZXRoZXIgd2Ug dGhvdWdodCB0aGF0IGl0IHdvdWxkIHByb3ZpZGUgYSBnb29kIHN0YXJ0aW5nIHBvaW50IHRoYXQg d2Vjb3VsZCB3b3JrIHdpdGggdG8gcG9saXNoIGFuZCBhZGFwdCB0byBiZWNvbWUgdGhlIEktRCB0 aGF0IHdlIHVsdGltYXRlbHkgc3VibWl0Zm9yIHB1YmxpY2F0aW9uIGFzIGFuIFJGQywgSSBiZWxp ZXZlIEkgaGVhcmQgYSBnb29kIGh1bSBpbiBmYXZvdXIgYW5kIHNpbGVuY2UgaW5vcHBvc2l0aW9u LiBTbyB0aGlzIGVtYWlsIHN0YXJ0cyBhIGZvcm1hbCBwb2xsIGZvciBhZG9wdGlvbi4gUGxlYXNl IGFuc3dlcjogRG8geW91IHRoaW5rIHRoYXQgdGhlIFdHIHNob3VsZCBhZG9wdCBkcmFmdC13ZW4t bDJzbS1sMnZwbi1zZXJ2aWNlLW1vZGVsLTAzLnR4dD8gSWYgInllcywiIGl0IHdvdWxkIGhlbHAg aWYgeW91IGNvdWxkIGluZGljYXRlIHdoZXRoZXIgeW91IGhhdmUgcmVhZCB0aGUgZHJhZnRhbmQg aG93IGhhcHB5IHlvdSBhcmUgd2l0aCBpdC5JZiAibm8iLCBpdCBpcyBpbXBvcnRhbnQgdGhhdCB5 b3UgcHJvdmlkZSByZWFzb25zLiBUaGlzIHBvbGwgd2lsbCBsYXN0IGZvciB0d28gd2Vla3MsIGVu ZGluZyBvbiBTYXR1cmRheSAzcmQgRGVjZW1iZXIuIEp1c3QgdG8gcmVhc3N1cmUgZXZlcnlvbmUg dGhhdCBhZG9wdGlvbiBkb2VzIG5vdCBpbXBseSB0aGF0IGFueXRoaW5nIGlzIHNldCBpbnN0b25l OiB3ZSBleHBlY3QgdGhlIFdHIHRvIGNvbnRpbnVlIHRvIGRldmVsb3AgdGhlIGNvbnRlbnQgYW5k IGNoYW5nZSB3aGF0ZXZlcm5lZWRzIHRvIGJlIGNoYW5nZWQuIFRoYW5rcyxBZHJpYW4gYW5kIFFp biBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX0wyc20gbWFp bGluZyBsaXN0TDJzbUBpZXRmLm9yZ2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbDJzbS4gDQogDQo= ------=_001_NextPart505020173620_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0A=0A
Hi, Adrian,

Firstly, thank you f= or writing the long mail to illustrate = of the status of the l2sm. 
Secondly, I suppo= rt this draft can be adopted as early&n= bsp;as possible. China Telecom is one of&nbs= p;the operators who offer L2VPN service, in&= nbsp;most cases, in joint with foreign opera= tors. The service model like L2SM will make&= nbsp;the service provisioning more flexible and&n= bsp;quicker.

Thank you!
Chongfeng  =0A
=

Hi all,

 

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

 

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

 

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

 

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

 

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

 

=

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

&nb= sp;

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

 

1. This document should not include protocol-spec= ific details.

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

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-= serif";mso-bidi-font-family:"Times New Roman";color:#1F497D= ">Clearly when the service is a CE-mode VPN those details don't apply.

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-= serif";mso-bidi-font-family:"Times New Roman";color:#1F497D= ">In Seoul, we received an offer to go through the current document and fl= ag the protocol parameters that are a concern. I hope that this can be don= e so that those of us who don't think there is a problem can better unders= tand what the concern is.

 

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

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

On the other hand, attempts to map this se= rvice modelling approach into the MEF LSO architecture have not been entir= ely successful (with lots of differing opinions and some suggestions that = parts of multiple LSO reference points are captured in this model). That s= uggests to me that what is going on in L2SM is closer to a parallel with L= 3SM than a duplication of MEF work. It may be a different approach or a di= fferent thing.

 

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

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

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

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

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

 

Bottom line:

 

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

   continue their work.

=

   - Address specific issues raised= in Seoul

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

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

     see how the model is used

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

<= p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 12pt; = font-family: 'Times New Roman', serif; color: black;">      progress MEF work.

 

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

   it = is currently something that we can use for a starting point for our work.<= o:p>

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

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

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

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

 

Thanks,

Adrian

 

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

=  

Dear= all,

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

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

We really need th= is to be driven by Operators
    - Of course, vendors ca= n and should participate
    - But be aware of how the d= ata model is use  

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

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

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

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

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

Regards, Benoit= 

Hi,
 
Our charter ma=
ndates that we consider basing our work on
draft-wen-l2sm-l2vpn-service-model-03.txt
 
As w=
e discussed in the meeting, that draft is not perfect. But when I asked th=
e
room whether we thought that i=
t would provide a good starting point that we
could work with to polish and adapt to become the I-D that=
 we ultimately submit
for public=
ation as an RFC, I believe I heard a good hum in favour and silence in
opposition.
 
So thi=
s email starts a formal poll for adoption. Please answer:
= 
 
Do you think that the WG should adopt draft-wen-l2sm-l2vpn-service-model-=
03.txt?
 
<= pre style=3D"margin: 0cm 0cm 0.0001pt; font-size: 10pt; font-family: 'Cour= ier New'; color: black;">If "yes," it would help if you could indicate whe= ther you have read the draft
and=
 how happy you are with it.
If "=
no", it is important that you provide reasons.
 
This poll=
 will last for two weeks, ending on Saturday 3rd December.
 
stone: we expect the WG t=
o continue to develop the content and change whatever
needs to be changed.
 
Thanks,
Adrian and Qin
 
______=
_________________________________________
L2sm mailing list
L2sm@ietf.org
https://www.ietf.org/mailman/listinfo/l2sm
.
 

 

<= /blockquote>=0A ------=_001_NextPart505020173620_=------ From nobody Tue Jan 3 11:19:25 2017 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 5F82F129B04 for ; Tue, 3 Jan 2017 11:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq0cUAiFOmmv for ; Tue, 3 Jan 2017 11:19:22 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 494D5129AE5 for ; Tue, 3 Jan 2017 11:19:21 -0800 (PST) X-AuditID: c6180641-e87ff70000000a0b-dd-586ba4cc4a31 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by (Symantec Mail Security) with SMTP id E1.F2.02571.CC4AB685; Tue, 3 Jan 2017 14:19:10 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 14:19:18 -0500 From: Scott Mansfield To: Benoit Claise , "adrian@olddog.co.uk" , "l2sm@ietf.org" Thread-Topic: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt Thread-Index: AQHSXFl6C4zNlwTvBUSSUw5sf+rGa6EnMKWA Date: Tue, 3 Jan 2017 19:19:18 +0000 Message-ID: References: <0d4501d24132$62ceb590$286c20b0$@olddog.co.uk> <5b6dbba2-d283-8c81-7aaa-152d05ebdb8c@cisco.com> In-Reply-To: <5b6dbba2-d283-8c81-7aaa-152d05ebdb8c@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_EF35EE4B92789843B1DECBC0E24558644C65254Feusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLrHW/fckuwIg8f7bSx+9Nxgtjj6WMLi zsuXjA7MHlN+b2T1WLLkJ5PHis0rGQOYo7hsUlJzMstSi/TtErgy5p86y1iwuqSic/5ilgbG e0ldjJwcEgImEvu7TzJ3MXJxCAmsZ5Ro6+uAcpYxSjT9b2QHqWIDqtq6azojiC0iUCqx78Be ZhBbWCBQYt2fz0BxDqB4kMSNO3IQJUYS5xdfAmtlEVCROLF4ERuIzSvgK7Hy+ClWkHIhgVyJ Z3MzQUxOAVuJr4u9QCoYBcQkvp9awwRiMwuIS9x6Mp8J4kwBiSV7zjND2KISLx//Y4WwlSTm vL7GDFGfL7G/8Sw7xCZBiZMzn7BMYBSehWTULCRls5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPg MROy+AJG9lWMHKXFBTm56UaGmxiBMXNMgs1xB+PeXs9DjAIcjEo8vAYt2RFCrIllxZW5hxgl OJiVRHjjvgCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ814PuR8uJJCeWJKanZpakFoEk2Xi4JRq YFQQKN2xR/WF+Unevadu5FprZUWGcZrdeVYl8/ZMwMeVs8oLNpw2CW/vOZ9y8vIC+a87Sy7y pDVL+S/7tuu3Tf1zI24twQU1jY3K2/+zGu5Qcjksznfg+nXGZIvpE7u/5k2YFvx7dddsQ/3Q MLXa9zPd048pvX8d89NniUZABeeFTdyL+0wnliuxFGckGmoxFxUnAgCLqa2GlQIAAA== Archived-At: Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 19:19:24 -0000 --_000_EF35EE4B92789843B1DECBC0E24558644C65254Feusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Benoit. There are many dimensions to the modeling space and w= e can't let the perfect be the enemy of the good. Constant communication a= nd sharing will help alignment while allowing the people that actually run = networks to get what they need. 30+ years of object-oriented software deve= lopment (should have) taught all designers/architects/programmers that the = first iteration of a solution is not the best and most optimized. Each ite= ration provides the opportunity to abstract, refine, refactor, and extend. = Proper information hiding and encapsulation is key. Automation is very im= portant and we need to work together to ensure that whatever models that ar= e created are supported by tools that allow for effective reuse and extensi= ons. Regards, -scott. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Thursday, December 22, 2016 8:44 AM To: adrian@olddog.co.uk; l2sm@ietf.org; Scott Mansfield Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03= .txt Dear all, A couple of reflections on L2SM, just before the end of year break. First, I want to quote one chairs slides https://www.ietf.org/proceedings/9= 7/slides/slides-97-l2sm-chairs-slides-01.pdf: We really need this to be driven by Operators - Of course, vendors can and should participate - But be aware of how the data model is use I'm always baffled when vendors 'seem to) know better than the operators wh= at they need. I don't believe we have spent enough time listening to the fe= w operators in the room during the WG meeting. We have here a group of operators who want to do work in the IETF, and we s= hould respect that. Second, on the differences between IETF and MEF service management. MEF wants to go for the full LSO architecture (billing, SLA, order manageme= nt, etc.). Perfect. L2SM charter wants to do something similar to L3SM: a self-contained servic= e YANG module. It would be nice to try to fit the L2SM service models in the MEF LSO archi= tecture, but the L2SM work follows a different architectural model to LSO, = and that there is no value in trying to match the functions across model at= all costs. This should not invalidate either approach, only observe that t= hey are different. Third, exactly like the L3SM draft, the L2SM draft includes a number of tec= hnology-specific parameters and these have caused people to claim that the = I-D must be describing a normalised or configuration model. But (of course?= ) the parameters are needed to configure the CE-PE access connections. This= is a suitable point of differentiation between MEF and L2SM that MEF has w= orked on CE-based models while L2SM will work on PE-based models. Indeed, t= he IETF works on the networking aspects. However, when a building is done s= omewhere else (typical example, SLA management done in MEF), this L2SM YANG= module should only contain a place holder or a pointer. Fourth. Discussing those very topics live with Scott Mansfield (our MEF - I= ETF liaison manager) during a workshop recently, we agree that both IETF an= d MEF service models have a place. While we start to see some consolidation= in terms of YANG modules for device management, we are only at the beginni= ng of YANG service modules. I hope this is useful and that it clarifies the situation. Regards, Benoit Hi, Our charter mandates that we consider basing our work on draft-wen-l2sm-l2vpn-service-model-03.txt As we discussed in the meeting, that draft is not perfect. But when I asked= the room whether we thought that it would provide a good starting point that we could work with to polish and adapt to become the I-D that we ultimately su= bmit for publication as an RFC, I believe I heard a good hum in favour and silen= ce in opposition. So this email starts a formal poll for adoption. Please answer: Do you think that the WG should adopt draft-wen-l2sm-l2vpn-service-model-03= .txt? If "yes," it would help if you could indicate whether you have read the dra= ft and how happy you are with it. If "no", it is important that you provide reasons. This poll will last for two weeks, ending on Saturday 3rd December. Just to reassure everyone that adoption does not imply that anything is set= in stone: we expect the WG to continue to develop the content and change whate= ver needs to be changed. Thanks, Adrian and Qin _______________________________________________ L2sm mailing list L2sm@ietf.org https://www.ietf.org/mailman/listinfo/l2sm . --_000_EF35EE4B92789843B1DECBC0E24558644C65254Feusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Benoit.  There a= re many dimensions to the modeling space and we can’t let the perfect= be the enemy of the good.  Constant communication and sharing will help alignment while allowing the people that actually run networks t= o get what they need.  30+ years of object-oriented software devel= opment (should have) taught all designers/architects/programmers that the f= irst iteration of a solution is not the best and most optimized.  Each iteration provides the opportunity to abstr= act, refine, refactor, and extend.  Proper information hiding and enca= psulation is key.  Automation is very important and we need to work to= gether to ensure that whatever models that are created are supported by tools that allow for effective reuse and extensio= ns.

 

Regards,

-scott.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, December 22, 2016 8:44 AM
To: adrian@olddog.co.uk; l2sm@ietf.org; Scott Mansfield <scott.ma= nsfield@ericsson.com>
Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-m= odel-03.txt

 

Dear all,

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

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

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

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

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

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

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

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

Regards, Benoit

Hi,
 
Our charter mandates that we consider basing our work on

draft-wen-l2sm-l2vpn-service-model-03.txt


 


As we discussed in the meeting, that draft is not perfect. But when I =
asked the


room whether we thought that it would provide a good starting point th=
at we


could work with to polish and adapt to become the I-D that we ultimate=
ly submit


for publication as an RFC, I believe I heard a good hum in favour and =
silence in


opposition.


 


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


 


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


 


If "yes," it would help if you could indicate whether you ha=
ve read the draft


and how happy you are with it.


If "no", it is important that you provide reasons.


 


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


 


Just to reassure everyone that adoption does not imply that anything i=
s set in


stone: we expect the WG to continue to develop the content and change =
whatever


needs to be changed.


 


Thanks,


Adrian and Qin


 


_______________________________________________


L2sm mailing list


L2sm@ietf.org


https://www.iet=
f.org/mailman/listinfo/l2sm


.


 

 

--_000_EF35EE4B92789843B1DECBC0E24558644C65254Feusaamb105erics_-- From nobody Wed Jan 4 02:14:25 2017 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 6C3FD128DF6 for ; Wed, 4 Jan 2017 02:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.611 X-Spam-Level: X-Spam-Status: No, score=-17.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 qjlNXEauK2lY for ; Wed, 4 Jan 2017 02:14:21 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE5E12711D for ; Wed, 4 Jan 2017 02:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22583; q=dns/txt; s=iport; t=1483524861; x=1484734461; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=O8KqSr/xKKjJBdZEENNSLpWUi65lzemek1pXEg4XSxE=; b=d/BgZDyy7sOfpOhmuUhCaKrtfUGur1bUylr/zE6SpBriqX1nOSxI9YJL 57sUsIp30eWQT49fG9DUETrxE4rVREL+5UQfDPZNlF/TdDt8aSlUKJBrZ ZUB72cigfJ6xAsIQ/PphmkSzQYaUNGqe9dosOW5GZbgkKKe0n5t3lZGH5 4=; X-IronPort-AV: E=Sophos;i="5.33,458,1477958400"; d="scan'208,217";a="691049151" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2017 10:14:19 +0000 Received: from [10.63.23.55] (dhcp-ensft1-uk-vla370-10-63-23-55.cisco.com [10.63.23.55]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v04AEJbO010060; Wed, 4 Jan 2017 10:14:19 GMT To: Scott Mansfield , Benoit Claise , "adrian@olddog.co.uk" , "l2sm@ietf.org" References: <0d4501d24132$62ceb590$286c20b0$@olddog.co.uk> <5b6dbba2-d283-8c81-7aaa-152d05ebdb8c@cisco.com> From: David Ball Message-ID: <692649e6-0f18-f643-9768-64abf744749b@cisco.com> Date: Wed, 4 Jan 2017 10:14:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------08752243C1908FF56DCAB272" Archived-At: Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 10:14:24 -0000 This is a multi-part message in MIME format. --------------08752243C1908FF56DCAB272 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Scott, I agree; but what is being proposed is not iteration, reuse and extension, which you rightly extol. It is instead ignoring all the work that has gone before (not just the MEF yang models, but the 10+ years of work MEF has done in defining Carrier Ethernet services). Benoit, to answer your points: * You are correct that MEF has a grand vision for the LSO architecture; time will tell whether that is achievable. However, the one small part of it that they are furthest progressed with is exactly the same area that is covered by L2SM. I don't understand why you think L2SM is following a different architecture; in both cases what we are talking about is a model for the set of things that need to be agreed between the SP and the customer, right? * I can't speak for anyone else, but my criticism regarding the inclusion of "technology-specific parameters", as you put it, is not in respect of the PE-CE links. I agree the technology details are needed there. However, the draft also includes a lot of details about the technology used within the SP's network (i.e., PE-PE) - that is the detail which I think is not relevant and does not belong in a service model. * I do not understand what you mean when you say the MEF has worked on CE-based models. A service model is not used between the CE and PE, it is used between the customer's management systems (as the client) and the SP's management systems (as the server). There are differences in terminology for those systems, but fundamentally I don't see any difference between MEF and IETF approach here. Can you clarify what you meant? Benoit, you mentioned that, as vendors, we should listen more to operators. I agree. I would love to hear from the operators who support adoption of this draft what issues they see with the MEF models, and why they believe that starting again from scratch in IETF is a better option than working with MEF to improve on what they have already done, and then augmenting ("extending") it to fill in any gaps. The MEF models are certainly far from perfect (and of course they are still WIP in MEF), but what I would like to understand is why you, as operators, think they are not a good starting point for solving the problems that led to the creation of this WG. David On 03/01/2017 19:19, Scott Mansfield wrote: > > I agree with Benoit. There are many dimensions to the modeling space > and we can’t let the perfect be the enemy of the good. Constant > communication and sharing will help alignment while allowing the > people that actually run networks to get what they need. 30+ years of > object-oriented software development (should have) taught all > designers/architects/programmers that the first iteration of a > solution is not the best and most optimized. Each iteration provides > the opportunity to abstract, refine, refactor, and extend. Proper > information hiding and encapsulation is key. Automation is very > important and we need to work together to ensure that whatever models > that are created are supported by tools that allow for effective reuse > and extensions. > > Regards, > > -scott. > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Thursday, December 22, 2016 8:44 AM > *To:* adrian@olddog.co.uk; l2sm@ietf.org; Scott Mansfield > > *Subject:* Re: [L2sm] Adoption poll for > draft-wen-l2sm-l2vpn-service-model-03.txt > > Dear all, > > A couple of reflections on L2SM, just before the end of year break. > > First, I want to quote one chairs slides > https://www.ietf.org/proceedings/97/slides/slides-97-l2sm-chairs-slides-01.pdf: > > > > We really need this to be driven by Operators > - Of course, vendors can and should participate > - But be aware of how the data model is use > > I'm always baffled when vendors 'seem to) know better than the > operators what they need. I don't believe we have spent enough time > listening to the few operators in the room during the WG meeting. > We have here a group of operators who want to do work in the IETF, and > we should respect that. > > Second, on the differences between IETF and MEF service management. > MEF wants to go for the full LSO architecture (billing, SLA, order > management, etc.). Perfect. > L2SM charter wants to do something similar to L3SM: a self-contained > service YANG module. > It would be nice to try to fit the L2SM service models in the MEF LSO > architecture, but the L2SM work follows a different architectural > model to LSO, and that there is no value in trying to match the > functions across model at all costs. This should not invalidate either > approach, only observe that they are different. > > Third, exactly like the L3SM draft, the L2SM draft includes a number > of technology-specific parameters and these have caused people to > claim that the I-D must be describing a normalised or configuration > model. But (of course?) the parameters are needed to configure the > CE-PE access connections. This is a suitable point of differentiation > between MEF and L2SM that MEF has worked on CE-based models while L2SM > will work on PE-based models. Indeed, the IETF works on the networking > aspects. However, when a building is done somewhere else (typical > example, SLA management done in MEF), this L2SM YANG module should > only contain a place holder or a pointer. > > Fourth. Discussing those very topics live with Scott Mansfield (our > MEF - IETF liaison manager) during a workshop recently, we agree that > both IETF and MEF service models have a place. While we start to see > some consolidation in terms of YANG modules for device management, we > are only at the beginning of YANG service modules. > > I hope this is useful and that it clarifies the situation. > > Regards, Benoit > > Hi, > > Our charter mandates that we consider basing our work on > > draft-wen-l2sm-l2vpn-service-model-03.txt > > As we discussed in the meeting, that draft is not perfect. But when I asked the > > room whether we thought that it would provide a good starting point that we > > could work with to polish and adapt to become the I-D that we ultimately submit > > for publication as an RFC, I believe I heard a good hum in favour and silence in > > opposition. > > So this email starts a formal poll for adoption. Please answer: > > Do you think that the WG should adopt draft-wen-l2sm-l2vpn-service-model-03.txt? > > If "yes," it would help if you could indicate whether you have read the draft > > and how happy you are with it. > > If "no", it is important that you provide reasons. > > This poll will last for two weeks, ending on Saturday 3rd December. > > Just to reassure everyone that adoption does not imply that anything is set in > > stone: we expect the WG to continue to develop the content and change whatever > > needs to be changed. > > Thanks, > > Adrian and Qin > > _______________________________________________ > > L2sm mailing list > > L2sm@ietf.org > > https://www.ietf.org/mailman/listinfo/l2sm > > . > > > > _______________________________________________ > L2sm mailing list > L2sm@ietf.org > https://www.ietf.org/mailman/listinfo/l2sm -- David Ball --------------08752243C1908FF56DCAB272 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Scott,

I agree; but what is being proposed is not iteration, reuse and extension, which you rightly extol.  It is instead ignoring all the work that has gone before (not just the MEF yang models, but the 10+ years of work MEF has done in defining Carrier Ethernet services).

Benoit, to answer your points:

  • You are correct that MEF has a grand vision for the LSO architecture; time will tell whether that is achievable.  However, the one small part of it that they are furthest progressed with is exactly the same area that is covered by L2SM.  I don't understand why you think L2SM is following a different architecture; in both cases what we are talking about is a model for the set of things that need to be agreed between the SP and the customer, right?
  • I can't speak for anyone else, but my criticism regarding the inclusion of "technology-specific parameters", as you put it, is not in respect of the PE-CE links.  I agree the technology details are needed there.  However, the draft also includes a lot of details about the technology used within the SP's network (i.e., PE-PE) - that is the detail which I think is not relevant and does not belong in a service model.
  • I do not understand what you mean when you say the MEF has worked on CE-based models.  A service model is not used between the CE and PE, it is used between the customer's management systems (as the client) and the SP's management systems (as the server).  There are differences in terminology for those systems, but fundamentally I don't see any difference between MEF and IETF approach here.  Can you clarify what you meant?
Benoit, you mentioned that, as vendors, we should listen more to operators.  I agree.  I would love to hear from the operators who support adoption of this draft what issues they see with the MEF models, and why they believe that starting again from scratch in IETF is a better option than working with MEF to improve on what they have already done, and then augmenting ("extending") it to fill in any gaps.  The MEF models are certainly far from perfect (and of course they are still WIP in MEF), but what I would like to understand is why you, as operators, think they are not a good starting point for solving the problems that led to the creation of this WG.

    David

On 03/01/2017 19:19, Scott Mansfield wrote:

I agree with Benoit.  There are many dimensions to the modeling space and we can’t let the perfect be the enemy of the good.  Constant communication and sharing will help alignment while allowing the people that actually run networks to get what they need.  30+ years of object-oriented software development (should have) taught all designers/architects/programmers that the first iteration of a solution is not the best and most optimized.  Each iteration provides the opportunity to abstract, refine, refactor, and extend.  Proper information hiding and encapsulation is key.  Automation is very important and we need to work together to ensure that whatever models that are created are supported by tools that allow for effective reuse and extensions.

 

Regards,

-scott.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, December 22, 2016 8:44 AM
To: adrian@olddog.co.uk; l2sm@ietf.org; Scott Mansfield <scott.mansfield@ericsson.com>
Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt

 

Dear all,

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

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

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

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

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

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

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

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

Regards, Benoit

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

 



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


-- 
David Ball
<daviball@cisco.com>
--------------08752243C1908FF56DCAB272-- From nobody Wed Jan 11 12:52:00 2017 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 E55A512945C for ; Wed, 11 Jan 2017 12:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 B1SYljTb3u1D for ; Wed, 11 Jan 2017 12:51:56 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 211BC129873 for ; Wed, 11 Jan 2017 12:51:55 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id v186so90815496lfa.1 for ; Wed, 11 Jan 2017 12:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LOrTsvHPRRD4hlVOF0m2zhaUgtNPTUJW3pc5mhIH18c=; b=JaVkQEUleXF/GNI2esHP+Jvr3r7Rpvel+G/nE3kn3ISDf+Auka6ciFvErP78stwk2K 8kCceQhuEkUhMLyy4K2T4W5tdLCDDswWrWlNabBDISfzzJ00mQnSWnsXH//jK3ARQ9gq zEw2BThnJl8sxMAzRWiq1WNkv4pOClYlyqO5bL1/doaNbTeD8H4kL/lGBPLkUeEPhgDD sqIJZ34TgT27laTEx755ifAfOQWQ5l95LyllaIGQmcC/8L3yzTML/L5hDJk+KfibcGga oboB98tckjO2h/5UiB+zknlJEjU//gr7VbmQ9EqOQYptIAY14wFE8hYQ9pLfiq31yakK RtCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LOrTsvHPRRD4hlVOF0m2zhaUgtNPTUJW3pc5mhIH18c=; b=S7dh1X+9e/TbaDjdm2lcF8Jn0W1X/l5BtaLL9f3gn/wiZgnwDRqelGBB1DdzCCbRhi ermLnGzNO4UeyGOPlJoxEszpqHMIsGdOUpbeYraNhHwhafGhQUnThPzq6W3hjkrOM6kx jleI4ZyIPzvavm8hPKYc4PACt1XJlJwQx8rjyFu3a3wcfJD2NLbeUKnsRHg/88toKRHa faqOBlt5FeFwX+Gr2WDAS2f2Rt1Nh8KMidFEKgU3um/zU93wgQfpRTbhBIMgmd83hNTv rQa6B6gcZtkSora3YSIUHIPFJp30vCQElTqO5SwSqIhQGvfTujvzAL7NRIaddF2Fi+vQ LmRQ== X-Gm-Message-State: AIkVDXL/J9XxgbAoPB0BNdFwZoTYIpda5b8DILmNJ8ofskCtJXxOPiHtwuhYDKmiTxAuv+5cK3KKyn/q0UDlVA== X-Received: by 10.25.132.6 with SMTP id g6mr4392261lfd.144.1484167913690; Wed, 11 Jan 2017 12:51:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.21.203 with HTTP; Wed, 11 Jan 2017 12:51:53 -0800 (PST) From: John Strassner Date: Wed, 11 Jan 2017 12:51:53 -0800 Message-ID: To: l2sm@ietf.org Content-Type: multipart/alternative; boundary=001a113eaa72485a850545d7c517 Archived-At: Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:51:59 -0000 --001a113eaa72485a850545d7c517 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, first, I would like to express support for the WG adopting this draft. Sorr= y that I'm not an operator :-) but I am actively involved in the MEF and other relevant IETF WGs. Second, some comments to Scott: > Hi Scott, > > I agree; but what is being proposed is not iteration, reuse and > extension, which you rightly extol. I disagree - the iteration is the continuous revision of the draft. The charter says that the WG "...will also coordinate with other organizations working on related L2VPN data models (such as the MEF)", which is good enough for me. > It is instead ignoring all the work > that has gone before (not just the MEF yang models, but the 10+ years of > work MEF has done in defining Carrier Ethernet services). I think that the L2SM charter is different than the Carrier Ethernet work done in the MEF. Where do you think they overlap, and why? > > Benoit, to answer your points: > > * You are correct that MEF has a grand vision for the LSO > architecture; time will tell whether that is achievable. However, > the one small part of it that they are furthest progressed with is > exactly the same area that is covered by L2SM. I don't understand > why you think L2SM is following a different architecture; in both > cases what we are talking about is a model for the set of things > that need to be agreed between the SP and the customer, right? I disagree. The charter says: ... 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. First, the MEF didn't start with the goal of creating a YANG data model; this by itself differentiates the resulting architectures and approaches. The fact that 10 years later the MEF added a YANG model doesn't make them equal. Indeed, the MEF (should) be defining its YANG model directly from its Core Info Model and relevant other models; in contrast, the IETF currently has no such info model from which to derive the L2SM YANG data model. Second, in reading Qin's opsawg draft, there is some similarity in how a "service model" is defined (e.g., emphasizing connectivity offered). However, I still view this as different from the current work done in the MEF. For example, I would hope that in the MEF, we would consider defining service models that are amenable to orchestration; that is clearly outside the scope of L2SM (at least now). > * I can't speak for anyone else, but my criticism regarding the > inclusion of "technology-specific parameters", as you put it, is not > in respect of the PE-CE links. I agree the technology details are > needed there. However, the draft also includes a lot of details > about the technology used within the SP's network (i.e., PE-PE) - > that is the detail which I think is not relevant and does not belong > in a service model. I do agree that some of those parameters should be removed. That shouldn't be considered as a reason for the WG to not adopt this draft. Indeed, it **should** be easier to gain consensus on what should and should not be included by working on it as a WG. Regarding the PE-PE technology, I viewed that as being part of the Service Delivery Model in the opsawg draft. Qin, please correct me if I am wrong here. > * I do not understand what you mean when you say the MEF has worked on > CE-based models. A service model is not used between the CE and PE, > it is used between the customer's management systems (as the client) > and the SP's management systems (as the server). There are > differences in terminology for those systems, but fundamentally I > don't see any difference between MEF and IETF approach here. Can > you clarify what you meant? I agree with David that the MEF model is **not** a CE-based model. I'm also not sure what is meant by that. As stated earlier, I disagree with David that the MEF and IETF approaches are the same - please see my above comments. > > Benoit, you mentioned that, as vendors, we should listen more to > operators. I agree. I would love to hear from the operators who > support adoption of this draft what issues they see with the MEF models, > and why they believe that starting again from scratch in IETF is a > better option than working with MEF to improve on what they have already > done, and then augmenting ("extending") it to fill in any gaps. The MEF > models are certainly far from perfect (and of course they are still WIP > in MEF), but what I would like to understand is why you, as operators, > think they are not a good starting point for solving the problems that > led to the creation of this WG. I would love to hear that as well, but this shouldn't be an impediment for the WG to adopt this draft. > > David >> >>On 03/01/2017 19:19, Scott Mansfield wrote: >> >> I agree with Benoit. There are many dimensions to the modeling space >> and we can=E2=80=99t let the perfect be the enemy of the good. Constant >> communication and sharing will help alignment while allowing the >> people that actually run networks to get what they need. 30+ years of >> object-oriented software development (should have) taught all >> designers/architects/programmers that the first iteration of a >> solution is not the best and most optimized. Each iteration provides >> the opportunity to abstract, refine, refactor, and extend. Proper >> information hiding and encapsulation is key. Automation is very >> important and we need to work together to ensure that whatever models >> that are created are supported by tools that allow for effective reuse >> and extensions. ... elided rest of message thread regards, John --=20 regards, John --001a113eaa72485a850545d7c517 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

first, I would like = to express support for the WG adopting this draft. Sorry
that I&#= 39;m not an operator :-) but I am actively involved in the MEF and
other relevant IETF WGs.

Second, some comments t= o Scott:

> Hi Scott,
>
> I agree; = but what is being proposed is not iteration, reuse and
> extension, = which you rightly extol.=C2=A0

I disagree - the it= eration is the continuous revision of the draft. The charter
says= that the WG "...will also coordinate with other organizations working=
on related L2VPN data models (such as the MEF)", which is g= ood enough
for me.

> It is instead ig= noring all the work
> that has gone before (not just the MEF yang mo= dels, but the 10+ years of
> work MEF has done in defining Carrier E= thernet services).

I think that the L2SM charter i= s different than the Carrier Ethernet work done
in the MEF. Where= do you think they overlap, and why?

>
> Benoit, to= answer your points:
>=C2=A0
>=C2=A0=C2=A0 * You are correct th= at MEF has a grand vision for the LSO
>=C2=A0=C2=A0=C2=A0=C2=A0 archi= tecture; time will tell whether that is achievable. However,
>=C2=A0= =C2=A0=C2=A0=C2=A0 the one small part of it that they are furthest progress= ed with is
>=C2=A0=C2=A0=C2=A0=C2=A0 exactly the same area that is co= vered by L2SM.=C2=A0 I don't understand
>=C2=A0=C2=A0=C2=A0=C2=A0= why you think L2SM is following a different architecture; in both
>= =C2=A0=C2=A0=C2=A0=C2=A0 cases what we are talking about is a model for the= set of things
>=C2=A0=C2=A0=C2=A0=C2=A0 that need to be agreed betwe= en the SP and the customer, right?

I disagree. The= charter says:

=C2=A0=C2=A0=C2=A0 ... is a short-l= ived WG. It is tasked to create a YANG data model that
=C2=A0=C2= =A0=C2=A0 describes a L2VPN service (a L2VPN customer service model). The
=C2=A0=C2=A0=C2=A0 model can be used for communication between cus= tomers and
=C2=A0=C2=A0=C2=A0 network operators, and to provide i= nput to automated control and
=C2=A0=C2=A0=C2=A0 configuration a= pplications.

First, the MEF didn't start with = the goal of creating a YANG data model;
this by itself differenti= ates the resulting architectures and approaches.
The fact that 10= years later the MEF added a YANG model doesn't
make them equ= al. Indeed, the MEF (should) be defining its YANG
model directly = from its Core Info Model and relevant other models; in
contrast, = the IETF currently has no such info model from which to
derive th= e L2SM YANG data model.

Second, in reading Qin'= ;s opsawg draft, there is some similarity in how
a "service = model" is defined (e.g., emphasizing connectivity offered).
= However, I still view this as different from the current work done in
=
the MEF. For example, I would hope that in the MEF, we would
consider defining service models that are amenable to orchestration;
=
that is clearly outside the scope of L2SM (at least now).
>=C2=A0=C2=A0 * I can't speak for anyone else, but my criticism re= garding the
>=C2=A0=C2=A0=C2=A0=C2=A0 inclusion of "technology-s= pecific parameters", as you put it, is not
>=C2=A0=C2=A0=C2=A0= =C2=A0 in respect of the PE-CE links.=C2=A0 I agree the technology details = are
>=C2=A0=C2=A0=C2=A0=C2=A0 needed there.=C2=A0 However, the draft = also includes a lot of details
>=C2=A0=C2=A0=C2=A0=C2=A0 about the te= chnology used within the SP's network (i.e., PE-PE) -
>=C2=A0=C2= =A0=C2=A0=C2=A0 that is the detail which I think is not relevant and does n= ot belong
>=C2=A0=C2=A0=C2=A0=C2=A0 in a service model.
I do agree that some of those parameters should be removed. Tha= t
shouldn't be considered as a reason for the WG to not adopt= this
draft. Indeed, it **should** be easier to gain consensus on= what should
and should not be included by working on it as a WG.=

Regarding the PE-PE technology, I viewed that as = being part of the
Service Delivery Model in the opsawg draft. Qin= , please correct me
if I am wrong here.

>=C2=A0= =C2=A0 * I do not understand what you mean when you say the MEF has worked = on
>=C2=A0=C2=A0=C2=A0=C2=A0 CE-based models.=C2=A0 A service model i= s not used between the CE and PE,
>=C2=A0=C2=A0=C2=A0=C2=A0 it is use= d between the customer's management systems (as the client)
>=C2= =A0=C2=A0=C2=A0=C2=A0 and the SP's management systems (as the server).= =C2=A0 There are
>=C2=A0=C2=A0=C2=A0=C2=A0 differences in terminology= for those systems, but fundamentally I
>=C2=A0=C2=A0=C2=A0 =C2=A0don= 't see any difference between MEF and IETF approach here.=C2=A0 Can
= >=C2=A0=C2=A0=C2=A0 =C2=A0you clarify what you meant?

I agree with David that the MEF model is **not** a CE-based model. I= 'm
also not sure what is meant by that.

<= div>As stated earlier, I disagree with David that the MEF and IETF approach= es
are the same - please see my above comments.

>= ;
> Benoit, you mentioned that, as vendors, we should listen more to=
> operators.=C2=A0 I agree.=C2=A0 I would love to hear from the ope= rators who
> support adoption of this draft what issues they see wit= h the MEF models,
> and why they believe that starting again from sc= ratch in IETF is a
> better option than working with MEF to improve = on what they have already
> done, and then augmenting ("extendi= ng") it to fill in any gaps.=C2=A0 The MEF
> models are certain= ly far from perfect (and of course they are still WIP
> in MEF), but= what I would like to understand is why you, as operators,
> think t= hey are not a good starting point for solving the problems that
> le= d to the creation of this WG.

I would love to hear= that as well, but this shouldn't be an impediment for
the WG= to adopt this draft.

>
>=C2=A0=C2=A0=C2=A0 David
>>
>>On 03/01/2017 19:19, Scott Mansfield wrote:
= >>
>> I agree with Benoit.=C2=A0 There are many dimensions t= o the modeling space
>> and we can=E2=80=99t let the perfect be t= he enemy of the good.=C2=A0 Constant
>> communication and sharing= will help alignment while allowing the
>> people that actually r= un networks to get what they need.=C2=A0 30+ years of
>> object-o= riented software development (should have) taught all
>> designer= s/architects/programmers that the first iteration of a
>> solutio= n is not the best and most optimized. Each iteration provides
>> = the opportunity to abstract, refine, refactor, and extend.=C2=A0 Proper >> information hiding and encapsulation is key.=C2=A0 Automation is = very
>> important and we need to work together to ensure that wha= tever models
>> that are created are supported by tools that allo= w for effective reuse
>> and extensions.

...

elided rest of message thread

<= /div>

regards,
John

--
regards,
John
--001a113eaa72485a850545d7c517-- From nobody Wed Jan 11 21:52:43 2017 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 D9473129488 for ; Wed, 11 Jan 2017 21:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 eU7h0fmaR94x for ; Wed, 11 Jan 2017 21:52:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4FF12943B for ; Wed, 11 Jan 2017 21:52:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYQ67566; Thu, 12 Jan 2017 05:52:36 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 12 Jan 2017 05:52:35 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.43]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 12 Jan 2017 13:51:47 +0800 From: Qin Wu To: John Strassner , "l2sm@ietf.org" Thread-Topic: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt Thread-Index: AQHSbJf2T9wdissAAkujXPHJj+CEEg== Date: Thu, 12 Jan 2017 05:51:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.218] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9A751B3Enkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.587719A5.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.43, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9f589624d8aa4ae52ce80a9e2451103a Archived-At: Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 05:52:42 -0000 --_000_B8F9A780D330094D99AF023C5877DABA9A751B3Enkgeml513mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAgICogSSBjYW4ndCBzcGVhayBmb3IgYW55b25lIGVsc2UsIGJ1dCBteSBjcml0aWNpc20gcmVn YXJkaW5nIHRoZQ0KPiAgICAgaW5jbHVzaW9uIG9mICJ0ZWNobm9sb2d5LXNwZWNpZmljIHBhcmFt ZXRlcnMiLCBhcyB5b3UgcHV0IGl0LCBpcyBub3QNCj4gICAgIGluIHJlc3BlY3Qgb2YgdGhlIFBF LUNFIGxpbmtzLiAgSSBhZ3JlZSB0aGUgdGVjaG5vbG9neSBkZXRhaWxzIGFyZQ0KPiAgICAgbmVl ZGVkIHRoZXJlLiAgSG93ZXZlciwgdGhlIGRyYWZ0IGFsc28gaW5jbHVkZXMgYSBsb3Qgb2YgZGV0 YWlscw0KPiAgICAgYWJvdXQgdGhlIHRlY2hub2xvZ3kgdXNlZCB3aXRoaW4gdGhlIFNQJ3MgbmV0 d29yayAoaS5lLiwgUEUtUEUpIC0NCj4gICAgIHRoYXQgaXMgdGhlIGRldGFpbCB3aGljaCBJIHRo aW5rIGlzIG5vdCByZWxldmFudCBhbmQgZG9lcyBub3QgYmVsb25nDQo+ICAgICBpbiBhIHNlcnZp Y2UgbW9kZWwuDQoNCkkgZG8gYWdyZWUgdGhhdCBzb21lIG9mIHRob3NlIHBhcmFtZXRlcnMgc2hv dWxkIGJlIHJlbW92ZWQuIFRoYXQNCnNob3VsZG4ndCBiZSBjb25zaWRlcmVkIGFzIGEgcmVhc29u IGZvciB0aGUgV0cgdG8gbm90IGFkb3B0IHRoaXMNCmRyYWZ0LiBJbmRlZWQsIGl0ICoqc2hvdWxk KiogYmUgZWFzaWVyIHRvIGdhaW4gY29uc2Vuc3VzIG9uIHdoYXQgc2hvdWxkDQphbmQgc2hvdWxk IG5vdCBiZSBpbmNsdWRlZCBieSB3b3JraW5nIG9uIGl0IGFzIGEgV0cuDQoNClJlZ2FyZGluZyB0 aGUgUEUtUEUgdGVjaG5vbG9neSwgSSB2aWV3ZWQgdGhhdCBhcyBiZWluZyBwYXJ0IG9mIHRoZQ0K U2VydmljZSBEZWxpdmVyeSBNb2RlbCBpbiB0aGUgb3BzYXdnIGRyYWZ0LiBRaW4sIHBsZWFzZSBj b3JyZWN0IG1lDQppZiBJIGFtIHdyb25nIGhlcmUuDQoNCltRaW5dOiBUaGFua3MgSm9obiBmb3Ig Y2xhcmlmaWNhdGlvbiBhbmQgY29tbWVudHMuDQpTZXJ2aWNlIERlbGl2ZXJ5IE1vZGVsIGlzIHJl YWxseSBhYm91dCBob3cgdGhlIHNlcnZpY2UgaXMgZGVsaXZlcmVkIGFuZCByZWFsaXplZCB3aGls ZSBMMlNNIG1vZGVsIGlzIGFib3V0IHdoYXQgdGhlIHNlcnZpY2UgaXMsIHdoYXQga2luZCBvZiB0 ZWNobm9sb2dpZXMgYXZhaWxhYmxlIHlvdSBjYW4gc3VwcG9ydC4NClNlcnZpY2UgRGVsaXZlcnkg TW9kZWwgaXMgYSBtb2RlbCB0aGF0IGhhcyBhbHJlYWR5IGJlZW4gaW5zdGFudGlhdGVkLCBlLmcu LCBWUkYgc3BlY2lmaWMgZGV0YWlsZWQgcGFyYW1ldGVycyhWUlAsIHJvdXRlIGRpc3Rpbmd1aXNo ZXIsIHJvdXRlciB0YXJnZXQpLA0KQkdQIHNwZWNpZmljIGRldGFpbGVkIHBhcmFtZXRlcnMgc3Vj aCBhcyBuZXh0IGhvcCBvcHRpb25zLiBUaGVzZSBwYXJhbWV0ZXJzIGFyZSBwYXJ0IG9mIHNlcnZp Y2UgZGVsaXZlcnkgbW9kZWwsIGJ1dCBub3QgcGFydCBvZiBMMlNNIG1vZGVsIG9yIEwzU00gbW9k ZWwuIEwyU00gd291bGQgbm90IGNvdmVyIHRvbyBtdWNoIGRldGFpbHMgb24gdGhlc2UgQkdQIHNw ZWNpZmljIHBhcmFtZXRlcnMsIGl0IGp1c3Qgc2F5IGJncCwgb3NwZiwgc3RhdGljLCByaXAsIGV0 YyBjYW4gYmUgc3VwcG9ydGVkIHNpbmNlIEwyU00gaXMgbm90IGluc3RhbnRpYXRlZCBtb2RlbCwg c2luY2UgeW91IGRvbuKAmXQga25vdyB3aGljaCBQRSB5b3Ugd2lsbCBzZWxlY3QsIHdoaWNoIGlu dGVyZmFjZSBvbiB0aGUgZGV2aWNlIHlvdSB3aWxsIGFsbG9jYXRlIGJlZm9yZSB0aGV5IGNhbiBi ZSBtYXBwZWQgaW50byBjb25maWcgcGFyYW1ldGVycyB0aGVyZWZvcmUgd2UgaW50cm9kdWNlIGxv Y2F0aW9uIGFuZCBkZXZpY2UgY29uc3RyYWludCBpbiB0aGUgbW9kZWwgdG8gaGVscCB0aGUgbWFu YWdlbWVudCBzeXN0ZW0gdG8gZGVjaWRlIFBFIHNlbGVjdGlvbiwgaW50ZXJmYWNlIHNlbGVjdGlv biBpbiB0aGUgbG93ZXIgbGF5ZXIgcmF0aGVyIHRoYW4gc2VydmljZSBsYXllci4NCg0KSSBhbSBu b3Qgc3VyZSB3ZSByZWFsbHkgY292ZXIgUEUtUEUgZGV0YWlscyBpbiBMMlNNIG1vZGVsLCB3ZSBk aWQgZGVzY3JpYmUgb25lIFZQTiBjYW4gYmUgZXh0ZW5kZWQgYWNyb3NzIG11bHRpcGxlIGF1dG9u b21vdXMgc3lzdGVtcywgYnV0IGRvbuKAmXQgZ28gaW50byBkZXRhaWxzIHRvIGRpc2N1c3MNClZS RiBzcGVjaWZpYyBkZXRhaWxlZCBwYXJhbWV0ZXJzIGFuZCBCR1Agc3BlY2lmaWMgZGV0YWlsZWQg cGFyYW1ldGVycywgc2luY2UgdGhlc2UgYXJlIHNvbWV0aGluZyBiZWxvbmdpbmcgdG8gc2Vydmlj ZSBkZWxpdmVyeSBtb2RlbC4geW91IHdpbGwgc2VlIEwzU00gYWxzbyBtb2RlbCBpdCBhcyBvbmUg c3BlY2lhbCBzaXRlLg0KDQpJbiBhIHdvcmQsIEwyU00gbW9kZWwgd2lsbCBvbmx5IGRlc2NyaWJl IGhvdyBtYW55IHNpdGVzIHlvdSBoYXZlLCBob3cgb25lIHNpdGUgY29ubmVjdHMgdG8gdGhlIG90 aGVyIHNpdGUsIGhvdyBvbmUgc2l0ZSBjb25uZWN0cyB0byBpbnRlcm5ldCwgRGF0YUNlbnRlciwg cHVibGljIGNsb3VkLCBob3cgdG8gZGVzY3JpYmUNCkNvbm5lY3Rpdml0eSBiZXR3ZWVuIHRoZXNl IHNpdGVzIG9yIGJldHdlZW4gc2l0ZSBhbmQgZGF0YWNlbnRlci4gV2hhdCBraW5kIG9mIHRlY2hu b2xvZ2llcyBwZXJ0YWluaW5nIHRvIHRoZXNlIGNvbm5lY3Rpdml0eSBzZXJ2aWNlIGNhbiBiZSBz dXBwb3J0ZWQuDQoNCg0KDQo= --_000_B8F9A780D330094D99AF023C5877DABA9A751B3Enkgeml513mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jmd0OyZuYnNwOyZuYnNwOyAqIEkgY2FuJ3Qgc3BlYWsgZm9yIGFueW9u ZSBlbHNlLCBidXQgbXkgY3JpdGljaXNtIHJlZ2FyZGluZyB0aGU8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGluY2x1c2lvbiBvZiAmcXVvdDt0ZWNobm9sb2d5LXNwZWNpZmljIHBh cmFtZXRlcnMmcXVvdDssIGFzIHlvdSBwdXQgaXQsIGlzIG5vdDxicj4NCiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaW4gcmVzcGVjdCBvZiB0aGUgUEUtQ0UgbGlua3MuJm5ic3A7IEkgYWdy ZWUgdGhlIHRlY2hub2xvZ3kgZGV0YWlscyBhcmU8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG5lZWRlZCB0aGVyZS4mbmJzcDsgSG93ZXZlciwgdGhlIGRyYWZ0IGFsc28gaW5jbHVk ZXMgYSBsb3Qgb2YgZGV0YWlsczxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWJv dXQgdGhlIHRlY2hub2xvZ3kgdXNlZCB3aXRoaW4gdGhlIFNQJ3MgbmV0d29yayAoaS5lLiwgUEUt UEUpIC08YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgaXMgdGhlIGRldGFp bCB3aGljaCBJIHRoaW5rIGlzIG5vdCByZWxldmFudCBhbmQgZG9lcyBub3QgYmVsb25nPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiBhIHNlcnZpY2UgbW9kZWwuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRvIGFncmVlIHRoYXQg c29tZSBvZiB0aG9zZSBwYXJhbWV0ZXJzIHNob3VsZCBiZSByZW1vdmVkLiBUaGF0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPnNob3VsZG4ndCBiZSBjb25zaWRlcmVkIGFzIGEgcmVhc29uIGZvciB0aGUg V0cgdG8gbm90IGFkb3B0IHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ZHJhZnQuIEluZGVlZCwg aXQgKipzaG91bGQqKiBiZSBlYXNpZXIgdG8gZ2FpbiBjb25zZW5zdXMgb24gd2hhdCBzaG91bGQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+YW5kIHNob3VsZCBub3QgYmUgaW5jbHVkZWQgYnkgd29ya2lu ZyBvbiBpdCBhcyBhIFdHLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+UmVnYXJkaW5nIHRoZSBQRS1QRSB0ZWNobm9sb2d5LCBJIHZpZXdlZCB0aGF0IGFz IGJlaW5nIHBhcnQgb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlcnZpY2UgRGVsaXZlcnkg TW9kZWwgaW4gdGhlIG9wc2F3ZyBkcmFmdC4gUWluLCBwbGVhc2UgY29ycmVjdCBtZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5pZiBJIGFtIHdyb25nIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPltRaW5dOiBUaGFua3MgSm9obiBmb3IgY2xhcmlmaWNhdGlvbiBhbmQgY29t bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZXJ2aWNl IERlbGl2ZXJ5IE1vZGVsIGlzIHJlYWxseSBhYm91dCBob3cgdGhlIHNlcnZpY2UgaXMgZGVsaXZl cmVkIGFuZCByZWFsaXplZCB3aGlsZSBMMlNNIG1vZGVsIGlzIGFib3V0IHdoYXQgdGhlIHNlcnZp Y2UgaXMsIHdoYXQga2luZCBvZiB0ZWNobm9sb2dpZXMNCiBhdmFpbGFibGUgeW91IGNhbiBzdXBw b3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VydmljZSBE ZWxpdmVyeSBNb2RlbCBpcyBhIG1vZGVsIHRoYXQgaGFzIGFscmVhZHkgYmVlbiBpbnN0YW50aWF0 ZWQsIGUuZy4sIFZSRiBzcGVjaWZpYyBkZXRhaWxlZCBwYXJhbWV0ZXJzKFZSUCwgcm91dGUgZGlz dGluZ3Vpc2hlciwgcm91dGVyIHRhcmdldCksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5CR1Agc3BlY2lmaWMgZGV0YWlsZWQgcGFyYW1ldGVycyBzdWNoIGFzIG5l eHQgaG9wIG9wdGlvbnMuIFRoZXNlIHBhcmFtZXRlcnMgYXJlIHBhcnQgb2Ygc2VydmljZSBkZWxp dmVyeSBtb2RlbCwgYnV0IG5vdCBwYXJ0IG9mIEwyU00gbW9kZWwgb3IgTDNTTQ0KIG1vZGVsLiBM MlNNIHdvdWxkIG5vdCBjb3ZlciB0b28gbXVjaCBkZXRhaWxzIG9uIHRoZXNlIEJHUCBzcGVjaWZp YyBwYXJhbWV0ZXJzLCBpdCBqdXN0IHNheSBiZ3AsIG9zcGYsIHN0YXRpYywgcmlwLCBldGMgY2Fu IGJlIHN1cHBvcnRlZCBzaW5jZSBMMlNNIGlzIG5vdCBpbnN0YW50aWF0ZWQgbW9kZWwsIHNpbmNl IHlvdSBkb27igJl0IGtub3cgd2hpY2ggUEUgeW91IHdpbGwgc2VsZWN0LCB3aGljaCBpbnRlcmZh Y2Ugb24gdGhlIGRldmljZSB5b3Ugd2lsbA0KIGFsbG9jYXRlIGJlZm9yZSB0aGV5IGNhbiBiZSBt YXBwZWQgaW50byBjb25maWcgcGFyYW1ldGVycyB0aGVyZWZvcmUgd2UgaW50cm9kdWNlIGxvY2F0 aW9uIGFuZCBkZXZpY2UgY29uc3RyYWludCBpbiB0aGUgbW9kZWwgdG8gaGVscCB0aGUgbWFuYWdl bWVudCBzeXN0ZW0gdG8gZGVjaWRlIFBFIHNlbGVjdGlvbiwgaW50ZXJmYWNlIHNlbGVjdGlvbiBp biB0aGUgbG93ZXIgbGF5ZXIgcmF0aGVyIHRoYW4gc2VydmljZSBsYXllci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBub3Qgc3VyZSB3ZSByZWFsbHkgY292ZXIgUEUt UEUgZGV0YWlscyBpbiBMMlNNIG1vZGVsLCB3ZSBkaWQgZGVzY3JpYmUgb25lIFZQTiBjYW4gYmUg ZXh0ZW5kZWQgYWNyb3NzIG11bHRpcGxlIGF1dG9ub21vdXMgc3lzdGVtcywgYnV0IGRvbuKAmXQN CiBnbyBpbnRvIGRldGFpbHMgdG8gZGlzY3VzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VlJGIHNwZWNpZmljIGRldGFpbGVkIHBhcmFtZXRlcnMgYW5kIEJHUCBz cGVjaWZpYyBkZXRhaWxlZCBwYXJhbWV0ZXJzLCBzaW5jZSB0aGVzZSBhcmUgc29tZXRoaW5nIGJl bG9uZ2luZyB0byBzZXJ2aWNlIGRlbGl2ZXJ5IG1vZGVsLiB5b3Ugd2lsbA0KIHNlZSBMM1NNIGFs c28gbW9kZWwgaXQgYXMgb25lIHNwZWNpYWwgc2l0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SW4gYSB3b3JkLCBMMlNNIG1vZGVsIHdpbGwgb25seSBkZXNjcmliZSBob3cg bWFueSBzaXRlcyB5b3UgaGF2ZSwgaG93IG9uZSBzaXRlIGNvbm5lY3RzIHRvIHRoZSBvdGhlciBz aXRlLCBob3cgb25lIHNpdGUgY29ubmVjdHMgdG8gaW50ZXJuZXQsIERhdGFDZW50ZXIsDQogcHVi bGljIGNsb3VkLCBob3cgdG8gZGVzY3JpYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkNvbm5lY3Rpdml0eSBiZXR3ZWVuIHRoZXNlIHNpdGVzIG9yIGJldHdlZW4g c2l0ZSBhbmQgZGF0YWNlbnRlci4gV2hhdCBraW5kIG9mIHRlY2hub2xvZ2llcyBwZXJ0YWluaW5n IHRvIHRoZXNlIGNvbm5lY3Rpdml0eSBzZXJ2aWNlIGNhbiBiZSBzdXBwb3J0ZWQuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0K PGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA9A751B3Enkgeml513mbschi_-- From nobody Wed Jan 11 23:06:53 2017 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 9E45712948D for ; Wed, 11 Jan 2017 23:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.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] 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 Vaw8jTeg3kbw for ; Wed, 11 Jan 2017 23:06:48 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 44E801293E4 for ; Wed, 11 Jan 2017 23:06:48 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id k86so6950489lfi.0 for ; Wed, 11 Jan 2017 23:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Hutvour/r71XfKl5xT986yz784OwihBc5wV4OX4z5Bo=; b=CtJoI6kMufMQc949sLnNIW5fqbEgykUj/hquedEJIXpj5ONPT6eY/ZDuU2UzvqOpCs qQZsCfXt8Ef4LNTqZNmIJo33HpTuFBwiYmOEpnnaZX8x8wK0n85x4InVZz5458LbhTnm sRU5YcFWUrNIB08uJD1behLItG0rVOPRe7cfT96/xn5OABPbIX20o7WK93WP5UMs4NqP 7rfMMvHrPGVBM6/iyHMKLe7QpZWYUHCpGoOZj9cwxVgm+AbAOQ5Ms9I+ps4Iu1GWOppy Ck47HmQE4V8vXkdz9aSO6+XOuosEucnpR+lK3ISwFEtrdVbUcjTZXT4r2f/wgdb/q0la Gqpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hutvour/r71XfKl5xT986yz784OwihBc5wV4OX4z5Bo=; b=ngRKF9lNexupiIOrSm66FoTrzTHtSghp7cjoFwrpy1rZU/2/goNFODeM/N6Oe8wiLm MY0eJEm9KqJYdX+UhRv5u62a4sU9bCR7dFcfZpRXAU7SsY8sGi7erof5Vg3xZ4Uu0iD8 2z0ihU6QGl8fYqVjmMHq9PxHz8T5RVmgp6lcmeJ5CgYU5SGFEH6KMhvQmjYMCekBzj2D L1VJpQAHLe4H+tmCYXSqBXTe3eMXmPpE2+SfecyAJZFRDU2lbKWx73PWZp0D4WDscD+w /WqHHbIVwFSMdvUn7DoEbWlG7zxTBzuZBLJTDOLLkkEo+v98WMiJE92Y2qJKpizfOABr F4/w== X-Gm-Message-State: AIkVDXL0lQoPmC+4/I9WMWxQH5Aw9X1gY7Urw+6YJs2y4mjxZNFsx2VZfjR7d/RfsK/6k14LqmiMHCmkInHV0Q== X-Received: by 10.25.132.6 with SMTP id g6mr5137127lfd.144.1484204806035; Wed, 11 Jan 2017 23:06:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.21.203 with HTTP; Wed, 11 Jan 2017 23:06:45 -0800 (PST) From: John Strassner Date: Wed, 11 Jan 2017 23:06:45 -0800 Message-ID: To: l2sm@ietf.org, John Strassner Content-Type: multipart/alternative; boundary=001a113eaa723ce06c0545e05cd9 Archived-At: Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 07:06:51 -0000 --001a113eaa723ce06c0545e05cd9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, I meant to address this to David, not Scott. Curse you, demon of jet lag! :-) regards, John John Strassner Wed, 11 January 2017 20:51 UTC 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 E55A512945C for ; Wed, 11 Jan 2017 12:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=3D-2.699 tagged_above=3D-999 required=3D5 tests=3D[BAYES_00=3D-1.9, DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1, DKIM_VALID_= AU=3D-0.1, FREEMAIL_FROM=3D0.001, HTML_MESSAGE=3D0.001, RCVD_IN_DNSWL_LOW=3D-0.7, SPF_PASS=3D-0.001] autolearn=3Dham autolearn_force=3Dno Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=3Dpass (2048-bit key) header.d=3Dgmail.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 B1SYljTb3u1D for < l2sm@ietfa.amsl.com>; Wed, 11 Jan 2017 12:51:56 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 211BC129873 for < l2sm@ietf.org>; Wed, 11 Jan 2017 12:51:55 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id v186so90815496lfa.1 for = < l2sm@ietf.org>; Wed, 11 Jan 2017 12:51:55 -0800 (PST) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dgmail.com; s=3D20161025; h=3Dmime-version:from:date:message-id:subject:to; bh=3DLOrTsvHPRRD4hlVOF0m2zhaUgtNPTUJW3pc5mhIH18c=3D; b=3DJaVkQEUleXF/GNI2esHP+Jvr3r7Rpvel+G/nE3kn3ISDf+Auka6ciFvErP78stwk2K 8kCceQhuEkUhMLyy4K2T4W5tdLCDDswWrWlNabBDISfzzJ00mQnSWnsXH//jK3ARQ9gq zEw2BThnJl8sxMAzRWiq1WNkv4pOClYlyqO5bL1/doaNbTeD8H4kL/lGBPLkUeEPhgDD sqIJZ34TgT27laTEx755ifAfOQWQ5l95LyllaIGQmcC/8L3yzTML/L5hDJk+KfibcGga oboB98tckjO2h/5UiB+zknlJEjU//gr7VbmQ9EqOQYptIAY14wFE8hYQ9pLfiq31yakK RtCA= =3D=3D X-Google-DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3D1e= 100.net; s=3D20161025; h=3Dx-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3DLOrTsvHPRRD4hlVOF0m2zhaUgtNPTUJW3pc5mhIH18c=3D; b=3DS7dh1X+9e/TbaDjdm2lcF8Jn0W1X/l5BtaLL9f3gn/wiZgnwDRqelGBB1DdzCCbRhi ermLnGzNO4UeyGOPlJoxEszpqHMIsGdOUpbeYraNhHwhafGhQUnThPzq6W3hjkrOM6kx jleI4ZyIPzvavm8hPKYc4PACt1XJlJwQx8rjyFu3a3wcfJD2NLbeUKnsRHg/88toKRHa faqOBlt5FeFwX+Gr2WDAS2f2Rt1Nh8KMidFEKgU3um/zU93wgQfpRTbhBIMgmd83hNTv rQa6B6gcZtkSora3YSIUHIPFJp30vCQElTqO5SwSqIhQGvfTujvzAL7NRIaddF2Fi+vQ LmRQ= =3D=3D X-Gm-Message-State: AIkVDXL/J9XxgbAoPB0BNdFwZoTYIpda5b8DILmNJ8ofskCtJXxOPiHtwuhYDKmiTxAuv+5cK3K= Kyn/q0UDlVA=3D=3D X-Received: by 10.25.132.6 with SMTP id g6mr4392261lfd.144.1484167913690; Wed, 11 Jan 2017 12:51:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.21.203 with HTTP; Wed, 11 Jan 2017 12:51:53 -0800 (PST) From: John Strassner Date: Wed, 11 Jan 2017 12:51:53 -0800 Message-ID: To: l2sm@ietf.org Content-Type: multipart/alternative; boundary=3D001a113eaa72485a850545d7c51= 7 Archived-At: < https://mailarchive.ietf.org/arch/msg/l2sm/h917C8DkptG-IA2LC6vy7Op0D5M> Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" < l2sm.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:51:59 -0000 Hi all, first, I would like to express support for the WG adopting this draft. Sorr= y that I'm not an operator :-) but I am actively involved in the MEF and other relevant IETF WGs. Second, some comments to Scott: > Hi Scott, > > I agree; but what is being proposed is not iteration, reuse and > extension, which you rightly extol. I disagree - the iteration is the continuous revision of the draft. The charter says that the WG "...will also coordinate with other organizations working on related L2VPN data models (such as the MEF)", which is good enough for me. > It is instead ignoring all the work > that has gone before (not just the MEF yang models, but the 10+ years of > work MEF has done in defining Carrier Ethernet services). I think that the L2SM charter is different than the Carrier Ethernet work done in the MEF. Where do you think they overlap, and why? > > Benoit, to answer your points: > > * You are correct that MEF has a grand vision for the LSO > architecture; time will tell whether that is achievable. However, > the one small part of it that they are furthest progressed with is > exactly the same area that is covered by L2SM. I don't understand > why you think L2SM is following a different architecture; in both > cases what we are talking about is a model for the set of things > that need to be agreed between the SP and the customer, right? I disagree. The charter says: ... 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. First, the MEF didn't start with the goal of creating a YANG data model; this by itself differentiates the resulting architectures and approaches. The fact that 10 years later the MEF added a YANG model doesn't make them equal. Indeed, the MEF (should) be defining its YANG model directly from its Core Info Model and relevant other models; in contrast, the IETF currently has no such info model from which to derive the L2SM YANG data model. Second, in reading Qin's opsawg draft, there is some similarity in how a "service model" is defined (e.g., emphasizing connectivity offered). However, I still view this as different from the current work done in the MEF. For example, I would hope that in the MEF, we would consider defining service models that are amenable to orchestration; that is clearly outside the scope of L2SM (at least now). > * I can't speak for anyone else, but my criticism regarding the > inclusion of "technology-specific parameters", as you put it, is not > in respect of the PE-CE links. I agree the technology details are > needed there. However, the draft also includes a lot of details > about the technology used within the SP's network (i.e., PE-PE) - > that is the detail which I think is not relevant and does not belong > in a service model. I do agree that some of those parameters should be removed. That shouldn't be considered as a reason for the WG to not adopt this draft. Indeed, it **should** be easier to gain consensus on what should and should not be included by working on it as a WG. Regarding the PE-PE technology, I viewed that as being part of the Service Delivery Model in the opsawg draft. Qin, please correct me if I am wrong here. > * I do not understand what you mean when you say the MEF has worked on > CE-based models. A service model is not used between the CE and PE, > it is used between the customer's management systems (as the client) > and the SP's management systems (as the server). There are > differences in terminology for those systems, but fundamentally I > don't see any difference between MEF and IETF approach here. Can > you clarify what you meant? I agree with David that the MEF model is **not** a CE-based model. I'm also not sure what is meant by that. As stated earlier, I disagree with David that the MEF and IETF approaches are the same - please see my above comments. > > Benoit, you mentioned that, as vendors, we should listen more to > operators. I agree. I would love to hear from the operators who > support adoption of this draft what issues they see with the MEF models, > and why they believe that starting again from scratch in IETF is a > better option than working with MEF to improve on what they have already > done, and then augmenting ("extending") it to fill in any gaps. The MEF > models are certainly far from perfect (and of course they are still WIP > in MEF), but what I would like to understand is why you, as operators, > think they are not a good starting point for solving the problems that > led to the creation of this WG. I would love to hear that as well, but this shouldn't be an impediment for the WG to adopt this draft. > > David >> >>On 03/01/2017 19:19, Scott Mansfield wrote: >> >> I agree with Benoit. There are many dimensions to the modeling space >> and we can=E2=80=99t let the perfect be the enemy of the good. Constant >> communication and sharing will help alignment while allowing the >> people that actually run networks to get what they need. 30+ years of >> object-oriented software development (should have) taught all >> designers/architects/programmers that the first iteration of a >> solution is not the best and most optimized. Each iteration provides >> the opportunity to abstract, refine, refactor, and extend. Proper >> information hiding and encapsulation is key. Automation is very >> important and we need to work together to ensure that whatever models >> that are created are supported by tools that allow for effective reuse >> and extensions. ... elided rest of message thread regards, John --=20 regards, John --001a113eaa723ce06c0545e05cd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, I meant to address this to David, not Scott. Curse = you, demon of jet lag! :-)

regards,
John

John Strassner <strazpdj@gmail.co= m> Wed= , 11 January 2017 20:51 UTC=C2=A0=C2=A0

Re= turn-Path: <strazpdj@gmail.com= >
X-Original-To: l2sm@ietfa.amsl.com
Delivered-To: l2sm@ietfa.amsl.com
Received: from= localhost (localhost [127.0.0.1]) by iet= fa.amsl.com (Postfix) with ESMTP id E55A512945C for <l2sm@ietfa.amsl.com>; Wed, 11 Jan 2017 12:51= :58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
= X-Spam-Score: -2.699
X-Spam-Level:
= X-Spam-Status: No, score=3D-2.699 tagged_above=3D-999 required=3D5 tests= =3D[BAYES_00=3D-1.9, DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1, DKIM_VALID_AU=3D= -0.1, FREEMAIL_FROM=3D0.001, HTML_MESSAGE=3D0.001, RCVD_IN_DNSWL_LOW=3D-0.7= , SPF_PASS=3D-0.001] autolearn=3Dham autolearn_force=3Dno
= Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=3Dpass (2048-bit key) header.d=3Dgmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 1002= 4) with ESMTP id B1SYljTb3u1D for <l2sm@ietfa.amsl.com>; Wed, 11 Jan 2017 12:51:56 -0800 (PST)
= Received: from mail-= lf0-x22a.google.com (mail-l= f0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with = cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate r= equested) by ietfa.amsl.com (Postfix)= with ESMTPS id 211BC129873 for <l2sm@i= etf.org>; Wed, 11 Jan 2017 12:51:55 -0800 (PST)
Rec= eived: by mail-lf0-x22a.google.= com with SMTP id v186so90815496lfa.1 for <l2sm@ietf.org>; Wed, 11 Jan 2017 12:51:55 -0800 (PST)
= DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3D<= a href=3D"http://gmail.com">gmail.com; s=3D20161025; h=3Dmime-version:= from:date:message-id:subject:to; bh=3DLOrTsvHPRRD4hlVOF0m2zhaUgtNPTUJW3pc5m= hIH18c=3D; b=3DJaVkQEUleXF/GNI2esHP+Jvr3r7Rpvel+G/nE3kn3ISDf+Auka6ciFvErP78= stwk2K 8kCceQhuEkUhMLyy4K2T4W5tdLCDDswWrWlNabBDISfzzJ00mQnSWnsXH//jK3ARQ9gq= zEw2BThnJl8sxMAzRWiq1WNkv4pOClYlyqO5bL1/doaNbTeD8H4kL/lGBPLkUeEPhgDD sqIJZ= 34TgT27laTEx755ifAfOQWQ5l95LyllaIGQmcC/8L3yzTML/L5hDJk+KfibcGga oboB98tckjO= 2h/5UiB+zknlJEjU//gr7VbmQ9EqOQYptIAY14wFE8hYQ9pLfiq31yakK RtCA=3D=3D
= X-Google-DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/rela= xed; d=3D1e100.net; s=3D20161025; h=3Dx-gm= -message-state:mime-version:from:date:message-id:subject:to; bh=3DLOrTsvHPR= RD4hlVOF0m2zhaUgtNPTUJW3pc5mhIH18c=3D; b=3DS7dh1X+9e/TbaDjdm2lcF8Jn0W1X/l5B= taLL9f3gn/wiZgnwDRqelGBB1DdzCCbRhi ermLnGzNO4UeyGOPlJoxEszpqHMIsGdOUpbeYraN= hHwhafGhQUnThPzq6W3hjkrOM6kx jleI4ZyIPzvavm8hPKYc4PACt1XJlJwQx8rjyFu3a3wcfJ= D2NLbeUKnsRHg/88toKRHa faqOBlt5FeFwX+Gr2WDAS2f2Rt1Nh8KMidFEKgU3um/zU93wgQfp= RTbhBIMgmd83hNTv rQa6B6gcZtkSora3YSIUHIPFJp30vCQElTqO5SwSqIhQGvfTujvzAL7NRI= addF2Fi+vQ LmRQ=3D=3D
X-Gm-Message-State: AIkVDXL/J9XxgbAo= PB0BNdFwZoTYIpda5b8DILmNJ8ofskCtJXxOPiHtwuhYDKmiTxAuv+5cK3KKyn/q0UDlVA=3D= =3D
X-Received: by 10.25.132.6 with SMTP id g6mr4392261lfd= .144.1484167913690; Wed, 11 Jan 2017 12:51:53 -0800 (PST)
= MIME-Version: 1.0
Received: by 10.25.21.203 with HTTP; Wed= , 11 Jan 2017 12:51:53 -0800 (PST)
From: John Strassner &l= t;strazpdj@gmail.com>
= Date: Wed, 11 Jan 2017 12:51:53 -0800
Message-ID:= <CAJwYUrH6jRoHv3m8b8RXw4_Lir41nGv=3DJDVvTE6S6brJiOBkUQ@mail.gmail.com>
= To: l2sm@ietf.org
C= ontent-Type: multipart/alternative; boundary=3D001a113eaa72485a850545d7c517=
Archived-At: <https://mailarchive.ietf.org/arc= h/msg/l2sm/h917C8DkptG-IA2LC6vy7Op0D5M>
Subject: Re= : [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt
= X-BeenThere: l2sm@ietf.org<= br> X-Mailman-Version: 2.1.17
Precedence: lis= t
List-Id: "The Layer Two Virtual Private Network Ser= vice Model \(L2SM\)" <l2sm.ietf.or= g>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2sm&g= t;, <mailto:l2sm-request@ietf.o= rg?subject=3Dunsubscribe>
List-Archive: <https://mailarchive.iet= f.org/arch/browse/l2sm/>
List-Post: <mailto:l2sm@ietf.org>
List-He= lp: <mailto:l2sm-request@ietf.o= rg?subject=3Dhelp>
List-Subscribe: <https://www.ietf.org/mailman/lis= tinfo/l2sm>, <mailto:l2s= m-request@ietf.org?subject=3Dsubscribe>
X-List-Rece= ived-Date: Wed, 11 Jan 2017 20:51:59 -0000

Hi all,

first, I would like to express support for the WG adopting this draft. Sorr=
y
that I'm not an operator :-) but I am actively involved in the MEF and
other relevant IETF WGs.

Second, some comments to Scott:

> Hi Scott,
>
> I agree; but what is being proposed is not iteration, reuse and
> extension, which you rightly extol.

I disagree - the iteration is the continuous revision of the draft. The
charter
says that the WG "...will also coordinate with other organizations wor=
king
on related L2VPN data models (such as the MEF)", which is good enough
for me.

> It is instead ignoring all the work
> that has gone before (not just the MEF yang models, but the 10+ years =
of
> work MEF has done in defining Carrier Ethernet services).

I think that the L2SM charter is different than the Carrier Ethernet work
done
in the MEF. Where do you think they overlap, and why?

>
> Benoit, to answer your points:
>
>   * You are correct that MEF has a grand vision for the LSO
>     architecture; time will tell whether that is achievable. However,
>     the one small part of it that they are furthest progressed with is
>     exactly the same area that is covered by L2SM.  I don't unders=
tand
>     why you think L2SM is following a different architecture; in both
>     cases what we are talking about is a model for the set of things
>     that need to be agreed between the SP and the customer, right?

I disagree. The charter says:

    ... 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.

First, the MEF didn't start with the goal of creating a YANG data model=
;
this by itself differentiates the resulting architectures and approaches.
The fact that 10 years later the MEF added a YANG model doesn't
make them equal. Indeed, the MEF (should) be defining its YANG
model directly from its Core Info Model and relevant other models; in
contrast, the IETF currently has no such info model from which to
derive the L2SM YANG data model.

Second, in reading Qin's opsawg draft, there is some similarity in how
a "service model" is defined (e.g., emphasizing connectivity offe=
red).
However, I still view this as different from the current work done in
the MEF. For example, I would hope that in the MEF, we would
consider defining service models that are amenable to orchestration;
that is clearly outside the scope of L2SM (at least now).

>   * I can't speak for anyone else, but my criticism regarding the
>     inclusion of "technology-specific parameters", as you pu=
t it, is not
>     in respect of the PE-CE links.  I agree the technology details are
>     needed there.  However, the draft also includes a lot of details
>     about the technology used within the SP's network (i.e., PE-PE=
) -
>     that is the detail which I think is not relevant and does not belo=
ng
>     in a service model.

I do agree that some of those parameters should be removed. That
shouldn't be considered as a reason for the WG to not adopt this
draft. Indeed, it **should** be easier to gain consensus on what should
and should not be included by working on it as a WG.

Regarding the PE-PE technology, I viewed that as being part of the
Service Delivery Model in the opsawg draft. Qin, please correct me
if I am wrong here.

>   * I do not understand what you mean when you say the MEF has worked =
on
>     CE-based models.  A service model is not used between the CE and P=
E,
>     it is used between the customer's management systems (as the c=
lient)
>     and the SP's management systems (as the server).  There are
>     differences in terminology for those systems, but fundamentally I
>     don't see any difference between MEF and IETF approach here.  =
Can
>     you clarify what you meant?

I agree with David that the MEF model is **not** a CE-based model. I'm
also not sure what is meant by that.

As stated earlier, I disagree with David that the MEF and IETF approaches
are the same - please see my above comments.

>
> Benoit, you mentioned that, as vendors, we should listen more to
> operators.  I agree.  I would love to hear from the operators who
> support adoption of this draft what issues they see with the MEF model=
s,
> and why they believe that starting again from scratch in IETF is a
> better option than working with MEF to improve on what they have alrea=
dy
> done, and then augmenting ("extending") it to fill in any ga=
ps.  The MEF
> models are certainly far from perfect (and of course they are still WI=
P
> in MEF), but what I would like to understand is why you, as operators,
> think they are not a good starting point for solving the problems that
> led to the creation of this WG.

I would love to hear that as well, but this shouldn't be an impediment =
for
the WG to adopt this draft.

>
>    David
>>
>>On 03/01/2017 19:19, Scott Mansfield wrote:
>>
>> I agree with Benoit.  There are many dimensions to the modeling sp=
ace
>> and we can=E2=80=99t let the perfect be the enemy of the good.  Co=
nstant
>> communication and sharing will help alignment while allowing the
>> people that actually run networks to get what they need.  30+ year=
s of
>> object-oriented software development (should have) taught all
>> designers/architects/programmers that the first iteration of a
>> solution is not the best and most optimized. Each iteration provid=
es
>> the opportunity to abstract, refine, refactor, and extend.  Proper
>> information hiding and encapsulation is key.  Automation is very
>> important and we need to work together to ensure that whatever mod=
els
>> that are created are supported by tools that allow for effective r=
euse
>> and extensions.

...

elided rest of message thread


regards,
John


--
regards,
John
--001a113eaa723ce06c0545e05cd9-- From nobody Thu Jan 12 19:58:24 2017 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 3476A1299AB for ; Thu, 12 Jan 2017 19:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 ykCrUJAkKX3H for ; Thu, 12 Jan 2017 19:58:17 -0800 (PST) Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (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 CA0851299AD for ; Thu, 12 Jan 2017 19:58:09 -0800 (PST) X-AuditID: 60721c4c-61fff70000007eaf-cd-5878504ebf57 Received: from VAADCEX26.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by (SMTP Gateway) with SMTP id 2B.3C.32431.E4058785; Thu, 12 Jan 2017 22:58:08 -0500 (EST) Received: from VAADCEX31.cable.comcast.com (147.191.103.208) by VAADCEX26.cable.comcast.com (147.191.103.203) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 12 Jan 2017 22:58:04 -0500 Received: from VAADCEX31.cable.comcast.com ([fe80::3aea:a7ff:fe12:e278]) by VAADCEX31.cable.comcast.com ([fe80::3aea:a7ff:fe12:e278%19]) with mapi id 15.00.1130.005; Thu, 12 Jan 2017 22:58:04 -0500 From: "Wen, Bin" To: "adrian@olddog.co.uk" , "l2sm@ietf.org" Thread-Topic: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt Thread-Index: AdJBMl9LkbuTL93GR8uhCc0ETwHqcwsHt2uA Date: Fri, 13 Jan 2017 03:58:04 +0000 Message-ID: References: <0d4501d24132$62ceb590$286c20b0$@olddog.co.uk> In-Reply-To: <0d4501d24132$62ceb590$286c20b0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [68.87.29.8] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <76A0661695D7794F80361F76A269F176@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsWSUOxpoRsQUBFh8HKamcWPnhvMFndevmR0 YPJYsuQnk8eKzSsZA5iiuGxSUnMyy1KL9O0SuDImf1vPWrCWp6J561TWBsYWri5GTg4JAROJ y1vXMHUxcnEICcxkkuhet4EJJCEkcIhR4sIaOYjESUaJI7OmM4Mk2ATUJJ7OmsoOYosIBEk8 ad0FZgsLBErcWDoPyOYAi9+4IwdhGkl8XsoDYrIIqErM64gAMXkFzCSO3TIEMYUErCS+H2MF GcEpYC1xpPc12DhGATGJ76fWgN3CLCAucevJfCaIgwUkluw5zwxhi0q8fPwPrFdUQE9i9pQG doi4jsTZ608YIWwDia1L97FA2HISPTtaGSFm6kncmDqFDcJ2kJi39SsLhK0tsWzha7D5vAKC EidnPoHqFZc4fGQH6wRGqVlITpqFZNQsJKNmIRk1C8moBYysqxjlyhITU5JzM/JLSwyM9JIT k3JS9ZLzc5MTi0tA9CZGUAQXyfjsYPw0zeMQowAHoxIPr6hdRYQQa2JZcWUuMGY4mJVEeOW8 gEK8KYmVValF+fFFpTmpxYcYpTlYlMR5t9/UjBASSE8sSc1OTS1ILYLJMnFwSjUwzq9ultA+ XHGnVf4fk23oqSNmmdXaRh+rWq+U+ijyXX1zxnniLu/DXwsO75i/d4le3uudLT8PhpoqXAhY NEtAsYX7t+y35p7jS9rYlmse+DB7+jPHh28ZcwviHx4TmDVnbr2bxfbKbN+3Lusz727lnvr7 taiS81HNnAvPPYJMRGW2WvmUeVduVGIpzkg01GIuKk4EABp/EJDcAgAA Archived-At: Subject: Re: [L2sm] Adoption poll for draft-wen-l2sm-l2vpn-service-model-03.txt X-BeenThere: l2sm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "The Layer Two Virtual Private Network Service Model \(L2SM\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 03:58:23 -0000 I support the adoption of this draft. From operator perspective, it=B9s important to decouple customer service model from the actual service delivery method.=20 The current draft needs to be updated. However, it=B9s a good On 11/17/16, 7:26 PM, "L2sm on behalf of Adrian Farrel" wrote: >Hi, > >Our charter mandates that we consider basing our work on >draft-wen-l2sm-l2vpn-service-model-03.txt > >As we discussed in the meeting, that draft is not perfect. But when I >asked the >room whether we thought that it would provide a good starting point that >we >could work with to polish and adapt to become the I-D that we ultimately >submit >for publication as an RFC, I believe I heard a good hum in favour and >silence in >opposition. > >So this email starts a formal poll for adoption. Please answer: > >Do you think that the WG should adopt >draft-wen-l2sm-l2vpn-service-model-03.txt? > >If "yes," it would help if you could indicate whether you have read the >draft >and how happy you are with it. >If "no", it is important that you provide reasons. > >This poll will last for two weeks, ending on Saturday 3rd December. > >Just to reassure everyone that adoption does not imply that anything is >set in >stone: we expect the WG to continue to develop the content and change >whatever >needs to be changed. > >Thanks, >Adrian and Qin > >_______________________________________________ >L2sm mailing list >L2sm@ietf.org >https://www.ietf.org/mailman/listinfo/l2sm >