From nobody Wed Jul 1 01:24:45 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBAD1A0084 for ; Wed, 1 Jul 2015 01:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 hsz7LfuDtvju for ; Wed, 1 Jul 2015 01:24:42 -0700 (PDT) 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 A94C21A0041 for ; Wed, 1 Jul 2015 01:24:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUO66631; Wed, 01 Jul 2015 08:24:40 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 1 Jul 2015 09:24:37 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.89]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Wed, 1 Jul 2015 16:24:33 +0800 From: Qin Wu To: "l3sm@ietf.org" Thread-Topic: Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model Thread-Index: AdCoOcNOC4WSimn7RASgarVbA3avjgLnWMCA Date: Wed, 1 Jul 2015 08:24:33 +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.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA847649D0nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "adrian@olddog.co.uk" Subject: Re: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 08:24:43 -0000 --_000_B8F9A780D330094D99AF023C5877DABA847649D0nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The L3SM WG adoption call for draft-ltsd-l3sm-l3vpn-service-model has ended= . The I-D is adopted as a WG document. Just to remind that this document serves as a basis for WG to continue to w= ork on. The authors should submit this as draft-ietf-l3sm-l3vpn-service-model-00. -Qin and Adrian --_000_B8F9A780D330094D99AF023C5877DABA847649D0nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

The L3SM WG adoption call fo= r draft-ltsd-l3sm-l3vpn-service-model has ended. The I-D is adopted as a WG= document.

Just to remind that this doc= ument serves as a basis for WG to continue to work on.

 

The authors should submit this = as draft-ietf-l3sm-l3vpn-service-model-00.

&n= bsp;

-Qin and Adrian

--_000_B8F9A780D330094D99AF023C5877DABA847649D0nkgeml501mbschi_-- From nobody Wed Jul 1 02:27:07 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3A71B2AA3 for ; Wed, 1 Jul 2015 02:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 qYinl7_UgCwW for ; Wed, 1 Jul 2015 02:27:05 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5E01B29E2 for ; Wed, 1 Jul 2015 02:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9220; q=dns/txt; s=iport; t=1435742824; x=1436952424; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=XmaWi7c/P3JXjMJcRnYujc3+3Q9HRVue4cvVCfv66mM=; b=LuNpNhL8oTVCC0fXz2gKFdoZ9LalkSA+qF/er9dQ/lqWHFvl7Z3hrFDm 7s7MS0wNvj9VwZYdCBfz7d/t2Vi9bXB/mEMcjb61gOCojX+etAYlngLNy cnn+Mhs4voQFKT6KQQoWelMalrqXnPs2k7p//32k7MiAAQ2jakUmFVCA8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BgAwDMsZNV/xbLJq1bgkWBIF+9LgmBZAEJhXgCgg4UAQEBAQEBAYEKhCMBAQQBAQEaEEEKARALDhMWDwkDAgECARUwBgEMBgIBAYgrDcprAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLSoUGB4QrAQSUEIthiDmQCyaDfDwxgkgBAQE X-IronPort-AV: E=Sophos;i="5.15,384,1432598400"; d="scan'208,217";a="569226511" 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; 01 Jul 2015 09:27:00 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t619QvSr032436; Wed, 1 Jul 2015 09:26:58 GMT To: Qin Wu , "l3sm@ietf.org" References: From: Benoit Claise Message-ID: <5593B260.8010203@cisco.com> Date: Wed, 1 Jul 2015 11:26:56 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050909000706020009080006" Archived-At: Cc: "adrian@olddog.co.uk" Subject: Re: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 09:27:07 -0000 This is a multi-part message in MIME format. --------------050909000706020009080006 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear draft-ltsd-l3sm-l3vpn-service-model authors, Note that - pyang produces: ietf-l3vpn-svc@2015-06-16.yang:1: warning: unexpected latest revision "2015-04-24" in ietf-l3vpn-svc@2015-06-16.yang, should be 2015-06-16 - "pyang --ietf" produces: WITH WARNINGS ietf-l3vpn-svc@2015-06-16.yang:1: warning: unexpected latest revision "2015-04-24" in ietf-l3vpn-svc@2015-06-16.yang, should be 2015-06-16 ietf-l3vpn-svc@2015-06-16.yang:804: warning: IETF rule (RFC formatting): line length 72 exceeds 70 characters ietf-l3vpn-svc@2015-06-16.yang:852: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters ietf-l3vpn-svc@2015-06-16.yang:879: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters ietf-l3vpn-svc@2015-06-16.yang:884: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters ietf-l3vpn-svc@2015-06-16.yang:901: warning: IETF rule (RFC formatting): line length 72 exceeds 70 characters ietf-l3vpn-svc@2015-06-16.yang:1024: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters ietf-l3vpn-svc@2015-06-16.yang:1258: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters ietf-l3vpn-svc@2015-06-16.yang:1271: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters ietf-l3vpn-svc@2015-06-16.yang:1404: warning: IETF rule (RFC formatting): line length 73 exceeds 70 characters ietf-l3vpn-svc@2015-06-16.yang:1410: warning: IETF rule (RFC formatting): line length 73 exceeds 70 characters Regards, Benoit > > Folks, > > The L3SM WG adoption call for draft-ltsd-l3sm-l3vpn-service-model has > ended. The I-D is adopted as a WG document. > > Just to remind that this document serves as a basis for WG to continue > to work on. > > The authors should submit this as draft-ietf-l3sm-l3vpn-service-model-00. > > -Qin and Adrian > > > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm --------------050909000706020009080006 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear draft-ltsd-l3sm-l3vpn-service-model authors,

Note that

- pyang produces:
ietf-l3vpn-svc@2015-06-16.yang:1: warning: unexpected latest revision "2015-04-24" in ietf-l3vpn-svc@2015-06-16.yang, should be 2015-06-16

- "pyang --ietf" produces:
WITH WARNINGS ietf-l3vpn-svc@2015-06-16.yang:1: warning: unexpected latest revision "2015-04-24" in ietf-l3vpn-svc@2015-06-16.yang, should be 2015-06-16
ietf-l3vpn-svc@2015-06-16.yang:804: warning: IETF rule (RFC formatting): line length 72 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:852: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:879: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:884: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:901: warning: IETF rule (RFC formatting): line length 72 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1024: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1258: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1271: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1404: warning: IETF rule (RFC formatting): line length 73 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1410: warning: IETF rule (RFC formatting): line length 73 exceeds 70 characters

Regards, Benoit

Folks,

 

The L3SM WG adoption call for draft-ltsd-l3sm-l3vpn-service-model has ended. The I-D is adopted as a WG document.

Just to remind that this document serves as a basis for WG to continue to work on.

 

The authors should submit this as draft-ietf-l3sm-l3vpn-service-model-00.

 

-Qin and Adrian



_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm

--------------050909000706020009080006-- From nobody Wed Jul 1 19:28:24 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383361A6EDB for ; Wed, 1 Jul 2015 19:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XFuSBFveI5Kh for ; Wed, 1 Jul 2015 19:28:20 -0700 (PDT) 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 8A7501B2D48 for ; Wed, 1 Jul 2015 19:27:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUP57247; Thu, 02 Jul 2015 02:27:45 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 2 Jul 2015 03:27:43 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.89]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Thu, 2 Jul 2015 10:27:40 +0800 From: Qin Wu To: Benoit Claise , "l3sm@ietf.org" Thread-Topic: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model Thread-Index: AdCoOcNOC4WSimn7RASgarVbA3avjgLnWMCA//+LvAD//l5aIA== Date: Thu, 2 Jul 2015 02:27:39 +0000 Message-ID: References: <5593B260.8010203@cisco.com> In-Reply-To: <5593B260.8010203@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA847650A9nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "adrian@olddog.co.uk" Subject: Re: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 02:28:22 -0000 --_000_B8F9A780D330094D99AF023C5877DABA847650A9nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIEJlbm9pdCBmb3Iga2luZGx5IHJlbWluZGluZy4gSXQgd291bGQgYmUgZ3JlYXQgdGhh dCB0aGUgcHlhbmcgdG9vbCBjYW4gYmUgYWxzbyBpbnRlZ3JhdGVkIGludG8gSUROaXRzIHRvb2wg dG8gY2hlY2sgWUFORyBkb2N1bWVudC4NCkF1dGhvcnMsIHBsZWFzZSBmaXggdGhlc2Ugbml0cyB3 aGVuIHN1Ym1pc3Npb24uDQoNCi1RaW4NCreivP7IyzogQmVub2l0IENsYWlzZSBbbWFpbHRvOmJj bGFpc2VAY2lzY28uY29tXQ0Kt6LLzcqxvOQ6IDIwMTXE6jfUwjHI1SAxNzoyNw0KytW8/sjLOiBR aW4gV3U7IGwzc21AaWV0Zi5vcmcNCrOty806IGFkcmlhbkBvbGRkb2cuY28udWsNCtb3zOI6IFJl OiBbTDNzbV0gUG9sbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtbHRzZC1sM3NtLWwzdnBuLXNlcnZp Y2UtbW9kZWwNCg0KRGVhciBkcmFmdC1sdHNkLWwzc20tbDN2cG4tc2VydmljZS1tb2RlbCBhdXRo b3JzLA0KDQpOb3RlIHRoYXQNCg0KLSBweWFuZyBwcm9kdWNlczoNCmlldGYtbDN2cG4tc3ZjQDIw MTUtMDYtMTYueWFuZzoxPG1haWx0bzppZXRmLWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6MT46 IHdhcm5pbmc6IHVuZXhwZWN0ZWQgbGF0ZXN0IHJldmlzaW9uICIyMDE1LTA0LTI0IiBpbiBpZXRm LWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc8bWFpbHRvOmlldGYtbDN2cG4tc3ZjQDIwMTUtMDYt MTYueWFuZz4sIHNob3VsZCBiZSAyMDE1LTA2LTE2DQoNCi0gInB5YW5nIC0taWV0ZiIgcHJvZHVj ZXM6DQpXSVRIIFdBUk5JTkdTIGlldGYtbDN2cG4tc3ZjQDIwMTUtMDYtMTYueWFuZzoxPG1haWx0 bzppZXRmLWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6MT46IHdhcm5pbmc6IHVuZXhwZWN0ZWQg bGF0ZXN0IHJldmlzaW9uICIyMDE1LTA0LTI0IiBpbiBpZXRmLWwzdnBuLXN2Y0AyMDE1LTA2LTE2 Lnlhbmc8bWFpbHRvOmlldGYtbDN2cG4tc3ZjQDIwMTUtMDYtMTYueWFuZz4sIHNob3VsZCBiZSAy MDE1LTA2LTE2DQppZXRmLWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6ODA0PG1haWx0bzppZXRm LWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6ODA0Pjogd2FybmluZzogSUVURiBydWxlIChSRkMg Zm9ybWF0dGluZyk6IGxpbmUgbGVuZ3RoIDcyIGV4Y2VlZHMgNzAgY2hhcmFjdGVycw0KaWV0Zi1s M3Zwbi1zdmNAMjAxNS0wNi0xNi55YW5nOjg1MjxtYWlsdG86aWV0Zi1sM3Zwbi1zdmNAMjAxNS0w Ni0xNi55YW5nOjg1Mj46IHdhcm5pbmc6IElFVEYgcnVsZSAoUkZDIGZvcm1hdHRpbmcpOiBsaW5l IGxlbmd0aCA3MSBleGNlZWRzIDcwIGNoYXJhY3RlcnMNCmlldGYtbDN2cG4tc3ZjQDIwMTUtMDYt MTYueWFuZzo4Nzk8bWFpbHRvOmlldGYtbDN2cG4tc3ZjQDIwMTUtMDYtMTYueWFuZzo4Nzk+OiB3 YXJuaW5nOiBJRVRGIHJ1bGUgKFJGQyBmb3JtYXR0aW5nKTogbGluZSBsZW5ndGggNzEgZXhjZWVk cyA3MCBjaGFyYWN0ZXJzDQppZXRmLWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6ODg0PG1haWx0 bzppZXRmLWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6ODg0Pjogd2FybmluZzogSUVURiBydWxl IChSRkMgZm9ybWF0dGluZyk6IGxpbmUgbGVuZ3RoIDcxIGV4Y2VlZHMgNzAgY2hhcmFjdGVycw0K aWV0Zi1sM3Zwbi1zdmNAMjAxNS0wNi0xNi55YW5nOjkwMTxtYWlsdG86aWV0Zi1sM3Zwbi1zdmNA MjAxNS0wNi0xNi55YW5nOjkwMT46IHdhcm5pbmc6IElFVEYgcnVsZSAoUkZDIGZvcm1hdHRpbmcp OiBsaW5lIGxlbmd0aCA3MiBleGNlZWRzIDcwIGNoYXJhY3RlcnMNCmlldGYtbDN2cG4tc3ZjQDIw MTUtMDYtMTYueWFuZzoxMDI0PG1haWx0bzppZXRmLWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6 MTAyND46IHdhcm5pbmc6IElFVEYgcnVsZSAoUkZDIGZvcm1hdHRpbmcpOiBsaW5lIGxlbmd0aCA3 MSBleGNlZWRzIDcwIGNoYXJhY3RlcnMNCmlldGYtbDN2cG4tc3ZjQDIwMTUtMDYtMTYueWFuZzox MjU4PG1haWx0bzppZXRmLWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6MTI1OD46IHdhcm5pbmc6 IElFVEYgcnVsZSAoUkZDIGZvcm1hdHRpbmcpOiBsaW5lIGxlbmd0aCA3MSBleGNlZWRzIDcwIGNo YXJhY3RlcnMNCmlldGYtbDN2cG4tc3ZjQDIwMTUtMDYtMTYueWFuZzoxMjcxPG1haWx0bzppZXRm LWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6MTI3MT46IHdhcm5pbmc6IElFVEYgcnVsZSAoUkZD IGZvcm1hdHRpbmcpOiBsaW5lIGxlbmd0aCA3MSBleGNlZWRzIDcwIGNoYXJhY3RlcnMNCmlldGYt bDN2cG4tc3ZjQDIwMTUtMDYtMTYueWFuZzoxNDA0PG1haWx0bzppZXRmLWwzdnBuLXN2Y0AyMDE1 LTA2LTE2Lnlhbmc6MTQwND46IHdhcm5pbmc6IElFVEYgcnVsZSAoUkZDIGZvcm1hdHRpbmcpOiBs aW5lIGxlbmd0aCA3MyBleGNlZWRzIDcwIGNoYXJhY3RlcnMNCmlldGYtbDN2cG4tc3ZjQDIwMTUt MDYtMTYueWFuZzoxNDEwPG1haWx0bzppZXRmLWwzdnBuLXN2Y0AyMDE1LTA2LTE2Lnlhbmc6MTQx MD46IHdhcm5pbmc6IElFVEYgcnVsZSAoUkZDIGZvcm1hdHRpbmcpOiBsaW5lIGxlbmd0aCA3MyBl eGNlZWRzIDcwIGNoYXJhY3RlcnMNCg0KUmVnYXJkcywgQmVub2l0DQoNCkZvbGtzLA0KDQoNCg0K VGhlIEwzU00gV0cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtbHRzZC1sM3NtLWwzdnBuLXNlcnZp Y2UtbW9kZWwgaGFzIGVuZGVkLiBUaGUgSS1EIGlzIGFkb3B0ZWQgYXMgYSBXRyBkb2N1bWVudC4N Cg0KSnVzdCB0byByZW1pbmQgdGhhdCB0aGlzIGRvY3VtZW50IHNlcnZlcyBhcyBhIGJhc2lzIGZv ciBXRyB0byBjb250aW51ZSB0byB3b3JrIG9uLg0KDQpUaGUgYXV0aG9ycyBzaG91bGQgc3VibWl0 IHRoaXMgYXMgZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwtMDAuDQoNCi1RaW4g YW5kIEFkcmlhbg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpMM3NtIG1haWxpbmcgbGlzdA0KDQpMM3NtQGlldGYub3JnPG1haWx0bzpM M3NtQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wz c20NCg0K --_000_B8F9A780D330094D99AF023C5877DABA847650A9nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks = Benoit for kindly reminding. It would be great that the pyang tool can be a= lso integrated into IDNits tool to check YANG document.

Authors= , please fix these nits when submission.

&n= bsp;

-Qin

=B7=A2= =BC=FE=C8=CB: Benoit = Claise [mailto:bclaise@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:=CB=CE=CC=E5;colo= r:windowtext"> 2015=C4=EA7=D4=C21=C8=D5 17:27
=CA=D5=BC=FE=C8=CB: Qin Wu; l3sm@ietf.org
=B3=AD=CB=CD: adrian@olddog.co.uk
=D6=F7=CC=E2: Re: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model<= /o:p>

 

Dear draft-ltsd-l3sm-l3vpn-serv= ice-model authors,

Note that

- pyang produces:
ietf-l3vpn-svc@2015-06-= 16.yang:1: warning: unexpected latest revision "2015-04-24" i= n ietf-l3vpn-svc@2015-06-16= .yang, should be 2015-06-16

- "pyang --ietf" produces:
WITH WARNINGS ietf-l3vp= n-svc@2015-06-16.yang:1: warning: unexpected latest revision "2015= -04-24" in ietf-l3vpn-svc@2015-06-16= .yang, should be 2015-06-16
ietf-l3vpn-svc@2015-0= 6-16.yang:804: warning: IETF rule (RFC formatting): line length 72 exce= eds 70 characters
ietf-l3vpn-svc@2015-0= 6-16.yang:852: warning: IETF rule (RFC formatting): line length 71 exce= eds 70 characters
ietf-l3vpn-svc@2015-0= 6-16.yang:879: warning: IETF rule (RFC formatting): line length 71 exce= eds 70 characters
ietf-l3vpn-svc@2015-0= 6-16.yang:884: warning: IETF rule (RFC formatting): line length 71 exce= eds 70 characters
ietf-l3vpn-svc@2015-0= 6-16.yang:901: warning: IETF rule (RFC formatting): line length 72 exce= eds 70 characters
ietf-l3vpn-svc@2015-= 06-16.yang:1024: warning: IETF rule (RFC formatting): line length 71 ex= ceeds 70 characters
ietf-l3vpn-svc@2015-= 06-16.yang:1258: warning: IETF rule (RFC formatting): line length 71 ex= ceeds 70 characters
ietf-l3vpn-svc@2015-= 06-16.yang:1271: warning: IETF rule (RFC formatting): line length 71 ex= ceeds 70 characters
ietf-l3vpn-svc@2015-= 06-16.yang:1404: warning: IETF rule (RFC formatting): line length 73 ex= ceeds 70 characters
ietf-l3vpn-svc@2015-= 06-16.yang:1410: warning: IETF rule (RFC formatting): line length 73 ex= ceeds 70 characters

Regards, Benoit

Folks,

 

The L3SM WG adoption call fo= r draft-ltsd-l3sm-l3vpn-service-model has ended. The I-D is adopted as a WG= document.

Just to remind that this doc= ument serves as a basis for WG to continue to work on.

 

The authors should submit this = as draft-ietf-l3sm-l3vpn-service-model-00.

 <= /span>

-Qin and Adrian




_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm

 

--_000_B8F9A780D330094D99AF023C5877DABA847650A9nkgeml501mbschi_-- From nobody Thu Jul 2 06:13:22 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621561A1BD9; Thu, 2 Jul 2015 06:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Wh4ybVRsed-i; Thu, 2 Jul 2015 06:06:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1776A1A1B89; Thu, 2 Jul 2015 06:06:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150702130617.18137.2548.idtracker@ietfa.amsl.com> Date: Thu, 02 Jul 2015 06:06:17 -0700 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 06:13:21 -0700 Cc: l3sm@ietf.org Subject: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-00.txt X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 13:06:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the L3VPN Service Model Working Group of the IETF. Title : YANG Data Model for L3VPN service delivery Authors : Stephane Litkowski Rob Shakir Luis Tomotaki Kevin D'Souza Filename : draft-ietf-l3sm-l3vpn-service-model-00.txt Pages : 82 Date : 2015-07-02 Abstract: This document defines a YANG data model that can be used to deliver a Layer 3 Provider Provisioned VPN service. The document is limited to the BGP PE-based VPNs as described in RFC4110 and RFC4364. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IPVPN service configuration components. It will be up to a management system to take this as an input and use specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-model-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 2 09:19:06 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41D61AC42C for ; Thu, 2 Jul 2015 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 LHfxqXF2KDVd for ; Thu, 2 Jul 2015 09:19:04 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1FE1AC434 for ; Thu, 2 Jul 2015 09:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15795; q=dns/txt; s=iport; t=1435853943; x=1437063543; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=3qEh8S/Nk8nWxG8n7bILPNWNVz0+M9s7RPb7KDc8QQc=; b=TZ/bHp+9JfHPI03syFh/BDXVOaUOM0HgtPwbP5Ka/2MPn2S1KanJCcBj eCovvC9B8tTM0lP7SLWRlhsWKNHD0+aeKn9wOeQKTZXgKX3FgSIfbDMoN tgCQWTTBDuFEXDY8y/onaP2OexOvMIMbwwmBz/zv7AVSEunPn3zgTPkk9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ChBAAVY5VV/xbLJq1bgkWBIV+/IwEJhXgCghcBAQEBAQGBC4QjAQEEAQEBGgYEBkEKARAJAg4KCRYIAwICCQMCAQIBFR8RBgEMBgIBAYgrDZh9nRmWPwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0qFBgYBgmiBQwEElBKLZoE6hBSCbZAOJoN8PDGCSAEBAQ X-IronPort-AV: E=Sophos;i="5.15,394,1432598400"; d="scan'208,217";a="547964813" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 02 Jul 2015 16:19:01 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t62GJ0Ku000982; Thu, 2 Jul 2015 16:19:00 GMT To: Qin Wu , "l3sm@ietf.org" References: <5593B260.8010203@cisco.com> From: Benoit Claise Message-ID: <559541FF.3010200@cisco.com> Date: Thu, 2 Jul 2015 15:51:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000603040403040906030400" Archived-At: Cc: "adrian@olddog.co.uk" Subject: Re: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 16:19:06 -0000 This is a multi-part message in MIME format. --------------000603040403040906030400 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 02/07/2015 04:27, Qin Wu wrote: > > Thanks Benoit for kindly reminding. It would be great that the pyang > tool can be also integrated into IDNits tool to check YANG document. > Completely agreed. This is planned for this Hackathon. See https://www.ietf.org/registration/MeetingWiki/wiki/93hackathon -> *NETCONF/YANG, I2RS, OpenDaylight* Regards, Benoit > > Authors, please fix these nits when submission. > > -Qin > > *������:*Benoit Claise [mailto:bclaise@cisco.com] > *����ʱ��:*2015��7��1��17:27 > *�ռ���:*Qin Wu; l3sm@ietf.org > *����:*adrian@olddog.co.uk > *����:*Re: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model > > Dear draft-ltsd-l3sm-l3vpn-service-model authors, > > Note that > > - pyang produces: > ietf-l3vpn-svc@2015-06-16.yang:1 > : warning: unexpected latest > revision "2015-04-24" in ietf-l3vpn-svc@2015-06-16.yang > , should be 2015-06-16 > > - "pyang --ietf" produces: > WITH WARNINGS ietf-l3vpn-svc@2015-06-16.yang:1 > : warning: unexpected latest > revision "2015-04-24" in ietf-l3vpn-svc@2015-06-16.yang > , should be 2015-06-16 > ietf-l3vpn-svc@2015-06-16.yang:804 > : warning: IETF rule (RFC > formatting): line length 72 exceeds 70 characters > ietf-l3vpn-svc@2015-06-16.yang:852 > : warning: IETF rule (RFC > formatting): line length 71 exceeds 70 characters > ietf-l3vpn-svc@2015-06-16.yang:879 > : warning: IETF rule (RFC > formatting): line length 71 exceeds 70 characters > ietf-l3vpn-svc@2015-06-16.yang:884 > : warning: IETF rule (RFC > formatting): line length 71 exceeds 70 characters > ietf-l3vpn-svc@2015-06-16.yang:901 > : warning: IETF rule (RFC > formatting): line length 72 exceeds 70 characters > ietf-l3vpn-svc@2015-06-16.yang:1024 > : warning: IETF rule (RFC > formatting): line length 71 exceeds 70 characters > ietf-l3vpn-svc@2015-06-16.yang:1258 > : warning: IETF rule (RFC > formatting): line length 71 exceeds 70 characters > ietf-l3vpn-svc@2015-06-16.yang:1271 > : warning: IETF rule (RFC > formatting): line length 71 exceeds 70 characters > ietf-l3vpn-svc@2015-06-16.yang:1404 > : warning: IETF rule (RFC > formatting): line length 73 exceeds 70 characters > ietf-l3vpn-svc@2015-06-16.yang:1410 > : warning: IETF rule (RFC > formatting): line length 73 exceeds 70 characters > > Regards, Benoit > > Folks, > > The L3SM WG adoption call for draft-ltsd-l3sm-l3vpn-service-model > has ended. The I-D is adopted as a WG document. > > Just to remind that this document serves as a basis for WG to > continue to work on. > > The authors should submit this as > draft-ietf-l3sm-l3vpn-service-model-00. > > -Qin and Adrian > > > > > _______________________________________________ > > L3sm mailing list > > L3sm@ietf.org > > https://www.ietf.org/mailman/listinfo/l3sm > --------------000603040403040906030400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 02/07/2015 04:27, Qin Wu wrote:

Thanks Benoit for kindly reminding. It would be great that the pyang tool can be also integrated into IDNits tool to check YANG document.

Completely agreed.
This is planned for this Hackathon.
See https://www.ietf.org/registration/MeetingWiki/wiki/93hackathon
    -> NETCONF/YANG, I2RS, OpenDaylight

Regards, Benoit

Authors, please fix these nits when submission.

 

-Qin

������: Benoit Claise [mailto:bclaise@cisco.com]
����ʱ��: 2015��7��1�� 17:27
�ռ���: Qin Wu; l3sm@ietf.org
����: adrian@olddog.co.uk
����: Re: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model

 

Dear draft-ltsd-l3sm-l3vpn-service-model authors,

Note that

- pyang produces:
ietf-l3vpn-svc@2015-06-16.yang:1: warning: unexpected latest revision "2015-04-24" in ietf-l3vpn-svc@2015-06-16.yang, should be 2015-06-16

- "pyang --ietf" produces:
WITH WARNINGS ietf-l3vpn-svc@2015-06-16.yang:1: warning: unexpected latest revision "2015-04-24" in ietf-l3vpn-svc@2015-06-16.yang, should be 2015-06-16
ietf-l3vpn-svc@2015-06-16.yang:804: warning: IETF rule (RFC formatting): line length 72 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:852: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:879: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:884: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:901: warning: IETF rule (RFC formatting): line length 72 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1024: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1258: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1271: warning: IETF rule (RFC formatting): line length 71 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1404: warning: IETF rule (RFC formatting): line length 73 exceeds 70 characters
ietf-l3vpn-svc@2015-06-16.yang:1410: warning: IETF rule (RFC formatting): line length 73 exceeds 70 characters

Regards, Benoit

Folks,

 

The L3SM WG adoption call for draft-ltsd-l3sm-l3vpn-service-model has ended. The I-D is adopted as a WG document.

Just to remind that this document serves as a basis for WG to continue to work on.

 

The authors should submit this as draft-ietf-l3sm-l3vpn-service-model-00.

 

-Qin and Adrian




_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm

 


--------------000603040403040906030400-- From nobody Sun Jul 5 12:02:05 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4861A8847 for ; Sun, 5 Jul 2015 11:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 1etmxPceqGBh for ; Sun, 5 Jul 2015 11:55:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D2E1A0108 for ; Sun, 5 Jul 2015 11:55:44 -0700 (PDT) Received: from BY2PR0301MB0693.namprd03.prod.outlook.com (10.160.63.148) by BY2PR0301MB0693.namprd03.prod.outlook.com (10.160.63.148) with Microsoft SMTP Server (TLS) id 15.1.207.19; Sun, 5 Jul 2015 18:55:43 +0000 Received: from BY2PR0301MB0693.namprd03.prod.outlook.com ([10.160.63.148]) by BY2PR0301MB0693.namprd03.prod.outlook.com ([10.160.63.148]) with mapi id 15.01.0207.004; Sun, 5 Jul 2015 18:55:43 +0000 From: Luyuan Fang To: "bill.wu@huawei.com" , "l3sm@ietf.org" Thread-Topic: Re: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model Thread-Index: AdC3U84/OaxOgg1dStW0t1QFwAMa4A== Date: Sun, 5 Jul 2015 18:55:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-originating-ip: [73.157.113.72] x-microsoft-exchange-diagnostics: 1; BY2PR0301MB0693; 5:JolxdFQunQb/HdVRvqUYxSCZ3UcTIiy2Ndoe73AGPqhyE4p57F75wjmQ0e6nO3ROIi5J1oltMrtkYYGd3NxLYLTuoWgBVXq2DZFjBDYcAgzU48Abe4CL9grr9bLNma6KqZiM1SmkyP2I+97UXHFOhQ==; 24:dH3qvg37md4/jNySJMtvOiSWnENfM3t5BlPP6A3u/djYOllgqgKGCUO2TuJP8x0N+Xs/tTXw60SJkzpxYG5WR80cJxFstU9kSgIYMhJudCs=; 20:RdJGKi9wJgi5hJzKHTQozhCuQ/h3QobE619L0G7n83JWhWuCkccqNYQya+jpXVhyDj1jNzPZrF9hHVbT4xCAmA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0301MB0693; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR0301MB0693; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0301MB0693; x-forefront-prvs: 062899525A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2900100001)(5003600100002)(19580395003)(19580405001)(46102003)(5001770100001)(5001960100002)(54356999)(19625215002)(230783001)(76576001)(107886002)(122556002)(2501003)(87936001)(40100003)(2656002)(86362001)(5002640100001)(74316001)(15975445007)(16236675004)(50986999)(33656002)(77156002)(62966003)(5001920100001)(102836002)(19300405004)(99286002)(66066001)(77096005)(92566002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0693; H:BY2PR0301MB0693.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY2PR0301MB06933F572468B6FF0D5F7CCAD6940BY2PR0301MB0693_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2015 18:55:42.9586 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0301MB0693 Archived-At: X-Mailman-Approved-At: Sun, 05 Jul 2015 12:02:04 -0700 Subject: Re: [L3sm] Poll for adoption of draft-ltsd-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2015 18:55:56 -0000 --_000_BY2PR0301MB06933F572468B6FF0D5F7CCAD6940BY2PR0301MB0693_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been reading this I-D in preparation for Prague and I think it's a fin= e piece of work. I'm glad the WG has adopted it. -Luyuan Qin Wu Wed, 01 July 2015 08:24 UTC Folks, The L3SM WG adoption call for draft-ltsd-l3sm-l3vpn-service-model has ended= . The I-D is adopted as a WG document. Just to remind that this document serves as a basis for WG to continue to w= ork on. The authors should submit this as draft-ietf-l3sm-l3vpn-service-model-00. -Qin and Adrian --_000_BY2PR0301MB06933F572468B6FF0D5F7CCAD6940BY2PR0301MB0693_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I've been reading this I-D in preparation for Prague= and I think it's a fine piece of work. I'm glad the WG has adopted it.

-Luyuan

 

Qin= Wu <bill.wu@huawei.com> Wed, 01 July 2015 08:24 UTC 

Folks,
The L3SM =
WG adoption call for draft-ltsd-l3sm-l3vpn-service-model has ended. The I-D=
 is adopted as a WG document.
Just to r=
emind that this document serves as a basis for WG to continue to work on.
The autho=
rs should submit this as draft-ietf-l3sm-l3vpn-service-model-00.=

-Qin and =
Adrian

 

--_000_BY2PR0301MB06933F572468B6FF0D5F7CCAD6940BY2PR0301MB0693_-- From nobody Mon Jul 6 04:13:56 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACC01A01E7 for ; Mon, 6 Jul 2015 04:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 VW2txEUhfnHu for ; Mon, 6 Jul 2015 04:13:53 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB061A01AA for ; Mon, 6 Jul 2015 04:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2118; q=dns/txt; s=iport; t=1436181233; x=1437390833; h=to:from:subject:message-id:date:mime-version; bh=46+zU9/JpvrFJYnVgE883x6PJ52pRKF0pPaLpq1ntFc=; b=cBRv1B2gLGyoTXEpowL7w66A67D15zuLIm59Tj1+cBNgxmkZJnc0o623 ZPP83+Z+rT4VuneEFEhfVssCtTkg+uoI3Nvt1hdIC/B7/GO488UmfNFaA by6baIhr60G5c39nFw4AX2Y8MewyKhCxv/2+3+ZrVLy4J6S5ITCxEZ7sS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D4BAAQYppV/xbLJq1cg2aDf7wqhXuBaBEBAQEBAQEBgQqETVUgARwWCwILAwIBAgFLDQgBAYgqDaJaj1+VcgEBAQcBAQEBGgSPeFWCc4FDBZQVhGKHBog8kBomghEXgVU8gTWBRwEBAQ X-IronPort-AV: E=Sophos;i="5.15,414,1432598400"; d="scan'208,217";a="556758003" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 06 Jul 2015 11:13:50 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t66BDnp6011153 for ; Mon, 6 Jul 2015 11:13:49 GMT To: "l3sm@ietf.org" From: Benoit Claise Message-ID: <559A62ED.9060001@cisco.com> Date: Mon, 6 Jul 2015 13:13:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060908060704070601010207" Archived-At: Subject: [L3sm] draft-ietf-l3sm-l3vpn-service-model feedback X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 11:13:55 -0000 This is a multi-part message in MIME format. --------------060908060704070601010207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Thanks for posting draft-ietf-l3sm-l3vpn-service-model. From the abstract, I see: This document defines a YANG data model that can be used to deliver a Layer 3 Provider Provisioned VPN service. The document is limited to the BGP PE-based VPNs as described inRFC4110 andRFC4364 . I wonder: What is specific to BGP PE-based VPNs in this YANG model? From the L3SM charter, "Instead it contains the characteristics of the service, as discussed between the operators and their customers." "Do you want a BGP PE-based VPNs", is this a typical question that operators ask to the customers? Regards, Benoit --------------060908060704070601010207 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear authors,

Thanks for posting draft-ietf-l3sm-l3vpn-service-model.
From the abstract, I see:
This document defines a YANG data model that can be used to deliver a
Layer 3 Provider Provisioned VPN service.  The document is limited to
the BGP PE-based VPNs as described in RFC4110 and RFC4364.
I wonder:  What is specific to BGP PE-based VPNs in this YANG model?
From the L3SM charter, "Instead it contains the characteristics of the service, as discussed between the operators and their customers."
"Do you want a BGP PE-based VPNs", is this a typical question that operators ask to the customers?

Regards, Benoit

--------------060908060704070601010207-- From nobody Thu Jul 9 01:53:01 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FDD1ACE92 for ; Thu, 9 Jul 2015 01:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, J_CHICKENPOX_12=0.6, MANY_SPAN_IN_TEXT=2.399, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 RAuxAW67RGjQ for ; Thu, 9 Jul 2015 01:52:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FAE51ACE91 for ; Thu, 9 Jul 2015 01:52:55 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 5D09519058B; Thu, 9 Jul 2015 10:52:53 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 3E531180084; Thu, 9 Jul 2015 10:52:53 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0235.001; Thu, 9 Jul 2015 10:52:52 +0200 From: To: Aijun Wang , "l3sm@ietf.org" Thread-Topic: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-00.txt Thread-Index: AQHQtMfpkB2m6+Fw0EGMzlvOWS0eBp3SoWsAgAA5tlA= Date: Thu, 9 Jul 2015 08:52:51 +0000 Message-ID: <21006_1436431973_559E3665_21006_7973_1_9E32478DFA9976438E7A22F69B08FF921669DB78@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20150702130617.18137.2548.idtracker@ietfa.amsl.com> <001f01d0ba16$4a44bcd0$dece3670$@org.cn> In-Reply-To: <001f01d0ba16$4a44bcd0$dece3670$@org.cn> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921669DB78OPEXCLILMA4corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.9.80320 Archived-At: Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-00.txt X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 08:53:00 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921669DB78OPEXCLILMA4corp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi, Please find inline comments. From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Thursday, July 09, 2015 09:10 To: l3sm@ietf.org Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-00.txt Hi, All: I read through this draft and the corresponding YANG model, and has the fol= lowing opinions and suggestions, please to see whether are they appropriate? General Questions: 1. Can we divide the contents in more service modules? Such as l3vpn,= Internet access, multicast service etc. [SLI] This is something that can be discussed, but I=1B$B!G=1B(Bm intereste= d in arguments. For Cloud access (including Internet), I had in mind to pro= pose to take it out of the vpn cfg. 2. Can we omitted the background information for VPN topology?. [SLI] What= info are you talking about ? 3. we need one standalone document to describe clearly the relationship be= tween the service orchestrator module and other system, such as OSS system= =1B$B!#=1B(B 4. can we make one clear boundary for what should be consider by service m= odel and what should be considered by device model, to reduce the overlappi= ng between them? 5. Is there any mechanism to decompose the l3vpn service to underlying dev= ice model automatically? Or else there is no more merit to use the YANG mod= el to describe the service. [SLI] It would be a role between orchestration and PNF manager to do the tr= anslation. Detailed suggestion about the YANG model: 1. About =1B$B!H=1B(BSite-availability=1B$B!I=1B(B a) Identity "Single" should be "Single-Site" [SLI] Agree 2. About =1B$B!H=1B(BSite-type=1B$B!I=1B(B a) Identity =1B$B!H=1B(BSite-type=1B$B!I=1B(B should be =1B$B!H=1B(= Bsite-role=1B$B!I=1B(B [SLI] Sounds good to me b) Identity =1B$B!H=1B(Bany-to-any site=1B$B!I=1B(B should be =1B$B= !H=1B(Bnormal role(can access all other sites)=1B$B!I=1B(B c) Identity =1B$B!H=1B(Bspoke-site=1B$B!I=1B(B should be =1B$B!H=1B= (Bspoke-role=1B$B!I=1B(B [SLI] I=1B$B!G=1B(Bm fine, if other people think t= his is useful to change d) Identity =1B$B!H=1B(Bhub-site=1B$B!I=1B(B should be =1B$B!H=1B(B= hub-role=1B$B!I=1B(B [SLI] I=1B$B!G=1B(Bm fine, if other people think this = is useful to change 3. About =1B$B!H=1B(Bvpn-topology=1B$B!I=1B(B There is no restriction or relationship description for the =1B$B!H=1B(B= site-type=1B$B!I=1B(B and =1B$B!I=1B(Bvpn-topology=1B$B!I=1B(B. For example= , if one vpn service is =1B$B!H=1B(Bany-to-any=1B$B!I=1B(B, then the role o= f all sites within it will be =1B$B!H=1B(Bnormal-role=1B$B!I=1B(B. And the = =1B$B!H=1B(Bhub-role=1B$B!I=1B(B, =1B$B!H=1B(Bspoke-role=1B$B!I=1B(B should= only exist within the =1B$B!H=1B(Bhub-spoke=1B$B!I=1B(B or =1B$B!H=1B(Bhub= -spoke-disjoint=1B$B!I=1B(B vpn topology. Can we organize these two identi= ty within one container? [SLI] I will see how to do this. 4. About =1B$B!H=1B(Brouting-protocol-type=1B$B!I=1B(B a) Why not include the isis protocol identity? b) =1B$B!H=1B(Bvrrp=1B$B!I=1B(B identity is not one routing-protocol [SLI] about a) , do you know someone using isis as PE-CE routing protocol ?= we can add it, but is it useful ? about vrrp, I agree that=1B$B!G=1B(Bs it= not a routing protocol but I wanted to keep the model simple and let all t= he =1B$B!H=1B(Brouting methods=1B$B!I=1B(B within the same container. If yo= u find a better name than routing protocol, I would be fine to change it. 5. About =1B$B!H=1B(Bl4-protocol-type=1B$B!I=1B(B a) This should be changed to =1B$B!H=1B(Btraffic protocol type=1B$B= !I=1B(B ? This value only be used within the Qos match action and =1B$B!H= =1B(Bicmp=1B$B!I=1B(B, =1B$B!H=1B(Bicmp6=1B$B!I=1B(B, =1B$B!H=1B(Bhop-by-ho= p=1B$B!I=1B(B etc. identity are not belong to l4 protocol. [SLI] I agree that there is a misuse of the name, but I think protocol is = maybe too generic as it can refer to any layer. I want only to refer to the= protocol type in IP header. 6. About =1B$B!H=1B(Bcloud-access=1B$B!I=1B(B Can its name be changed to =1B$B!H=1B(BInternet-Access=1B$B!I=1B(B? [SLI]= No, because it also permit to access to some Private cloud 7. About =1B$B!H=1B(BAnycast-rp-locatioin=1B$B!I=1B(B Can its name be changed to =1B$B!H=1B(Brp-location=1B$B!I=1B(B? 8. What is meaning and usage of =1B$B!H=1B(Bnative-vpn=1B$B!I=1B(B? [SLI] There was some issue to model sites belonging to multiple VPNs with c= omplex policies. So we decided that a site is primarly belonging to one VPN= (the native VPN) and then can define some policies to open access to other= VPNs. 9. About VPN service start and end leaf type. Is it useful to introduce the following leaf type : =1B$B!H=1B(Brequested= -site-start=1B$B!I=1B(B/=1B$B!H=1B(Brequested-site-stop=1B$B!I=1B(B/=1B$B!I= =1B(Bactual-site-start=1B$B!I=1B(B/=1B$B!I=1B(B actual-site-stop=1B$B!I=1B(= B if we use the http restful API to provide the service to customer? [SLI] There was a discussion thread on the list regarding that. 10. what is the meaning of =1B$B!H=1B(Bsite-diversity=1B$B!I=1B(B [SLI] Site diversity opens the ability to provision multiple sites within a= VPN that are not sharing the same fate. 11. =1B$B!H=1B(Bmaximus-routes=1B$B!I=1B(B should be included within the = =1B$B!H=1B(Bvpn-policy=1B$B!I=1B(B under the import-policy/export-policy [SLI] What=1B$B!G=1B(Bs the reason to do that ? 12. =1B$B!H=1B(Blan-prefix=1B$B!I=1B(B should be =1B$B!H=1B(Bsite-prefix=1B= $B!I=1B(B. Also for =1B$B!H=1B(Bipv4-lan-prefixes/ipv6-lan-prefixes/lan-tag= =1B$B!I=1B(B [SLI] I personally don=1B$B!G=1B(Bt care, so I will people comment on this. Best Regards. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Intelligent Network Product Line Tel : 010-58552347 Mobile: 13301168517 -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Thursday, July 02, 2015 9:06 PM To: i-d-announce@ietf.org Cc: l3sm@ietf.org Subject: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the L3VPN Service Model Working Group of the = IETF. Title : YANG Data Model for L3VPN service delivery Authors : Stephane Litkowski Rob Shakir Luis Tomotaki Kevin D'Souza Filename : draft-ietf-l3sm-l3vpn-service-model-00.txt Pages : 82 Date : 2015-07-02 Abstract: This document defines a YANG data model that can be used to deliver a Layer 3 Provider Provisioned VPN service. The document is limited to the BGP PE-based VPNs as described in RFC4110 and RFC4364. This model is intended to be instantiated at management system to deliver the overall service. This model is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IPVPN service configuration components. It will be up to a management system to take this as an input and use specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-model-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF921669DB78OPEXCLILMA4corp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Hi,

=  

Pleas= e find inline comments.

=  

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Thursday, July 09, 2015 09:10
To: l3sm@ietf.org
Subject: Re: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-= 00.txt

 =

Hi, All:

I read through this draft and the corresponding YANG= model, and has the following opinions and suggestions, please to see wheth= er are they appropriate?

 

General Questions:

1.     &= nbsp; Can we divide the contents in more service modules?= Such as l3vpn, Internet access, multicast service etc.

[SLI] This is s= omething that can be discussed, but I=1B$B!G=1B(Bm interested in arguments.= For Cloud access (including Internet), I had in mind to propose to take it= out of the vpn cfg.

2.  Can we omitted the background information f= or VPN topology?. [SLI] What info are you tal= king about ?

3.  we need one standalone document to describe= clearly the relationship between the service orchestrator module and other= system, such as OSS system=1B$B!#=1B(B

4.  can we make one clear boundary for what sho= uld be consider by service model and what should be considered by device mo= del, to reduce the overlapping between them?

5.  Is there any mechanism to decompose the l3v= pn service to underlying device model automatically? Or else there is no mo= re merit to use the YANG model to describe the service.

[SLI] It would be a ro= le between orchestration and PNF manager to do the translation.

=  

Detailed suggestion about the YANG model:=

1.      &nbs= p;  About =1B$B!H=1B(BSite-availability=1B$B!I=1B(B

a)      &nbs= p;  Identity "Single" should be "Single-= Site" [SLI] Agree

 

2.      &nbs= p;  About =1B$B!H=1B(BSite-type=1B$B!I=1B(B

a)      &nbs= p;  Identity =1B$B!H=1B(BSite-type=1B$B!I=1B(B should be =1B$B!H=1B(Bsite= -role=1B$B!I=1B(B [SLI] Sounds good to me

b)      &nbs= p;  Identity =1B$B!H=1B(Bany-to-any site=1B$B!I=1B(B should be =1B$B!H=1B(Bnorm= al role(can access all other sites)=1B$B!I=1B(B

c)      &nbs= p;  Identity =1B$B!H=1B(Bspoke-site=1B$B!I=1B(B should be =1B$B!H=1B(Bspok= e-role=1B$B!I=1B(B [SLI] I=1B$B!G=1B(Bm fine, if other people think = this is useful to change

d)      &nbs= p;  Identity =1B$B!H=1B(Bhub-site=1B$B!I=1B(B should be =1B$B!H=1B(Bhub-= role=1B$B!I=1B(B [SLI] I=1B$B!G=1B(Bm fine, if other people think th= is is useful to change

 

3.  About =1B$B!H=1B(Bvpn-topology=1B$B!I=1B(B

   There is no restriction or relations= hip description for the =1B$B!H=1B(Bsite= -type=1B$B!I=1B(B and =1B$B!I=1B(Bvpn-= topology=1B$B!I=1B(B. For example, if one vpn service is =1B$B!H=1B(Bany-= to-any=1B$B!I=1B(B, then the role of all sites within it will be =1B$B!H=1B(Bnorm= al-role=1B$B!I=1B(B. And the =1B$B!H=1B(Bhub-= role=1B$B!I=1B(B, =1B$B!H=1B(Bspok= e-role=1B$B!I=1B(B should only exist within the =1B$B!H=1B(Bhub-= spoke=1B$B!I=1B(B or =1B$B!H=1B(Bhub-= spoke-disjoint=1B$B!I= =1B(B vpn topology.  Can we organize these two identity within = one container?

[SLI] I will see ho= w to do this.

 

4.  About =1B$B!H=1B(Brouting-protocol-type=1B$B!I=1B(B

a)      &nbs= p;  Why not include the isis protocol identity?

b)      &nbs= p;  =1B$B!H=1B(Bvrrp=1B$B!I=1B(B identity is not one routing-protocol

[SLI] about a) , do= you know someone using isis as PE-CE routing protocol ? we can add it, but= is it useful ? about vrrp, I agree that=1B$B!G=1B(Bs it not a routing prot= ocol but I wanted to keep the model simple and let all the =1B$B!H=1B(Brouting methods=1B$B!I=1B(B within the same contai= ner. If you find a better name than routing protocol, I would be fine to ch= ange it.

 

5. About =1B$B!H=1B(Bl4-protocol-type=1B$B!I=1B(B

a)      &nbs= p;  This should be changed to =1B$B!H=1B(Btraffic protocol type=1B$B!I=1B(B ? This value only be used within the Q= os match action and =1B$B!H=1B(Bicmp= =1B$B!I=1B(B, =1B$B!H=1B(Bicmp= 6=1B$B!I=1B(B, =1B$B!H=1B(Bhop-= by-hop=1B$B!I=1B(B etc. identity are not belong to l4 protocol.

[SLI]  I agree that there is a misuse of the name, but I thi= nk protocol is maybe too generic as it can refer to any layer. I want only = to refer to the protocol type in IP header.

 

6. About =1B$B!H=1B(Bcloud-access=1B$B!I=1B(B

  Can its name be changed to =1B$B!H=1B(BInternet-Access=1B$B!I=1B(B? [SLI] No, bec= ause it also permit to access to some Private cloud

 

7. About =1B$B!H=1B(BAnycast-rp-locatioin=1B$B!I=1B(B

 Can its name be changed to =1B$B!H=1B(Brp-location=1B$B!I=1B(B?

 

8. What is meaning and usage of =1B$B!H=1B(Bnative-vpn=1B$B!I=1B(B?

[S= LI] There was some issue to model sites belonging to multiple VPNs with com= plex policies. So we decided that a site is primarly belonging to one VPN (= the native VPN) and then can define some policies to open access to other VPNs.

 

9. About VPN service start and end leaf type.

  Is it useful to introduce the following le= af type : =1B$B!H=1B(Brequested-site-start=1B$B!I=1B(B/=1B$B!H=1B(Brequested-site-stop=1B$B!I=1B(B/=1B$B!I=1B(Bactual-site-start=1B$B!I=1B(B/=1B$B!I=1B(B actual-site-stop=1B$B!= I=1B(B if we use the http restful API to provide the service to cust= omer?

[S= LI] There was a discussion thread on the list regarding that.

 

10. what is the meaning of =1B$B!H=1B(Bsite-diversity=1B$B!I=1B(B

[S= LI] Site diversity opens the ability to provision multiple sites within a V= PN that are not sharing the same fate.

 

11. =1B$B!H=1B(Bmaximus-routes=1B$B!I=1B(B should be included within the =1B$B!H=1B(Bvpn-= policy=1B$B!I=1B(B under the import-policy/export-policy

[S= LI] What=1B$B!G=1B(Bs the reason to do that ?

 

12. =1B$B!H=1B(Blan-prefix=1B$B!I=1B(B should be =1B$B!H=1B(Bsite= -prefix=1B$B!I=1B(B. Also for =1B$B!H=1B(Bipv4= -lan-prefixes/ipv6-lan-prefixes/lan-tag=1B$B!I=1B(B

[SLI] I personally = don=1B$B!G=1B(Bt care, so I will people comment on this.<= /p>

 

 

Best Regards.

Aijun Wang

 

China Telecom Corporation Limited Beijing Resear= ch Institute 

Intelligent Network Product Line

 

Tel : 010-58552347

Mobile:  13301168517

 

 

 

 

-----Original Message-----
From: L3sm [mailto:l3sm-bounces@ie= tf.org] On Behalf Of internet-drafts@ietf.org
Sent: Thursday, July 02, 2015 9:06 PM
To: i-d-announce@ietf.org
Cc: l3sm@ietf.org
Subject: [L3sm] I-D Action: draft-ietf-l3sm-l3vpn-service-model-00.txt=

 

 

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories.

This draft is a work item of the L3VPN Service Mo= del  Working Group of the IETF.

 

        Title&= nbsp;          : YANG Data Mod= el for L3VPN service delivery

        Author= s         : Stephane Litkowski=

        &= nbsp;           &nbs= p;     Rob Shakir

        &= nbsp;           &nbs= p;     Luis Tomotaki

        &= nbsp;           &nbs= p;     Kevin D'Souza

         = Filename        : draft-ietf-l3sm-l3vpn-= service-model-00.txt

         = Pages           : 82=

         = Date            : 20= 15-07-02

 

Abstract:

   This document defines a YANG data mo= del that can be used to deliver a

   Layer 3 Provider Provisioned VPN ser= vice.  The document is limited to

   the BGP PE-based VPNs as described i= n RFC4110 and RFC4364.  This

   model is intended to be instantiated= at management system to deliver

   the overall service.  This mode= l is not a configuration model to be

   used directly on network elements.&n= bsp; This model provides an abstracted

   view of the Layer 3 IPVPN service co= nfiguration components.  It will

   be up to a management system to take= this as an input and use

   specific configurations models to co= nfigure the different network

   elements to deliver the service.&nbs= p; How configuration of network

   elements is done is out of scope of = the document.

 

 

 

The IETF datatracker status page for this draft i= s:

https://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-= model/

 

There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-model-00=

 

 

Please note that it may take a couple of minutes = from the time of submission until the htmlized version and diff are availab= le at tools.ietf.org.

 

Internet-Drafts are also available by anonymous F= TP at:

<= span style=3D"color:windowtext;text-decoration:none">ftp://ftp.ietf.org/int= ernet-drafts/

 

_______________________________________________

L3sm mailing list

L3sm@ietf.org

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

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF921669DB78OPEXCLILMA4corp_-- From nobody Thu Jul 9 01:57:32 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5461ACE84 for ; Thu, 9 Jul 2015 01:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 yjnSI60EYX4X for ; Thu, 9 Jul 2015 01:57:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 913771A03A0 for ; Thu, 9 Jul 2015 01:57:27 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E16182DC963; Thu, 9 Jul 2015 10:57:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BE88627C095; Thu, 9 Jul 2015 10:57:25 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0235.001; Thu, 9 Jul 2015 10:57:25 +0200 From: To: Benoit Claise , "l3sm@ietf.org" Thread-Topic: [L3sm] draft-ietf-l3sm-l3vpn-service-model feedback Thread-Index: AQHQt9zbJgN968FJ/Umo9vrv9Ib91J3S2bHQ Date: Thu, 9 Jul 2015 08:57:24 +0000 Message-ID: <24850_1436432245_559E3775_24850_1614_13_9E32478DFA9976438E7A22F69B08FF921669DB9A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <559A62ED.9060001@cisco.com> In-Reply-To: <559A62ED.9060001@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921669DB9AOPEXCLILMA4corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.2.125417 Archived-At: Subject: Re: [L3sm] draft-ietf-l3sm-l3vpn-service-model feedback X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 08:57:29 -0000 --_000_9E32478DFA9976438E7A22F69B08FF921669DB9AOPEXCLILMA4corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVub2l0LA0KDQpDdXJyZW50bHkgd2Uga25vdyB0aGF0IHRoZSBtb2RlbCBtYXBzIGNvcnJl Y3RseSB0byBhIEJHUCBQRS1CYXNlZCBWUE4sIGJ1dCBub3Qgc3VyZSB0aGF0IGl0IGZpbGxzIGFu eSBWUE4gc2NlbmFyaW8gbGlrZSAoQ0UgdG8gQ0Ug4oCmICkuDQpXaGVuIHdlIGRpc2N1c3NlZCBh dCB0aGUgYmVnaW5uaW5nLCB3ZSBhZ3JlZWQgdG8gc3RhcnQgd2l0aCB0aGlzIFZQTiBtb2RlbCBh bmQgdGhlbiBzZWUgaG93IGl0IG1hcHMgdG8gb3RoZXJzLg0KDQpCZXN0IFJlZ2FyZHMsDQoNClN0 ZXBoYW5lDQoNCg0KRnJvbTogTDNzbSBbbWFpbHRvOmwzc20tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEJlbm9pdCBDbGFpc2UNClNlbnQ6IE1vbmRheSwgSnVseSAwNiwgMjAxNSAxMzox NA0KVG86IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFtMM3NtXSBkcmFmdC1pZXRmLWwzc20tbDN2 cG4tc2VydmljZS1tb2RlbCBmZWVkYmFjaw0KDQpEZWFyIGF1dGhvcnMsDQoNClRoYW5rcyBmb3Ig cG9zdGluZyBkcmFmdC1pZXRmLWwzc20tbDN2cG4tc2VydmljZS1tb2RlbC4NCkZyb20gdGhlIGFi c3RyYWN0LCBJIHNlZToNCg0KVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVs IHRoYXQgY2FuIGJlIHVzZWQgdG8gZGVsaXZlciBhDQoNCkxheWVyIDMgUHJvdmlkZXIgUHJvdmlz aW9uZWQgVlBOIHNlcnZpY2UuICBUaGUgZG9jdW1lbnQgaXMgbGltaXRlZCB0bw0KDQp0aGUgQkdQ IFBFLWJhc2VkIFZQTnMgYXMgZGVzY3JpYmVkIGluIFJGQzQxMTA8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzQxMTA+IGFuZCBSRkM0MzY0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM0MzY0Pi4NCkkgd29uZGVyOiAgV2hhdCBpcyBzcGVjaWZpYyB0byBCR1AgUEUtYmFzZWQg VlBOcyBpbiB0aGlzIFlBTkcgbW9kZWw/DQpGcm9tIHRoZSBMM1NNIGNoYXJ0ZXIsICJJbnN0ZWFk IGl0IGNvbnRhaW5zIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIHNlcnZpY2UsIGFzIGRpc2N1 c3NlZCBiZXR3ZWVuIHRoZSBvcGVyYXRvcnMgYW5kIHRoZWlyIGN1c3RvbWVycy4iDQoiRG8geW91 IHdhbnQgYSBCR1AgUEUtYmFzZWQgVlBOcyIsIGlzIHRoaXMgYSB0eXBpY2FsIHF1ZXN0aW9uIHRo YXQgb3BlcmF0b3JzIGFzayB0byB0aGUgY3VzdG9tZXJzPw0KDQpSZWdhcmRzLCBCZW5vaXQNCgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KCg== --_000_9E32478DFA9976438E7A22F69B08FF921669DB9AOPEXCLILMA4corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEJlbm9pdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkN1cnJlbnRseSB3ZSBr bm93IHRoYXQgdGhlIG1vZGVsIG1hcHMgY29ycmVjdGx5IHRvIGEgQkdQIFBFLUJhc2VkIFZQTiwg YnV0IG5vdCBzdXJlIHRoYXQgaXQgZmlsbHMgYW55IFZQTiBzY2VuYXJpbyBsaWtlIChDRSB0byBD RSDigKYgKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hlbiB3ZSBkaXNjdXNzZWQg YXQgdGhlIGJlZ2lubmluZywgd2UgYWdyZWVkIHRvIHN0YXJ0IHdpdGggdGhpcyBWUE4gbW9kZWwg YW5kIHRoZW4gc2VlIGhvdyBpdCBtYXBzIHRvIG90aGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlN0ZXBoYW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBM M3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5C ZW5vaXQgQ2xhaXNlPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSnVseSAwNiwgMjAxNSAxMzox NDxicj4NCjxiPlRvOjwvYj4gbDNzbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbTDNz bV0gZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwgZmVlZGJhY2s8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGF1dGhvcnMsPGJyPg0K PGJyPg0KVGhhbmtzIGZvciBwb3N0aW5nIGRyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1v ZGVsLjxicj4NCkZyb20gdGhlIGFic3RyYWN0LCBJIHNlZTo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+ VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRhIG1vZGVsIHRoYXQgY2FuIGJlIHVzZWQg dG8gZGVsaXZlciBhPG86cD48L286cD48L3ByZT4NCjxwcmU+TGF5ZXIgMyBQcm92aWRlciBQcm92 aXNpb25lZCBWUE4gc2VydmljZS4mbmJzcDsgVGhlIGRvY3VtZW50IGlzIGxpbWl0ZWQgdG88bzpw PjwvbzpwPjwvcHJlPg0KPHByZT50aGUgQkdQIFBFLWJhc2VkIFZQTnMgYXMgZGVzY3JpYmVkIGlu IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MTEwIj5SRkM0MTEwPC9h PiBhbmQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQzNjQiPlJGQzQz NjQ8L2E+LiA8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5JIHdvbmRlcjombmJzcDsgV2hhdCBpcyBzcGVjaWZpYyB0byBC R1AgUEUtYmFzZWQgVlBOcyBpbiB0aGlzIFlBTkcgbW9kZWw/PGJyPg0KRnJvbSB0aGUgTDNTTSBj aGFydGVyLCAmcXVvdDtJbnN0ZWFkIGl0IGNvbnRhaW5zIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2Yg dGhlIHNlcnZpY2UsIGFzIGRpc2N1c3NlZCBiZXR3ZWVuIHRoZSBvcGVyYXRvcnMgYW5kIHRoZWly IGN1c3RvbWVycy4mcXVvdDsNCjxicj4NCiZxdW90O0RvIHlvdSB3YW50IGEgQkdQIFBFLWJhc2Vk IFZQTnMmcXVvdDssIGlzIHRoaXMgYSB0eXBpY2FsIHF1ZXN0aW9uIHRoYXQgb3BlcmF0b3JzIGFz ayB0byB0aGUgY3VzdG9tZXJzPzxicj4NCjxicj4NClJlZ2FyZHMsIEJlbm9pdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0 bWw+DQo= --_000_9E32478DFA9976438E7A22F69B08FF921669DB9AOPEXCLILMA4corp_-- From nobody Thu Jul 9 02:02:42 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7476B1ACE9D for ; Thu, 9 Jul 2015 02:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 EFVece1UG5va for ; Thu, 9 Jul 2015 02:02:38 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF5F1ACE9E for ; Thu, 9 Jul 2015 02:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10868; q=dns/txt; s=iport; t=1436432558; x=1437642158; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=vY5/kYNVUYHo7V+2MgjPTH9va953+jJknDXNvXTtgPo=; b=Anf5dV3Hj4MpF667k6MkyGX2cQMQ8EiSws80pM8vfdtIWRqmew1PtzTP bgkz8BmBqh2axbz7lAdrY8yBwtluFqnaDNe0g2C0dTpTjKT9ILUPyGL1+ 6CjKlO7IskXGx0t4YMPNUat7hPmVqnPYfuEAHJcO58LMC2qH0epItDMuQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8BAAdOJ5V/xbLJq1bgkWBIWCDILlxhXsCgiQBAQEBAQGBC4QjAQEBAwEjCksGCwsRBAEBChYIAwICCQMCAQIBNAkIBgEMBgIBAYgiCA23T5YxAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLS4QjCgcBVwEGgmKBQwWULIRnhxmBPIQYgm2QJCaCEReBVTwxgQQJF4EnAQEB X-IronPort-AV: E=Sophos;i="5.15,438,1432598400"; d="scan'208,217";a="555395142" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 09 Jul 2015 09:02:35 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6992ZS1009170; Thu, 9 Jul 2015 09:02:35 GMT To: stephane.litkowski@orange.com, "l3sm@ietf.org" References: <559A62ED.9060001@cisco.com> <24850_1436432245_559E3775_24850_1614_13_9E32478DFA9976438E7A22F69B08FF921669DB9A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Benoit Claise Message-ID: <559E38AB.3090604@cisco.com> Date: Thu, 9 Jul 2015 11:02:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <24850_1436432245_559E3775_24850_1614_13_9E32478DFA9976438E7A22F69B08FF921669DB9A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------050504060401040009090201" Archived-At: Subject: Re: [L3sm] draft-ietf-l3sm-l3vpn-service-model feedback X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 09:02:40 -0000 This is a multi-part message in MIME format. --------------050504060401040009090201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Stephane, > Hi Benoit, > > Currently we know that the model maps correctly to a BGP PE-Based VPN, > but not sure that it fills any VPN scenario like (CE to CE … ). > Yes, I recall that. That makes sense. > > When we discussed at the beginning, we agreed to start with this VPN > model and then see how it maps to others. > We might want to keep this point in our to do list. Regards, Benoit > > Best Regards, > > Stephane > > *From:*L3sm [mailto:l3sm-bounces@ietf.org] *On Behalf Of *Benoit Claise > *Sent:* Monday, July 06, 2015 13:14 > *To:* l3sm@ietf.org > *Subject:* [L3sm] draft-ietf-l3sm-l3vpn-service-model feedback > > Dear authors, > > Thanks for posting draft-ietf-l3sm-l3vpn-service-model. > From the abstract, I see: > > This document defines a YANG data model that can be used to deliver a > Layer 3 Provider Provisioned VPN service. The document is limited to > the BGP PE-based VPNs as described inRFC4110 andRFC4364 . > > I wonder: What is specific to BGP PE-based VPNs in this YANG model? > From the L3SM charter, "Instead it contains the characteristics of the > service, as discussed between the operators and their customers." > "Do you want a BGP PE-based VPNs", is this a typical question that > operators ask to the customers? > > Regards, Benoit > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. --------------050504060401040009090201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Stephane,

Hi Benoit,

 

Currently we know that the model maps correctly to a BGP PE-Based VPN, but not sure that it fills any VPN scenario like (CE to CE … ).

Yes, I recall that. That makes sense.

When we discussed at the beginning, we agreed to start with this VPN model and then see how it maps to others.

We might want to keep this point in our to do list.

Regards, Benoit

 

Best Regards,

 

Stephane

 

 

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Monday, July 06, 2015 13:14
To: l3sm@ietf.org
Subject: [L3sm] draft-ietf-l3sm-l3vpn-service-model feedback

 

Dear authors,

Thanks for posting draft-ietf-l3sm-l3vpn-service-model.
From the abstract, I see:

This document defines a YANG data model that can be used to deliver a
Layer 3 Provider Provisioned VPN service.  The document is limited to
the BGP PE-based VPNs as described in RFC4110 and RFC4364.

I wonder:  What is specific to BGP PE-based VPNs in this YANG model?
From the L3SM charter, "Instead it contains the characteristics of the service, as discussed between the operators and their customers."
"Do you want a BGP PE-based VPNs", is this a typical question that operators ask to the customers?

Regards, Benoit

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--------------050504060401040009090201-- From nobody Wed Jul 15 21:56:15 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181331B3096 for ; Wed, 15 Jul 2015 21:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 VNztAZtBn93W for ; Wed, 15 Jul 2015 21:56:12 -0700 (PDT) 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 B11151A21BE for ; Wed, 15 Jul 2015 21:56:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVG14992; Thu, 16 Jul 2015 04:56:10 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Jul 2015 05:56:09 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Thu, 16 Jul 2015 12:56:05 +0800 From: Qin Wu To: "l3sm@ietf.org" Thread-Topic: IETF93 L3SM WG Agenda Thread-Index: AdC/g7epGeK1YoAgQqG45CVWn393BA== Date: Thu, 16 Jul 2015 04:56:04 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA847C9047nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "adrian@olddog.co.uk" Subject: [L3sm] IETF93 L3SM WG Agenda X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 04:56:14 -0000 --_000_B8F9A780D330094D99AF023C5877DABA847C9047nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks: We have posted a preliminary agenda for our upcoming WG meeting in Prague h= ere: https://datatracker.ietf.org/meeting/93/agenda/l3sm If you are a presenter please make sure you send Adrian & I slides no later= than 7/20 so that we have time to review prior to the meeting. If others have anything that you would like to discuss at IETF 93, please a= lso send a request to us. Qin/Adrian --_000_B8F9A780D330094D99AF023C5877DABA847C9047nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks:<= /o:p>

 <= /o:p>

We have posted a preliminary agenda for = our upcoming WG meeting in Prague here:

 <= /o:p>

https://datatracker.iet= f.org/meeting/93/agenda/l3sm

 <= /o:p>

If you are a= presenter please make sure you send Adrian & I slides no later than 7/20 so that we have time to review prior to the meeting.

If others have anything that you would= like to discuss at IETF 93, please also send a request to us.

 <= /o:p>

Qin/Adrian

--_000_B8F9A780D330094D99AF023C5877DABA847C9047nkgeml501mbschi_-- From nobody Thu Jul 16 17:59:15 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776211B2CC6 for ; Thu, 16 Jul 2015 17:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XPt43TWKPpgU for ; Thu, 16 Jul 2015 17:59:13 -0700 (PDT) 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 BAC9D1B2CC3 for ; Thu, 16 Jul 2015 17:59:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVH03613; Fri, 17 Jul 2015 00:59:11 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 17 Jul 2015 01:59:10 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Fri, 17 Jul 2015 08:59:03 +0800 From: Qin Wu To: "l3sm@ietf.org" Thread-Topic: Needed for Wednesday L3SM meeting Thread-Index: AdDAK8W3c4e+fk3iR+WBfOjCUOwCuQ== Date: Fri, 17 Jul 2015 00:59:03 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA847CD4FBnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "adrian@olddog.co.uk" Subject: [L3sm] Needed for Wednesday L3SM meeting X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 00:59:14 -0000 --_000_B8F9A780D330094D99AF023C5877DABA847CD4FBnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We are looking for one or two note-takers, and a jabber scribe, for l3sm se= ssion, please volunteer and Send Adrian and I a note, your contribution to = make a successful meeting is appreciated. -Qin/Adrian --_000_B8F9A780D330094D99AF023C5877DABA847CD4FBnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are looking for one or tw= o note-takers, and a jabber scribe, for l3sm session, please volunteer and = Send Adrian and I a note, your contribution to make a successful meeting is= appreciated.

 

-Qin/Adrian

 

--_000_B8F9A780D330094D99AF023C5877DABA847CD4FBnkgeml501mbschi_-- From nobody Mon Jul 20 07:27:53 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DC31A88B8 for ; Mon, 20 Jul 2015 07:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 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_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kkqT7ACysk_a for ; Mon, 20 Jul 2015 07:27:50 -0700 (PDT) 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 532371A8895 for ; Mon, 20 Jul 2015 07:27:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYY74561; Mon, 20 Jul 2015 14:27:49 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jul 2015 15:27:47 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Mon, 20 Jul 2015 22:27:44 +0800 From: Qin Wu To: "l3sm@ietf.org" Thread-Topic: L3SM Meeting at IETF93 Thread-Index: AdDC+DyqkaJySUgJRem4B+q73+kCxg== Date: Mon, 20 Jul 2015 14:27:43 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.77.138] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA847CF5C4nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "adrian@olddog.co.uk" Subject: [L3sm] L3SM Meeting at IETF93 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:27:52 -0000 --_000_B8F9A780D330094D99AF023C5877DABA847CF5C4nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks: We have upload meeting materials for our upcoming WG meeting in Prague belo= w: https://datatracker.ietf.org/meeting/93/materials.html For your reminder, the meeting will begin on Wednesday, July 22, 15:50-17:2= 0, The meeting Room is Karlin I/II. Qin/Adrian --_000_B8F9A780D330094D99AF023C5877DABA847CF5C4nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks:<= /o:p>

 <= /o:p>

We have uplo= ad meeting materials for our upcoming WG meeting in Prague below:

 <= /o:p>

https://datatracker.ietf.org/mee= ting/93/materials.html

 = 

For your reminder, the meeting=
 will begin on Wednesday, July 22, 15:50-17:20,

 <= /o:p>

The meeting = Room is Karlin I/II.

 

Qin/Adrian

--_000_B8F9A780D330094D99AF023C5877DABA847CF5C4nkgeml501mbschi_-- From nobody Mon Jul 20 19:26:31 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C521ACD52 for ; Mon, 20 Jul 2015 19:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.19 X-Spam-Level: * X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_35=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 hzNnc4Nrh2Cy for ; Mon, 20 Jul 2015 19:26:28 -0700 (PDT) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 5706C1AC425 for ; Mon, 20 Jul 2015 19:26:27 -0700 (PDT) Received: from ctbriwangaij (unknown [219.142.69.76]) by app1 (Coremail) with SMTP id Z0GX06BrWAERja1VhjB7Cw==.59002S2; Tue, 21 Jul 2015 08:06:56 +0800 (CST) From: "Aijun Wang" To: "'Qin Wu'" , References: In-Reply-To: Date: Tue, 21 Jul 2015 10:25:45 +0800 Message-ID: <012101d0c35c$955b2390$c0116ab0$@org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0122_01D0C39F.A37E6390" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDC+DyqkaJySUgJRem4B+q73+kCxgAXr0cQ Content-Language: zh-cn X-CM-TRANSID: Z0GX06BrWAERja1VhjB7Cw==.59002S2 X-Coremail-Antispam: 1U3129KBjvJXoW7KF18uryUXrW5tFWrtw48tFb_yoW8ZrWfpF W5GryvywsFqry7CFn7ZF18JFWFv3WrCFW5ArnxJFWUA345CFyFvw1Iqw1YvayxCrWktr10 vrWqvr13uw15XFJanT9S1TB71UUUUU7v73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjQlb7 Iv0xC_Jr1l5I8CrVAYj202j2C_Xr0_Wr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG 04xIwI0_Jr0_Gr1l5I8CrVCF0I0E4I0vr24lb4IE77IF4wAFF20E14v26r1j6r4UM7C26x Cjj4IEI4klw4CSwwAFxVCaYxvI4VCIwcAKzIAtMcIj6x8ErcxFaVAv8VW8AwC2zVAF1VAY 17CE14v26r126r1D0xZFpf9x0JUdManUUUUU= Archived-At: Cc: adrian@olddog.co.uk, 'Chongfeng Xie' Subject: Re: [L3sm] L3SM Meeting at IETF93 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 02:26:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0122_01D0C39F.A37E6390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, all: I read the slides that posted at https://www.ietf.org/proceedings/93/slides/slides-93-l3sm-1.pdf, and had some considerations for the design of l3vpn service model and the work for the L3SM WG: 1) Can we define some general and reusable service model that be referenced by l3vpn service? For example, the cloud-access, multicast-service, vpn policy and qos. The reason for doing in this way are as followings: a) If we can separate the service model into several components, it is also easier to map them to the device configuration model. b) As the authors pointed out in the slides, the vpn policy is some complex, so it is better to extract this part from the main service model. c) cloud-access, multicast-service are all value added services, they should be considered separately. 2) It seems not necessary to introduce the new concept of native VPN. And I think if we do, such design may confuse the customer because this concept overlaps with the vpn topology(any to any, hub&spoke, hub&spoke disjoint). 3) From the viewpoint of the service provider, the service unit should be site, not the LAN segments within each site. If the customer want to set the communication policy among different LAN segments, they should do this themselves, based on the service policy provided by service provider. Such design can simplify significantly the design of l3vpn service model. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Intelligent Network Product Line From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Monday, July 20, 2015 10:28 PM To: l3sm@ietf.org Cc: adrian@olddog.co.uk Subject: [L3sm] L3SM Meeting at IETF93 Folks: We have upload meeting materials for our upcoming WG meeting in Prague below: https://datatracker.ietf.org/meeting/93/materials.html For your reminder, the meeting will begin on Wednesday, July 22, 15:50-17:20, The meeting Room is Karlin I/II. Qin/Adrian ------=_NextPart_000_0122_01D0C39F.A37E6390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all:

 

I read the slides that posted  at = https://www.ietf.org/proceedings/93/slides/slides-93-l3sm-1.pdf, and = had some considerations for the design of l3vpn service model and the = work for the L3SM WG:

1)  Can we define some general and reusable service model that = be referenced by l3vpn service? For example, the cloud-access, = multicast-service, vpn policy and qos. The reason for doing in this way = are as followings:

a)  If we can separate the service model into several = components, it is also easier to map them to the device configuration = model.

b)  As the authors pointed out in the slides, the vpn policy is = some complex, so it is better to extract this part from the main service = model.

       c)  cloud-access, = multicast-service are all value added services, they should be = considered separately.

 

2) It seems not necessary to introduce the new concept of native VPN. = And I think if we do, such design may confuse the customer because this = concept overlaps with the vpn topology(any to any, hub&spoke, = hub&spoke disjoint).

 

3) From the viewpoint of the service provider, the service unit = should be site, not the LAN segments within each site. If the customer = want to set the communication policy among different LAN segments, they = should do this themselves, based on the service policy provided by = service provider. Such design can simplify significantly the design = of  l3vpn service model.

 

 

Aijun Wang

 

China Telecom Corporation Limited Beijing Res= earch Institute 

Intelligent Network Product Line

 

 

 

From:= L3sm = [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin = Wu
Sent: Monday, July 20, 2015 10:28 PM
To: = l3sm@ietf.org
Cc: adrian@olddog.co.uk
Subject: = [L3sm] L3SM Meeting at IETF93

 

Folks:

 

We have upload meeting materials for our upcoming WG meeting in Prague = below:

 

https://d= atatracker.ietf.org/meeting/93/materials.html

 = 

For your reminder, the meeting will begin on Wednesday, July 22, =
15:50-17:20,

 

The meeting Room is Karlin I/II.

 

Qin/Adrian<= o:p>

------=_NextPart_000_0122_01D0C39F.A37E6390-- From nobody Tue Jul 21 08:00:16 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD1B1B2EA9 for ; Tue, 21 Jul 2015 08:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 AsWL0lfFT0p1 for ; Tue, 21 Jul 2015 08:00:13 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 5C92B1B2EB6 for ; Tue, 21 Jul 2015 08:00:13 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so44168267wic.0 for ; Tue, 21 Jul 2015 08:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=pu9kYLzyqd8nH+0yDofuUUPXUcfMPharh8bzn6IfygA=; b=XOOqSz2unNWgMli2x6z/JMc23eQIYnP0F0Lz+4GtMUki5o0JnB3Gs0deGHWLIi2kEj w/kVbYNMZnO6RlQMSJ7PNzVR92bRndNp9xfZL5tSVGs/rgFqnhTfQlQwSFwYeZw1rbvq f4IcuopYITtEpAqV/ak6BNSzfzUQIYeBgOOcaHGXlB7uMbOQ/EXnt6fdoWSCbo45aHdS XqKbnh+kvOMtmbEaSLqOCPoUf1osWysq1wbNzq7RG9Udb44kZRxLEXfOg4CXrrNzgBoy dSx7KkJvT7EH9ud78bbKh7TAD/FCuBX4xCk/BZvdB3I5Fmws3ZnFjVyMXAUZJCG1OQfc JDow== X-Received: by 10.180.74.132 with SMTP id t4mr34128737wiv.55.1437490812011; Tue, 21 Jul 2015 08:00:12 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:c80:953:3006:3eff? ([2001:67c:370:176:c80:953:3006:3eff]) by smtp.gmail.com with ESMTPSA id v20sm37456670wjw.17.2015.07.21.08.00.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Jul 2015 08:00:10 -0700 (PDT) From: Kireeti Kompella Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2015 17:00:10 +0200 Message-Id: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> To: l3sm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Cc: Kireeti Kompella Subject: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:00:15 -0000 Hi, Very happy to see this WG, and to see the l3vpn _service_ YANG model. = Wish I=E2=80=99d been paying attention earlier :) Some comments: 1) At a high level, I would like to see services as compositions = (mash-ups) of service elements. This is a generalization of the = comments that Aijun made. Here=E2=80=99s why. As we (either the IETF = or other bodies, or SPs on their own) define other services, it would be = very convenient to be able to reuse these service elements. Example: = suppose an L2SM module is needed. Elements to consider: availability QoS access-control-list OAM (liveness) customer-specific-info I don=E2=80=99t know how one defines a mash-up of modules in YANG, maybe = as simple as =E2=80=9Cimport=E2=80=9D. (Note: this has nothing to do with service chaining!) 2) I think it would be convenient to have certain stanzas directly under = vpn-svc, and again under vpn-svc/sites =E2=80=94 essentially, a default = for the entire service, and overrides for each site. 3) not sure why =E2=80=9Cbfd=E2=80=9D is under =E2=80=9Crouting = protocols=E2=80=9D. You may be better off having a stanza called = OAM/Hello/liveness, where one can choose bfd among other mechanisms. 4) might be hard, but define defaults for as many YANG leaves as = possible. 5) =46rom comments on the mailing list, it seems OTT VPNs = (customer-provisioned) are out of scope; however, doing such a model = will help clarify common elements, and might help organize the L3VPN SM = better. 6) Philosophical comment: should scrutinize service models to ensure = we=E2=80=99re making them as abstract as possible. E.g., I=E2=80=99m = very happy that RDs and RTs are not in the SM. Question: what else can = be trimmed? Finally, should YANG models (in general) have guidance as to where to = place augments? The theory is, you start with an SM (or data model in = general) that everyone agrees on =E2=80=94 lowest common denominator. = Then, as people augment a DM, if a certain augmentation appears in = several such models, that might be promoted to being a part of the = standard DM. Or maybe I=E2=80=99m a dreamer :) Kireeti. From nobody Tue Jul 21 08:25:50 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF171A89E9 for ; Tue, 21 Jul 2015 08:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 18oEO6C-V-XE for ; Tue, 21 Jul 2015 08:25:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EBF81A89B0 for ; Tue, 21 Jul 2015 08:23:50 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 30F0F22CB26; Tue, 21 Jul 2015 17:23:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 110A535C06C; Tue, 21 Jul 2015 17:23:49 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0235.001; Tue, 21 Jul 2015 17:23:48 +0200 From: To: Kireeti Kompella , "l3sm@ietf.org" Thread-Topic: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHQw8X3K3YLZClNO0qpeZYxRBC/cp3mCTSQ Date: Tue, 21 Jul 2015 15:23:47 +0000 Message-ID: <1882_1437492229_55AE6405_1882_151_1_9E32478DFA9976438E7A22F69B08FF92166A3399@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> In-Reply-To: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.16.85415 Archived-At: Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 15:25:50 -0000 SGkgS2lyZWV0aSwNCg0KVGhhbmtzIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzIChhcyB1c3Vh bCA7KSApLg0KDQpTZWUgaW5saW5lIGNvbW1lbnRzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBMM3NtIFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgS2lyZWV0aSBLb21wZWxsYQ0KU2VudDogVHVlc2RheSwgSnVseSAyMSwgMjAxNSAxNzowMA0K VG86IGwzc21AaWV0Zi5vcmcNCkNjOiBLaXJlZXRpIEtvbXBlbGxhDQpTdWJqZWN0OiBbTDNzbV0g Q29tbWVudHMgb24gZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwNCg0KSGksDQoN ClZlcnkgaGFwcHkgdG8gc2VlIHRoaXMgV0csIGFuZCB0byBzZWUgdGhlIGwzdnBuIF9zZXJ2aWNl XyBZQU5HIG1vZGVsLiAgV2lzaCBJ4oCZZCBiZWVuIHBheWluZyBhdHRlbnRpb24gZWFybGllciA6 KQ0KDQpTb21lIGNvbW1lbnRzOg0KDQoxKSBBdCBhIGhpZ2ggbGV2ZWwsIEkgd291bGQgbGlrZSB0 byBzZWUgc2VydmljZXMgYXMgY29tcG9zaXRpb25zIChtYXNoLXVwcykgb2Ygc2VydmljZSBlbGVt ZW50cy4gIFRoaXMgaXMgYSBnZW5lcmFsaXphdGlvbiBvZiB0aGUgY29tbWVudHMgdGhhdCBBaWp1 biBtYWRlLiAgSGVyZeKAmXMgd2h5LiAgQXMgd2UgKGVpdGhlciB0aGUgSUVURiBvciBvdGhlciBi b2RpZXMsIG9yIFNQcyBvbiB0aGVpciBvd24pIGRlZmluZSBvdGhlciBzZXJ2aWNlcywgaXQgd291 bGQgYmUgdmVyeSBjb252ZW5pZW50IHRvIGJlIGFibGUgdG8gcmV1c2UgdGhlc2Ugc2VydmljZSBl bGVtZW50cy4gIEV4YW1wbGU6IHN1cHBvc2UgYW4gTDJTTSBtb2R1bGUgaXMgbmVlZGVkLg0KDQpF bGVtZW50cyB0byBjb25zaWRlcjoNCglhdmFpbGFiaWxpdHkNCglRb1MNCglhY2Nlc3MtY29udHJv bC1saXN0DQoJT0FNIChsaXZlbmVzcykNCgljdXN0b21lci1zcGVjaWZpYy1pbmZvDQoNCkkgZG9u 4oCZdCBrbm93IGhvdyBvbmUgZGVmaW5lcyBhIG1hc2gtdXAgb2YgbW9kdWxlcyBpbiBZQU5HLCBt YXliZSBhcyBzaW1wbGUgYXMg4oCcaW1wb3J04oCdLg0KDQpbU0xJXSBNb2R1bGFyaXphdGlvbiBp cyBhIHJlYWxseSBnb29kIHBvaW50LCBiZWZvcmUgZ29pbmcgdG8gc3RhcnQgdGhlIHdvcmssIEkg d291bGQgbGlrZSB0byBlbnN1cmUgdGhhdCBhbGwgY29tcG9uZW50cyBhcmUgdGhlcmUgc28gd2Ug Y2FuIHRoaW5rIHRoZSBnb29kIHdheSB0byBzcGxpdCBlbGVtZW50cy4gRm9yIHN1cmUgZ3JvdXBp bmdzIGNhbiBiZSBjcmVhdGVkIGFuZCBiZWluZyByZXVzZWQuDQoNCg0KKE5vdGU6IHRoaXMgaGFz IG5vdGhpbmcgdG8gZG8gd2l0aCBzZXJ2aWNlIGNoYWluaW5nISkNCg0KMikgSSB0aGluayBpdCB3 b3VsZCBiZSBjb252ZW5pZW50IHRvIGhhdmUgY2VydGFpbiBzdGFuemFzIGRpcmVjdGx5IHVuZGVy IHZwbi1zdmMsIGFuZCBhZ2FpbiB1bmRlciB2cG4tc3ZjL3NpdGVzIOKAlCBlc3NlbnRpYWxseSwg YSBkZWZhdWx0IGZvciB0aGUgZW50aXJlIHNlcnZpY2UsIGFuZCBvdmVycmlkZXMgZm9yIGVhY2gg c2l0ZS4NCltTTEldIENvdWxkIHlvdSBlbGFib3JhdGUgb24gd2hpY2ggc3RhbnphIHlvdSB3b3Vs ZCBsaWtlIHRvIHNlZSA/DQoNCjMpIG5vdCBzdXJlIHdoeSDigJxiZmTigJ0gaXMgdW5kZXIg4oCc cm91dGluZyBwcm90b2NvbHPigJ0uICBZb3UgbWF5IGJlIGJldHRlciBvZmYgaGF2aW5nIGEgc3Rh bnphIGNhbGxlZCBPQU0vSGVsbG8vbGl2ZW5lc3MsIHdoZXJlIG9uZSBjYW4gY2hvb3NlIGJmZCBh bW9uZyBvdGhlciBtZWNoYW5pc21zLg0KW1NMSV0gU29tZSBzaG9ydGN1dHMgaGF2ZSBiZWVuIHRh a2VuIChsaWtlIHZycnAgYXMgcm91dGluZyBwcm90b2NvbCA6KSApLCB0aGlzIGNhbiBiZSBmaXhl ZC4NCg0KNCkgbWlnaHQgYmUgaGFyZCwgYnV0IGRlZmluZSBkZWZhdWx0cyBmb3IgYXMgbWFueSBZ QU5HIGxlYXZlcyBhcyBwb3NzaWJsZS4NCltTTEldIE5vdCBzdXJlIHRoaXMgd291bGQgYmUgZG9h YmxlLCBidXQgSSB3aWxsIGhhdmUgYSBsb29rLiBEZWZhdWx0cyBtYXkgZGlmZmVyIGZvciBlYWNo IHNlcnZpY2UgcHJvdmlkZXJzIC4uLg0KDQo1KSBGcm9tIGNvbW1lbnRzIG9uIHRoZSBtYWlsaW5n IGxpc3QsIGl0IHNlZW1zIE9UVCBWUE5zIChjdXN0b21lci1wcm92aXNpb25lZCkgYXJlIG91dCBv ZiBzY29wZTsgaG93ZXZlciwgZG9pbmcgc3VjaCBhIG1vZGVsIHdpbGwgaGVscCBjbGFyaWZ5IGNv bW1vbiBlbGVtZW50cywgYW5kIG1pZ2h0IGhlbHAgb3JnYW5pemUgdGhlIEwzVlBOIFNNIGJldHRl ci4NCltTTEldIEZvciBub3cgeWVzLCBidXQgdGhlIGlkZWEgaXMgdG8gc2VlIGlmIHdlIGNhbiBt YWtlIHRoZSBtb2RlbCBnZW5lcmljIGVub3VnaCB0byBmaXQgYWxzbyBjdXN0b21lciBwcm92aXNp b25lZCBWUE5zLg0KDQo2KSBQaGlsb3NvcGhpY2FsIGNvbW1lbnQ6IHNob3VsZCBzY3J1dGluaXpl IHNlcnZpY2UgbW9kZWxzIHRvIGVuc3VyZSB3ZeKAmXJlIG1ha2luZyB0aGVtIGFzIGFic3RyYWN0 IGFzIHBvc3NpYmxlLiAgRS5nLiwgSeKAmW0gdmVyeSBoYXBweSB0aGF0IFJEcyBhbmQgUlRzIGFy ZSBub3QgaW4gdGhlIFNNLiAgUXVlc3Rpb246IHdoYXQgZWxzZSBjYW4gYmUgdHJpbW1lZD8NCltT TEldIE11bHRpcGxlIGV5ZXMgYXJlIHJlcXVpcmVkIGZvciB0aGF0IHB1cnBvc2UsIHdlIGFyZSBj b250aW51b3VzbHkgdHJ5aW5nIHRvIHRyaW0gYW5kIG1ha2UgbW9yZSBhYnN0cmFjdGlvbiBidXQg YW55IG5ldyBpZGVhIGlzIGdvb2QgdG8gdGFrZS4gSWRlYSBsaXN0IGlzIGJlY29taW5nIGVtcHR5 IG9uIG91ciBzaWRlIC4uLiBzbyBuZXcgZXllcyBhcmUgd2VsY29tZS4NCg0KRmluYWxseSwgc2hv dWxkIFlBTkcgbW9kZWxzIChpbiBnZW5lcmFsKSBoYXZlIGd1aWRhbmNlIGFzIHRvIHdoZXJlIHRv IHBsYWNlIGF1Z21lbnRzPyAgVGhlIHRoZW9yeSBpcywgeW91IHN0YXJ0IHdpdGggYW4gU00gKG9y IGRhdGEgbW9kZWwgaW4gZ2VuZXJhbCkgdGhhdCBldmVyeW9uZSBhZ3JlZXMgb24g4oCUIGxvd2Vz dCBjb21tb24gZGVub21pbmF0b3IuICBUaGVuLCBhcyBwZW9wbGUgYXVnbWVudCBhIERNLCBpZiBh IGNlcnRhaW4gYXVnbWVudGF0aW9uIGFwcGVhcnMgaW4gc2V2ZXJhbCBzdWNoIG1vZGVscywgdGhh dCBtaWdodCBiZSBwcm9tb3RlZCB0byBiZWluZyBhIHBhcnQgb2YgdGhlIHN0YW5kYXJkIERNLiAg T3IgbWF5YmUgSeKAmW0gYSBkcmVhbWVyIDopDQoNCktpcmVldGkuDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMM3NtIG1haWxpbmcgbGlzdA0KTDNz bUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl dWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Tue Jul 21 09:16:24 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F20B1B2F74 for ; Tue, 21 Jul 2015 09:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 GInOY35XI0ZQ for ; Tue, 21 Jul 2015 09:16:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D261A8AAB for ; Tue, 21 Jul 2015 09:16:19 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id CD974C09A6; Tue, 21 Jul 2015 18:16:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 9D0A315807F; Tue, 21 Jul 2015 18:16:17 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Tue, 21 Jul 2015 18:16:17 +0200 From: To: Aijun Wang , 'Qin Wu' , "l3sm@ietf.org" Thread-Topic: [L3sm] L3SM Meeting at IETF93 Thread-Index: AdDC+DyqkaJySUgJRem4B+q73+kCxgAXr0cQAB5B00A= Date: Tue, 21 Jul 2015 16:16:17 +0000 Message-ID: <18776_1437495377_55AE7051_18776_2315_1_9E32478DFA9976438E7A22F69B08FF92166A344B@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <012101d0c35c$955b2390$c0116ab0$@org.cn> In-Reply-To: <012101d0c35c$955b2390$c0116ab0$@org.cn> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166A344BOPEXCLILMA4corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.21.153615 Archived-At: Cc: "adrian@olddog.co.uk" , 'Chongfeng Xie' Subject: Re: [L3sm] L3SM Meeting at IETF93 X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 16:16:23 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92166A344BOPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Thanks for your comment, pls see inline From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang Sent: Tuesday, July 21, 2015 04:26 To: 'Qin Wu'; l3sm@ietf.org Cc: adrian@olddog.co.uk; 'Chongfeng Xie' Subject: Re: [L3sm] L3SM Meeting at IETF93 Hi, all: I read the slides that posted at https://www.ietf.org/proceedings/93/slide= s/slides-93-l3sm-1.pdf, and had some considerations for the design of l3vpn= service model and the work for the L3SM WG: 1) Can we define some general and reusable service model that be reference= d by l3vpn service? For example, the cloud-access, multicast-service, vpn p= olicy and qos. The reason for doing in this way are as followings: a) If we can separate the service model into several components, it is als= o easier to map them to the device configuration model. b) As the authors pointed out in the slides, the vpn policy is some comple= x, so it is better to extract this part from the main service model. c) cloud-access, multicast-service are all value added services, th= ey should be considered separately. [SLI] Modularization using groupings is necessary for sure. We will need to= discuss what is useful to put as grouping, and what is necessary to put at= top level of the hierarchy. 2) It seems not necessary to introduce the new concept of native VPN. And I= think if we do, such design may confuse the customer because this concept = overlaps with the vpn topology(any to any, hub&spoke, hub&spoke disjoint). [SLI] It does not overlap, native VPN marks the belonging of a site to a pa= rticular VPN. 3) From the viewpoint of the service provider, the service unit should be s= ite, not the LAN segments within each site. If the customer want to set the= communication policy among different LAN segments, they should do this the= mselves, based on the service policy provided by service provider. Such des= ign can simplify significantly the design of l3vpn service model. [SLI] A lot of customers are using LAN segmentation (example VoIP LAN, Data= LAN ...). What do you mean by "based on the service policy provided by ser= vice provider" ? I definitely agree that not having the LAN segmentation would clearly simpl= ify but I think we cannot avoid it. Aijun Wang China Telecom Corporation Limited Beijing Research Institute Intelligent Network Product Line From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu Sent: Monday, July 20, 2015 10:28 PM To: l3sm@ietf.org Cc: adrian@olddog.co.uk Subject: [L3sm] L3SM Meeting at IETF93 Folks: We have upload meeting materials for our upcoming WG meeting in Prague belo= w: https://datatracker.ietf.org/meeting/93/materials.html For your reminder, the meeting will begin on Wednesday, July 22, 15:50-17:2= 0, The meeting Room is Karlin I/II. Qin/Adrian ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF92166A344BOPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Thanks for your comment, = pls see inline

 <= /p>

From: L3sm [ma= ilto:l3sm-bounces@ietf.org] On Behalf Of Aijun Wang
Sent: Tuesday, July 21, 2015 04:26
To: 'Qin Wu'; l3sm@ietf.org
Cc: adrian@olddog.co.uk; 'Chongfeng Xie'
Subject: Re: [L3sm] L3SM Meeting at IETF93

 

https://www.ietf.org/proceedings/93/slides/slides-93-l3sm-1.pdf, and h= ad some considerations for the design of l3vpn service model and the work f= or the L3SM WG:

a)  If we can separate the service mod= el into several components, it is also easier to map them to the device configuration model.

b)  As the authors pointed out in the = slides, the vpn policy is some complex, so it is better to extract this part from the main service model.

based on the service policy provided by service provider” ?

From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Monday, July 20, 2015 10:28 PM
To: l3sm@ietf.org
Cc: adrian@olddog.co.uk Subject: [L3sm] L3SM Meeting at IETF93

&nbs= p;

= Folks:

=  

= We have upload meeting materials for our upcoming WG meeting in Prague belo= w:

=  

https://datatracker.= ietf.org/meeting/93/materials.html

 <= /o:p>

For your reminder,=
 the meeting will begin on Wednesday, July 22, 15:50-17:20,

=  

= The meeting Room is Karlin I/II.

 

Qin/Adrian

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_9E32478DFA9976438E7A22F69B08FF92166A344BOPEXCLILMA4corp_-- From nobody Wed Jul 22 05:28:11 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5B41B3197 for ; Wed, 22 Jul 2015 05:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham 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 So3E1rGQNkLx for ; Wed, 22 Jul 2015 05:28:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD2F1B30FE for ; Wed, 22 Jul 2015 05:28:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t6MCS4Tr005982; Wed, 22 Jul 2015 13:28:04 +0100 Received: from 950129200 (dhcp-b176.meeting.ietf.org [31.133.177.118]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t6MCS37r005960 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2015 13:28:04 +0100 From: "Adrian Farrel" To: "'Kireeti Kompella'" , References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> In-Reply-To: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> Date: Wed, 22 Jul 2015 13:28:03 +0100 Message-ID: <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwkYdepbJsEKHhpNfOeVRJn/+ynJ0nzb1g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-8.0.0.1202-21696.004 X-TM-AS-Result: No--11.996-10.0-31-10 X-imss-scan-details: No--11.996-10.0-31-10 X-TMASE-MatchedRID: hls5oAVArl84HKI/yaqRm/nCl+sgkNd7SZHpECn4g4tXPwnnY5XL5C7s reQJNnc7Pzin/03CLtPOgXE6r4gNc5IOhgOZiPMsBEfU2vugRF3SL+EVfOJR08CIs25kwV/ZAmM sMzPNmfMM556OdJ9dfvNDzsAQllGw6MiQmVdPpgiPYUYzX2Xjl6KaxHqGRwkC+Cckfm+bb6BiYT V2JsPIeW4tpK8fb7GNwEELKqiE+8CW+cf6nEkoShNEPNwNrw/rQKuv8uQBDjo76rqmQGSwT7No8 vBZ/z47bbZmB9bk47NinADt1JP3D8fEYAf1qh/lngIgpj8eDcByZ8zcONpAscRB0bsfrpPIfiAq rjYtFiRIipBsrsRP97R5vvrH39cIilG+LMP0pTTmm9xe3qr6DX7cGd19dSFd Archived-At: Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:28:10 -0000 Hello Kireeti, Welcome to the party. > 1) At a high level, I would like to see services as compositions = (mash-ups) of > service elements. This is a generalization of the comments that Aijun = made. > Here=E2=80=99s why. As we (either the IETF or other bodies, or SPs on = their own) define > other services, it would be very convenient to be able to reuse these = service > elements. I completely take your point, but... When we started the L3SM work we were not certain (and some remain = uncertain) that the problem could be addressed even for one of our most = simple services (the L3VPN) let alone for a more generic concept of = services. Therefore, the WG was explicitly tasked (read the charter) to = work with focus and attention on L3VPN only and to exclude consideration = of other services. That, in itself, does not predicate against modularisation, but it does = make it hard to consider which modules to have (since some aspects of = modularisation must surely consider the other services that might use = the modules). Therefore, my expectation of progress is... - Continue to progress L3SM towards completion - Publish an RFC (if it can be agreed and done) - Start work on another similar service model (e.g. L2SM) - If there is energy - If the IESG gives us permission - Look for commonalities and modularisations - If they exist it may be necessary to revise L3SM So, from some aspects this does not look optimal. Perhaps you could have = made this comment during chartering.=20 But from another perspective it enables some initial progress in a new = subject space that the IETF has not previously attempted. If it is = successful we can dig deeper. Overall (setting aside the fact that we are anyway constrained by our = charter) I have a fear of ocean-boiling. But some early, precautionary = modularisation is not going to be a problem so long as we don't spend = too long arguing about exactly what to modularise. Adrian From nobody Wed Jul 22 05:39:53 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B95E1B32D1 for ; Wed, 22 Jul 2015 05:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 H5MDGwpCx0hB for ; Wed, 22 Jul 2015 05:39:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020F71A020A for ; Wed, 22 Jul 2015 05:39:50 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 7664319041B; Wed, 22 Jul 2015 14:39:48 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 58F5018005C; Wed, 22 Jul 2015 14:39:48 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0235.001; Wed, 22 Jul 2015 14:39:47 +0200 From: To: "adrian@olddog.co.uk" , 'Kireeti Kompella' , "l3sm@ietf.org" Thread-Topic: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHQw8X3K3YLZClNO0qpeZYxRBC/cp3nSqKAgAAkJaA= Date: Wed, 22 Jul 2015 12:39:46 +0000 Message-ID: <10361_1437568788_55AF8F14_10361_7312_1_9E32478DFA9976438E7A22F69B08FF92166A3977@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk> In-Reply-To: <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.22.111517 Archived-At: Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:39:52 -0000 PiBCdXQgc29tZSBlYXJseSwgcHJlY2F1dGlvbmFyeSBtb2R1bGFyaXNhdGlvbiBpcyBub3QgZ29p bmcgdG8gYmUgYSBwcm9ibGVtIHNvIGxvbmcgYXMgd2UgZG9uJ3Qgc3BlbmQgdG9vIGxvbmcgYXJn dWluZyBhYm91dCBleGFjdGx5IHdoYXQgdG8gbW9kdWxhcmlzZS4NCg0KRnVsbHkgYWdyZWUgLi4u LCBzb21lIHNlY3Rpb25zIEtpcmVldGkgd2FzIG1lbnRpb25pbmcgYXJlIGV2aWRlbnQgdG8gYmUg YXMgYSByZXVzYWJsZSBjb21wb25lbnQgc28gd2UgY2FuIGRvIGl0IG5vdywgZm9yIG1vcmUgY29t cGxleCB0aGluZ3MsIGxldCdzIHRoaW5rIGFib3V0IGl0IGFmdGVyIHRoZSBtb2R1bGUgaXMgKGFs bW9zdCkgZmluaXNoZWQuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEwz c20gW21haWx0bzpsM3NtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFy cmVsDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjIsIDIwMTUgMTQ6MjgNClRvOiAnS2lyZWV0aSBL b21wZWxsYSc7IGwzc21AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTDNzbV0gQ29tbWVudHMgb24g ZHJhZnQtaWV0Zi1sM3NtLWwzdnBuLXNlcnZpY2UtbW9kZWwNCg0KSGVsbG8gS2lyZWV0aSwNCg0K V2VsY29tZSB0byB0aGUgcGFydHkuDQoNCj4gMSkgQXQgYSBoaWdoIGxldmVsLCBJIHdvdWxkIGxp a2UgdG8gc2VlIHNlcnZpY2VzIGFzIGNvbXBvc2l0aW9ucyANCj4gKG1hc2gtdXBzKSBvZiBzZXJ2 aWNlIGVsZW1lbnRzLiAgVGhpcyBpcyBhIGdlbmVyYWxpemF0aW9uIG9mIHRoZSBjb21tZW50cyB0 aGF0IEFpanVuIG1hZGUuDQo+IEhlcmXigJlzIHdoeS4gIEFzIHdlIChlaXRoZXIgdGhlIElFVEYg b3Igb3RoZXIgYm9kaWVzLCBvciBTUHMgb24gdGhlaXIgDQo+IG93bikgZGVmaW5lIG90aGVyIHNl cnZpY2VzLCBpdCB3b3VsZCBiZSB2ZXJ5IGNvbnZlbmllbnQgdG8gYmUgYWJsZSB0byANCj4gcmV1 c2UgdGhlc2Ugc2VydmljZSBlbGVtZW50cy4NCg0KSSBjb21wbGV0ZWx5IHRha2UgeW91ciBwb2lu dCwgYnV0Li4uDQoNCldoZW4gd2Ugc3RhcnRlZCB0aGUgTDNTTSB3b3JrIHdlIHdlcmUgbm90IGNl cnRhaW4gKGFuZCBzb21lIHJlbWFpbiB1bmNlcnRhaW4pIHRoYXQgdGhlIHByb2JsZW0gY291bGQg YmUgYWRkcmVzc2VkIGV2ZW4gZm9yIG9uZSBvZiBvdXIgbW9zdCBzaW1wbGUgc2VydmljZXMgKHRo ZSBMM1ZQTikgbGV0IGFsb25lIGZvciBhIG1vcmUgZ2VuZXJpYyBjb25jZXB0IG9mIHNlcnZpY2Vz LiBUaGVyZWZvcmUsIHRoZSBXRyB3YXMgZXhwbGljaXRseSB0YXNrZWQgKHJlYWQgdGhlIGNoYXJ0 ZXIpIHRvIHdvcmsgd2l0aCBmb2N1cyBhbmQgYXR0ZW50aW9uIG9uIEwzVlBOIG9ubHkgYW5kIHRv IGV4Y2x1ZGUgY29uc2lkZXJhdGlvbiBvZiBvdGhlciBzZXJ2aWNlcy4NCg0KVGhhdCwgaW4gaXRz ZWxmLCBkb2VzIG5vdCBwcmVkaWNhdGUgYWdhaW5zdCBtb2R1bGFyaXNhdGlvbiwgYnV0IGl0IGRv ZXMgbWFrZSBpdCBoYXJkIHRvIGNvbnNpZGVyIHdoaWNoIG1vZHVsZXMgdG8gaGF2ZSAoc2luY2Ug c29tZSBhc3BlY3RzIG9mIG1vZHVsYXJpc2F0aW9uIG11c3Qgc3VyZWx5IGNvbnNpZGVyIHRoZSBv dGhlciBzZXJ2aWNlcyB0aGF0IG1pZ2h0IHVzZSB0aGUgbW9kdWxlcykuDQoNClRoZXJlZm9yZSwg bXkgZXhwZWN0YXRpb24gb2YgcHJvZ3Jlc3MgaXMuLi4NCg0KLSBDb250aW51ZSB0byBwcm9ncmVz cyBMM1NNIHRvd2FyZHMgY29tcGxldGlvbg0KLSBQdWJsaXNoIGFuIFJGQyAoaWYgaXQgY2FuIGJl IGFncmVlZCBhbmQgZG9uZSkNCi0gU3RhcnQgd29yayBvbiBhbm90aGVyIHNpbWlsYXIgc2Vydmlj ZSBtb2RlbCAoZS5nLiBMMlNNKQ0KICAgLSBJZiB0aGVyZSBpcyBlbmVyZ3kNCiAgIC0gSWYgdGhl IElFU0cgZ2l2ZXMgdXMgcGVybWlzc2lvbg0KLSBMb29rIGZvciBjb21tb25hbGl0aWVzIGFuZCBt b2R1bGFyaXNhdGlvbnMNCiAgIC0gSWYgdGhleSBleGlzdCBpdCBtYXkgYmUgbmVjZXNzYXJ5IHRv IHJldmlzZSBMM1NNDQoNClNvLCBmcm9tIHNvbWUgYXNwZWN0cyB0aGlzIGRvZXMgbm90IGxvb2sg b3B0aW1hbC4gUGVyaGFwcyB5b3UgY291bGQgaGF2ZSBtYWRlIHRoaXMgY29tbWVudCBkdXJpbmcg Y2hhcnRlcmluZy4gDQpCdXQgZnJvbSBhbm90aGVyIHBlcnNwZWN0aXZlIGl0IGVuYWJsZXMgc29t ZSBpbml0aWFsIHByb2dyZXNzIGluIGEgbmV3IHN1YmplY3Qgc3BhY2UgdGhhdCB0aGUgSUVURiBo YXMgbm90IHByZXZpb3VzbHkgYXR0ZW1wdGVkLiBJZiBpdCBpcyBzdWNjZXNzZnVsIHdlIGNhbiBk aWcgZGVlcGVyLg0KDQpPdmVyYWxsIChzZXR0aW5nIGFzaWRlIHRoZSBmYWN0IHRoYXQgd2UgYXJl IGFueXdheSBjb25zdHJhaW5lZCBieSBvdXIgY2hhcnRlcikgSSBoYXZlIGEgZmVhciBvZiBvY2Vh bi1ib2lsaW5nLiBCdXQgc29tZSBlYXJseSwgcHJlY2F1dGlvbmFyeSBtb2R1bGFyaXNhdGlvbiBp cyBub3QgZ29pbmcgdG8gYmUgYSBwcm9ibGVtIHNvIGxvbmcgYXMgd2UgZG9uJ3Qgc3BlbmQgdG9v IGxvbmcgYXJndWluZyBhYm91dCBleGFjdGx5IHdoYXQgdG8gbW9kdWxhcmlzZS4NCg0KQWRyaWFu DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K TDNzbSBtYWlsaW5nIGxpc3QNCkwzc21AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbDNzbQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQs IHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxl dGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed Jul 22 05:53:06 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618F21B3306 for ; Wed, 22 Jul 2015 05:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 9M9mEzinyJJj for ; Wed, 22 Jul 2015 05:53:03 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C2F1A1B5D for ; Wed, 22 Jul 2015 05:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2742; q=dns/txt; s=iport; t=1437569581; x=1438779181; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=6OI5/ia0mxx/AWA3RbOYCozxsgmCwhjawKJl4J3wV0k=; b=K6nbWSobCSaG0V9I2FkZyz4FiGwkVY83GwCstB8YpPrsKvXh/USw0PV8 j867/nd8KPLeak/Yat1ktuYZZ7cBdkzGh2jYj1P78pRJ8jVGJWVPweHac CI7hbFEfLAr9pKAGZmN6h/fQbYZph1nkLWCU4NKdpTpMmv0Kt4s8NhaXR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AgBNka9V/xbLJq1bg2lpgyO4WgmBawqGAQKCBRQBAQEBAQEBgQqEJAEBBAEBASAPAQU2ChELGgIFFgsCAgkDAgECARUwBgEMBgIBAYgqDbYlljcBAQEBAQEBAQEBAQEBAQEBAQEWBIEiiiqFDYJogUMBBIUigWiNTYdVgjSCKYFDhwsiiB6EI4NhJoN+PDGCSwEBAQ X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="595566528" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 22 Jul 2015 12:52:59 +0000 Received: from [10.61.92.242] (ams3-vpn-dhcp7411.cisco.com [10.61.92.242]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6MCqtjf022493; Wed, 22 Jul 2015 12:52:55 GMT To: adrian@olddog.co.uk, "'Kireeti Kompella'" , l3sm@ietf.org References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk> From: Benoit Claise Message-ID: <55AF9226.4050005@cisco.com> Date: Wed, 22 Jul 2015 14:52:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 12:53:05 -0000 Dear all, +1 to Adrian's message. My ocean-boiling concern has always been: in order to do the perfect job of modularity/grouping/augmentation, we should investigate all existing and potential future services. And the L2VPN are technology specific, so it's start to be difficult. This is the reason why the charter is so strict and only focuses on L3VPN. Obviously, we should follow Adrian's advice: "But some early, precautionary modularisation is not going to be a problem so long as we don't spend too long arguing about exactly what to modularise." Regards, Benoit > Hello Kireeti, > > Welcome to the party. > >> 1) At a high level, I would like to see services as compositions (mash-ups) of >> service elements. This is a generalization of the comments that Aijun made. >> Here’s why. As we (either the IETF or other bodies, or SPs on their own) define >> other services, it would be very convenient to be able to reuse these service >> elements. > I completely take your point, but... > > When we started the L3SM work we were not certain (and some remain uncertain) that the problem could be addressed even for one of our most simple services (the L3VPN) let alone for a more generic concept of services. Therefore, the WG was explicitly tasked (read the charter) to work with focus and attention on L3VPN only and to exclude consideration of other services. > > That, in itself, does not predicate against modularisation, but it does make it hard to consider which modules to have (since some aspects of modularisation must surely consider the other services that might use the modules). > > Therefore, my expectation of progress is... > > - Continue to progress L3SM towards completion > - Publish an RFC (if it can be agreed and done) > - Start work on another similar service model (e.g. L2SM) > - If there is energy > - If the IESG gives us permission > - Look for commonalities and modularisations > - If they exist it may be necessary to revise L3SM > > So, from some aspects this does not look optimal. Perhaps you could have made this comment during chartering. > But from another perspective it enables some initial progress in a new subject space that the IETF has not previously attempted. If it is successful we can dig deeper. > > Overall (setting aside the fact that we are anyway constrained by our charter) I have a fear of ocean-boiling. But some early, precautionary modularisation is not going to be a problem so long as we don't spend too long arguing about exactly what to modularise. > > Adrian > > > > _______________________________________________ > L3sm mailing list > L3sm@ietf.org > https://www.ietf.org/mailman/listinfo/l3sm From nobody Wed Jul 22 06:09:01 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21941A1AE6 for ; Wed, 22 Jul 2015 06:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 LvByn5S7iTae for ; Wed, 22 Jul 2015 06:08:50 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90011B3349 for ; Wed, 22 Jul 2015 06:08:44 -0700 (PDT) Received: from [31.55.5.74] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZHtl5-0004t5-Jp; Wed, 22 Jul 2015 14:08:27 +0100 Date: Wed, 22 Jul 2015 14:08:34 +0100 From: Rob Shakir To: 'Kireeti Kompella' , adrian@olddog.co.uk, Benoit Claise , l3sm@ietf.org Message-ID: In-Reply-To: <55AF9226.4050005@cisco.com> References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk> <55AF9226.4050005@cisco.com> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55af95d3_46bf289d_36f" Archived-At: Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:08:52 -0000 --55af95d3_46bf289d_36f Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =46olks, +1 to Kireeti=E2=80=99s point that modularisation/mash-ups are the best w= ay forward - we have common network designs for how e.g., an L3 edge inte= rface works, which should not be duplicated between services. Indeed, whe= re they are - this creates=C2=A0inefficiencies - such as having to change= code and tooling surrounding multiple service models just to change one = parameter of an interface (supporting an IP MTU of =24current=5Fvalue+1).= However, I can see the point that is being made by Adrian/Benoit. I might= observe that this is a balance between standardisation (setting in R=46C= -stone), and building=C2=A0efficient=C2=A0=E2=80=98blocks=E2=80=99 of an = overall architecture that are usable. To me, I=E2=80=99m more interested in the latter, than the former. So - c= an we take an approach that says that we create an L3VPN service model - = and stamp it as some final version (figuring out whether we can actually = get to this step is interesting in and of itself) but not necessarily get= out our chisels and start carving =5B0=5D=3F Subsequently, common elemen= ts can be pulled=C2=A0apart into modules that achieve the most efficient = architecture. The balance we have here is one that I think the IESG needs to approach -= how do we both iterate on models (that are of course software), and get = to things that can be considered=C2=A0=E2=80=98standards=E2=80=99 despite= the fact that they may be refactored in the future. Cheers, r. =5B0=5D: This might be done by, rather than not publishing, determining t= hat the model=E2=80=99s status is really experimental, as we *know* as a = WG that modularity would be very useful, if not essential, to have. On 22 July 2015 at 13:53:04, Benoit Claise (bclaise=40cisco.com) wrote: Dear all, +1 to Adrian's message. My ocean-boiling concern has always been: in order to do the perfect job = =20 of modularity/grouping/augmentation, we should investigate all existing =20 and potential future services. And the L2VPN are technology specific, so = =20 it's start to be difficult. This is the reason why the charter is so strict and only focuses on L3VPN= . Obviously, we should follow Adrian's advice: =22But some early, =20 precautionary modularisation is not going to be a problem so long as we =20 don't spend too long arguing about exactly what to modularise.=22 Regards, Benoit > Hello Kireeti, > > Welcome to the party. > >> 1) At a high level, I would like to see services as compositions (mash= -ups) of >> service elements. This is a generalization of the comments that Aijun = made. >> Here=E2=80=99s why. As we (either the IET=46 or other bodies, or SPs o= n their own) define >> other services, it would be very convenient to be able to reuse these = service >> elements. > I completely take your point, but... > > When we started the L3SM work we were not certain (and some remain unce= rtain) that the problem could be addressed even for one of our most simpl= e services (the L3VPN) let alone for a more generic concept of services. = Therefore, the WG was explicitly tasked (read the charter) to work with f= ocus and attention on L3VPN only and to exclude consideration of other se= rvices. > > That, in itself, does not predicate against modularisation, but it does= make it hard to consider which modules to have (since some aspects of mo= dularisation must surely consider the other services that might use the m= odules). > > Therefore, my expectation of progress is... > > - Continue to progress L3SM towards completion > - Publish an R=46C (if it can be agreed and done) > - Start work on another similar service model (e.g. L2SM) > - If there is energy > - If the IESG gives us permission > - Look for commonalities and modularisations > - If they exist it may be necessary to revise L3SM > > So, from some aspects this does not look optimal. Perhaps you could hav= e made this comment during chartering. > But from another perspective it enables some initial progress in a new = subject space that the IET=46 has not previously attempted. If it is succ= essful we can dig deeper. > > Overall (setting aside the fact that we are anyway constrained by our c= harter) I have a fear of ocean-boiling. But some early, precautionary mod= ularisation is not going to be a problem so long as we don't spend too lo= ng arguing about exactly what to modularise. > > Adrian > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > L3sm mailing list > L3sm=40ietf.org > https://www.ietf.org/mailman/listinfo/l3sm =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F L3sm mailing list L3sm=40ietf.org https://www.ietf.org/mailman/listinfo/l3sm --55af95d3_46bf289d_36f Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi, all:

 

The reason that we consider to design the L3SM in modular manner is = that we should consider its relationship with the device model as early = as possible:

1. Can we make use of the Yang Model that defined in other WGs as = modules?

2. Or can we leave some spaces for future module = definition?

3. The service model should be abstracted in a higher level and=C2=A0 = hide the detail technology information into the modules at best. Is this = the right way to define the service module from top to = down?

4. If there is no more modules for us to refer now,=C2=A0 can we = group the related stanza into different modules and make it as the base = of the modular prototype?

 

 

Aijun Wang

 

China Telecom Corporation Limited Beijing Res= earch Institute 

Intelligent Network Product Line

 

From:= L3sm = [mailto:l3sm-bounces@ietf.org] On Behalf Of Rob = Shakir
Sent: Wednesday, July 22, 2015 9:09 PM
To: = 'Kireeti Kompella'; adrian@olddog.co.uk; Benoit Claise; = l3sm@ietf.org
Subject: Re: [L3sm] Comments on = draft-ietf-l3sm-l3vpn-service-model

 

Folks,=

 

+1 to Kireeti=E2=80=99s = point that modularisation/mash-ups are the best way forward - we have = common network designs for how e.g., an L3 edge interface works, which = should not be duplicated between services. Indeed, where they are - this = creates inefficiencies - such as having to change code and tooling = surrounding multiple service models just to change one parameter of an = interface (supporting an IP MTU of $current_value+1).

 

However, I can see the = point that is being made by Adrian/Benoit. I might observe that this is = a balance between standardisation (setting in RFC-stone), and = building efficient =E2=80=98blocks=E2=80=99 of an overall = architecture that are usable.

&nbs= p;

To me, I=E2=80=99m more = interested in the latter, than the former. So - can we take an approach = that says that we create an L3VPN service model - and stamp it as some = final version (figuring out whether we can actually get to this step is = interesting in and of itself) but not necessarily get out our chisels = and start carving [0]? Subsequently, common elements can be = pulled apart into modules that achieve the most efficient = architecture.

&nbs= p;

The balance we have here = is one that I think the IESG needs to approach - how do we both iterate = on models (that are of course software), and get to things that can be = considered =E2=80=98standards=E2=80=99 despite the fact that they = may be refactored in the future.

&nbs= p;

Cheers,

r.

&nbs= p;

[0]: This might be done = by, rather than not publishing, determining that the model=E2=80=99s = status is really experimental, as we *know* as a WG that modularity = would be very useful, if not essential, to have.

&nbs= p;

On 22 July 2015 at 13:53:04, Benoit Claise (bclaise@cisco.com) = wrote:

Dear = all,

+1 to Adrian's message.

My ocean-boiling concern has = always been: in order to do the perfect job
of = modularity/grouping/augmentation, we should investigate all existing =
and potential future services. And the L2VPN are technology = specific, so
it's start to be difficult.

This is the reason = why the charter is so strict and only focuses on = L3VPN.

Obviously, we should follow Adrian's advice: "But = some early,
precautionary modularisation is not going to be a = problem so long as we
don't spend too long arguing about exactly = what to modularise."

Regards, Benoit
> Hello = Kireeti,
>
> Welcome to the party.
>
>> 1) At = a high level, I would like to see services as compositions (mash-ups) = of
>> service elements. This is a generalization of the = comments that Aijun made.
>> Here=E2=80=99s why. As we (either = the IETF or other bodies, or SPs on their own) define
>> other = services, it would be very convenient to be able to reuse these = service
>> elements.
> I completely take your point, = but...
>
> When we started the L3SM work we were not certain = (and some remain uncertain) that the problem could be addressed even for = one of our most simple services (the L3VPN) let alone for a more generic = concept of services. Therefore, the WG was explicitly tasked (read the = charter) to work with focus and attention on L3VPN only and to exclude = consideration of other services.
>
> That, in itself, does = not predicate against modularisation, but it does make it hard to = consider which modules to have (since some aspects of modularisation = must surely consider the other services that might use the = modules).
>
> Therefore, my expectation of progress = is...
>
> - Continue to progress L3SM towards = completion
> - Publish an RFC (if it can be agreed and = done)
> - Start work on another similar service model (e.g. = L2SM)
> - If there is energy
> - If the IESG gives us = permission
> - Look for commonalities and modularisations
> = - If they exist it may be necessary to revise L3SM
>
> So, = from some aspects this does not look optimal. Perhaps you could have = made this comment during chartering.
> But from another = perspective it enables some initial progress in a new subject space that = the IETF has not previously attempted. If it is successful we can dig = deeper.
>
> Overall (setting aside the fact that we are = anyway constrained by our charter) I have a fear of ocean-boiling. But = some early, precautionary modularisation is not going to be a problem so = long as we don't spend too long arguing about exactly what to = modularise.
>
> Adrian
>
>
>
> = _______________________________________________
> L3sm mailing = list
> L3sm@ietf.org
> = https://www.ietf.org/= mailman/listinfo/l3sm

________________________________________= _______
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/= mailman/listinfo/l3sm

<= /div> ------=_NextPart_000_0001_01D0C55E.C86A1EE0-- From nobody Thu Jul 23 02:30:23 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6421A1A57 for ; Thu, 23 Jul 2015 02:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 BhDO7035XFAC for ; Thu, 23 Jul 2015 02:30:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63C11A21C0 for ; Thu, 23 Jul 2015 02:30:08 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id BD082374A7B; Thu, 23 Jul 2015 11:30:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.61]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 8BB1B158097; Thu, 23 Jul 2015 11:30:06 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0235.001; Thu, 23 Jul 2015 11:30:05 +0200 From: To: Eric C Rosen , Kireeti Kompella , "l3sm@ietf.org" Thread-Topic: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHQw8X3K3YLZClNO0qpeZYxRBC/cp3nugYAgADZWqA= Date: Thu, 23 Jul 2015 09:30:05 +0000 Message-ID: <29351_1437643806_55B0B41E_29351_10618_1_9E32478DFA9976438E7A22F69B08FF92166A402F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> <55AFE9C4.5070704@juniper.net> In-Reply-To: <55AFE9C4.5070704@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.23.82416 Archived-At: Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 09:30:21 -0000 SGkgRXJpYywNCg0KUGxlYXMgZmluZCBzb21lIGlubGluZSBjb21tZW50cw0KDQpCZXN0IFJlZ2Fy ZHMsDQoNClN0ZXBoYW5lDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMM3Nt IFttYWlsdG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBDIFJvc2Vu DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjIsIDIwMTUgMjE6MDcNClRvOiBLaXJlZXRpIEtvbXBl bGxhOyBsM3NtQGlldGYub3JnDQpDYzogZXJvc2VuQGp1bmlwZXIubmV0DQpTdWJqZWN0OiBSZTog W0wzc21dIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVsDQoN Ck9uIDcvMjEvMjAxNSAxMTowMCBBTSwgS2lyZWV0aSBLb21wZWxsYSB3cm90ZToNCj4gNikgUGhp bG9zb3BoaWNhbCBjb21tZW50OiBzaG91bGQgc2NydXRpbml6ZSBzZXJ2aWNlIG1vZGVscyB0byBl bnN1cmUgDQo+IHdl4oCZcmUgbWFraW5nIHRoZW0gYXMgYWJzdHJhY3QgYXMgcG9zc2libGUuICBF LmcuLCBJ4oCZbSB2ZXJ5IGhhcHB5IHRoYXQgDQo+IFJEcyBhbmQgUlRzIGFyZSBub3QgaW4gdGhl IFNNLg0KDQpJdCdzIGNlcnRhaW5seSB0cnVlIHRoYXQgUkRzIGFuZCBSVHMgYXJlIG5vdCBwYXJ0 IG9mIHRoZSBzZXJ2aWNlLCBzaW5jZSB0aGV5IGFyZSBub3Qga25vd24gdG8gdGhlIGN1c3RvbWVy cy4gIEJ1dCB0aGUgZHJhZnQgZG9lcyBzZWVtIHRvIHByZXN1bWUgdGhhdCB0aGUgU00sIHRvZ2V0 aGVyIHdpdGggdGhlIHByb3ZpZGVyJ3MgUlQvUkQgYWxsb2NhdGlvbiBwb2xpY2llcywgY2FuIGJl IHVzZWQgdG8gYXV0b21hdGljYWxseSBhbGxvY2F0ZSBSVHMgYW5kIFJEcyB0aGF0IGFyZSBzdWl0 YWJsZSBmb3IgcHJvdmlkaW5nIHRoZSBuZWNlc3Nhcnkgc2VydmljZXMuDQpbU0xJXSBZZXMsIHRo aXMgaXMgdGhlIGlkZWEuIA0KDQpJIG5vdGUgdGhhdCB0aGUgU00gZG9lcyBub3QgcmVzdHJpY3Qg dGhlIFJEIGFsbG9jYXRpb24gcG9saWN5LiAgSG93ZXZlciwgc29tZSBSRCBhbGxvY2F0aW9uIHBv bGljaWVzIGFyZSBpbmNvbXBhdGlibGUgd2l0aCBjZXJ0YWluIHNlcnZpY2VzLiAgRm9yIGluc3Rh bmNlLCBhIHBlci1WUE4gYWxsb2NhdGlvbiBwb2xpY3kgd2lsbCBzZXZlcmVseSBjb25zdHJhaW4g dGhlIHR5cGUgb2YgbG9hZC1iYWxhbmNpbmcgc2VydmljZSB0aGF0IGNhbiBiZSBvZmZlcmVkLiAg QSBwZXItVlBOIGFsbG9jYXRpb24gcG9saWN5IChpbmRlZWQsIGFueXRoaW5nIGJ1dCBhIHBlci1W UkYgYWxsb2NhdGlvbiBwb2xpY3kpIGlzIGFsc28gaW5jb21wYXRpYmxlIHdpdGggTkctTVZQTi4g IFNob3VsZCB0aGlzIGtpbmQgb2YgaW50ZXJkZXBlbmRlbmN5IGJlIGNhcHR1cmVkIGluIHRoZSBT TSwgb3IgaW4gYW5vdGhlciBZYW5nIG1vZGVsLCBvciBpcyBpdCBlbnRpcmVseSBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGUgWWFuZyBtb2RlbHM/DQpbU0xJXSBJIGFncmVlIHRoYXQgUkQgYWxsb2Nh dGlvbiBwb2xpY3kgcmVzdHJpY3Qgc29tZSBzZXJ2aWNlcy4gSU1PLCB0aGlzIGlzIGEgcHJvdmlk ZXIgbmV0d29yayBkZXNpZ24gaXNzdWUgcmF0aGVyIHRoYW4gYSBzZXJ2aWNlIG1vZGVsaW5nLiBU aGUgbW9kZWwgcHJvdmlkZXMgZW5vdWdoIGluZm9ybWF0aW9uIChsaWtlIGxvYWRzaGFyaW5nIHJl cXVlc3Qgb3IgbXVsdGljYXN0IHJlcXVlc3QpIHRvIGxldCBzZXJ2aWNlIHByb3ZpZGVyIGtub3cg dGhhdCB0aGVyZSBtYXkgYmUgc29tZXRoaW5nIHNwZWNpYWwgdG8gZG8gcmVnYXJkaW5nIHRoZSBS RCBhbGxvY2F0aW9uIHBvbGljeSB0byBtYWtlIHRoZXNlIHNlcnZpY2VzIHdvcmtpbmcuIFdlIHN1 cHBvc2UgdGhhdCB0aGVzZSBiYXNpYyBkZXNpZ24gcnVsZXMgYXJlIHdlbGwga25vd24gYnkgU1Bz IGFuZCB3ZSBjb25zaWRlciBpdCBhcyBvdXQgb2Ygc2NvcGUuDQoNClNvbWUgcHJvdmlkZXJzIHdp dGggbXVsdGktQVMgVlBOcyBkbyBSVC1yZXdyaXRpbmcgYXQgdGhlIEFTQlJzLiAgVGhpcyBzdWdn ZXN0cyB0aGF0IGZvciBhIGdpdmVuIFZQTiwgdGhlIFJUIGFsbG9jYXRpb24gcG9saWN5IGluIG9u ZSBBUyBjYW4gYmUgZGlmZmVyZW50IHRoYW4gdGhlIFJUIGFsbG9jYXRpb24gcG9saWN5IGluIHRo ZSBvdGhlci4gIEluIG9yZGVyIHRvIGNvcnJlY3RseSBhZGQgYSBuZXcgc2l0ZSBpbiBhIGdpdmVu IEFTLCBkb2VzIHRoZSBTTSBoYXZlIHRvIGNhcHR1cmUgdGhlIGZhY3QgdGhhdCB0aGUgUlQgYWxs b2NhdGlvbiBwb2xpY3kgaXMgcGVyLUFTPyAgSWYgbm90LCBpcyB0aGVyZSBzb21lIFlhbmcgbW9k ZWwgaW4gd2hpY2ggdGhpcyBmYWN0IGRvZXMgbmVlZCB0byBiZSBjYXB0dXJlZCwgb3IgaXMgaXQg ZW50aXJlbHkgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIFlhbmcgbW9kZWxzPw0KW1NMSV0gSW50 ZXJBUyBjYXNlIGhhcyBub3QgYmVlbiBhZGRyZXNzZWQgeWV0LiBEZXBlbmRpbmcgb2YgdGhlIGRl c2lnbiwgUlQgcmV3cml0ZSBpcyBuZWVkZWQgb3Igbm90LCBSVCBmaWx0ZXJpbmcgbWF5IGJlIGFw cGxpZWQgb3Igbm90IC4uLiB3ZSBuZWVkIHRvIGxvb2sgYXQgaWYgdGhlcmUgaXMgc29tZXRoaW5n IHNwZWNpYWwgdG8gZG8gaGVyZSBvciBub3QuDQoNCkNoYW5naW5nIHRoZSB0b3BpYywgSSBoYXZl IGEgcXVlc3Rpb24gYWJvdXQgdGhlIG11bHRpY2FzdCBzZXJ2aWNlIG1vZGVsLiANCiAgU29tZSBQ RSBwcm9kdWN0cyBhbGxvdyB0aGUgU1AgdG8gb2ZmZXIgYSBSZW5kZXp2b3VzIFBvaW50IHNlcnZp Y2UgdG8gdGhlaXIgTVZQTiBjdXN0b21lcnMuICANCltTTEldIFR5cGUgb2YgdHJlZSwgcmVuZGV6 IHZvdXMgcG9pbnQgdHlwZSBhbmQgSVAgYWRkcmVzcyBpcyBhdmFpbGFibGUgaW4gdGhlIHZwbi1z dmMgZGVmaW5pdGlvbg0KDQpTb21lIGFsbG93IHRoZSBTUCB0byBvZmZlciBJR01QL01MRCBzZXJ2 aWNlIHRvIHRoZWlyIE1WUE4gY3VzdG9tZXJzLCBvdGhlcnMgb25seSBhbGxvdyB0aGUgU1AgdG8g b2ZmZXIgYSBQSU0gcGVlcmluZyBzZXJ2aWNlLiAgVGhlIFNNIGRvZXNuJ3Qgc2VlbSB0byBzYXkg YW55dGhpbmcgYWJvdXQgdGhlc2UgYWx0ZXJuYXRpdmVzIGF0IGFsbCwgZXZlbiB0aG91Z2ggdGhl c2UgYWx0ZXJuYXRpdmVzIGFyZSBjdXN0b21lci12aXNpYmxlLiAgSXMgdGhhdCBhbiBpbnRlbnRp b25hbCBvbWlzc2lvbj8NCltTTEldIFRoaXMgY2FuIGJlIGFkZGVkIHRvIHRoZSByb3V0aW5nIHBy b3RvY29sIGxpc3QuIA0KDQpDaGFuZ2luZyB0aGUgdG9waWMgYWdhaW4sIGRvbid0IFNQcyBvZnRl biBwbGFjZSBsaW1pdGF0aW9ucyBvbiB0aGUgbnVtYmVyIG9mIHJvdXRlcyAob3IgdGhlIHJhdGUg b2Ygcm91dGUgY2hhbmdlKSBwZXIgVlJGIGZvciBlaXRoZXIgdW5pY2FzdCBvciBtdWx0aWNhc3Qg cm91dGVzIG9yIGJvdGg/ICBJIGRpZG4ndCBub3RpY2UgYW55dGhpbmcgYWJvdXQgdGhhdCBpbiB0 aGUgU007IGlzIHRoYXQgc29tZXRoaW5nIHRoYXQgdGhlIFNNIHNob3VsZCBjYXB0dXJlPw0KW1NM SV0gVGhhdCdzIGF2YWlsYWJsZSBpbiB0aGUgbW9kZWwsIHVzaW5nIG1heGltdW0tcm91dGVzIGxl YWYuDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkwzc20gbWFpbGluZyBsaXN0DQpMM3NtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2wzc20NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Thu Jul 23 03:15:31 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F7A1A036F for ; Thu, 23 Jul 2015 03:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 UjwWO1gCEY9N for ; Thu, 23 Jul 2015 03:15:27 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816481A0107 for ; Thu, 23 Jul 2015 03:15:27 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id DA0801171F895; Thu, 23 Jul 2015 10:15:23 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6NAFJ2Q028688 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 12:15:24 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.91]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 12:15:23 +0200 From: "Scharf, Michael (Michael)" To: "stephane.litkowski@orange.com" , "adrian@olddog.co.uk" , "'Kireeti Kompella'" , "l3sm@ietf.org" Thread-Topic: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHQw8X4DW+4qcfGmUmoUTaDVwVcyZ3nSqKAgAADRgCAAYdm0A== Date: Thu, 23 Jul 2015 10:15:22 +0000 Message-ID: <655C07320163294895BBADA28372AF5D484379B9@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk> <10361_1437568788_55AF8F14_10361_7312_1_9E32478DFA9976438E7A22F69B08FF92166A3977@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <10361_1437568788_55AF8F14_10361_7312_1_9E32478DFA9976438E7A22F69B08FF92166A3977@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 10:15:29 -0000 PiA+IEJ1dCBzb21lIGVhcmx5LCBwcmVjYXV0aW9uYXJ5IG1vZHVsYXJpc2F0aW9uIGlzIG5vdCBn b2luZyB0byBiZSBhDQo+IHByb2JsZW0gc28gbG9uZyBhcyB3ZSBkb24ndCBzcGVuZCB0b28gbG9u ZyBhcmd1aW5nIGFib3V0IGV4YWN0bHkgd2hhdA0KPiB0byBtb2R1bGFyaXNlLg0KPg0KPiBGdWxs eSBhZ3JlZSAuLi4sIHNvbWUgc2VjdGlvbnMgS2lyZWV0aSB3YXMgbWVudGlvbmluZyBhcmUgZXZp ZGVudCB0byBiZQ0KPiBhcyBhIHJldXNhYmxlIGNvbXBvbmVudCBzbyB3ZSBjYW4gZG8gaXQgbm93 LCBmb3IgbW9yZSBjb21wbGV4IHRoaW5ncywNCj4gbGV0J3MgdGhpbmsgYWJvdXQgaXQgYWZ0ZXIg dGhlIG1vZHVsZSBpcyAoYWxtb3N0KSBmaW5pc2hlZC4NCg0KVGhlcmUgaXMgZ3JlYXQgdmFsdWUg aW4gaGF2aW5nIGEgY29uc2lzdGVudCBtb2RlbCB3aXRob3V0IGNvbXBsZXggZXh0ZXJuYWwgZGVw ZW5kZW5jaWVzLCBhbmQgd2Ugc2hvdWxkIGFpbSBhdCBwdWJsaXNoaW5nIHRoYXQgbW9kZWwgc29v bi4gVGhpcyBzaWduaWZpY2FudGx5IHNpbXBsaWZpZXMgaW1wbGVtZW50YXRpb24uDQoNCk1pY2hh ZWwgDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMM3NtIFttYWls dG86bDNzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRyaWFuIEZhcnJlbA0KPiBT ZW50OiBXZWRuZXNkYXksIEp1bHkgMjIsIDIwMTUgMTQ6MjgNCj4gVG86ICdLaXJlZXRpIEtvbXBl bGxhJzsgbDNzbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0wzc21dIENvbW1lbnRzIG9uIGRy YWZ0LWlldGYtbDNzbS1sM3Zwbi1zZXJ2aWNlLW1vZGVsDQo+IA0KPiBIZWxsbyBLaXJlZXRpLA0K PiANCj4gV2VsY29tZSB0byB0aGUgcGFydHkuDQo+IA0KPiA+IDEpIEF0IGEgaGlnaCBsZXZlbCwg SSB3b3VsZCBsaWtlIHRvIHNlZSBzZXJ2aWNlcyBhcyBjb21wb3NpdGlvbnMNCj4gPiAobWFzaC11 cHMpIG9mIHNlcnZpY2UgZWxlbWVudHMuICBUaGlzIGlzIGEgZ2VuZXJhbGl6YXRpb24gb2YgdGhl DQo+IGNvbW1lbnRzIHRoYXQgQWlqdW4gbWFkZS4NCj4gPiBIZXJl4oCZcyB3aHkuICBBcyB3ZSAo ZWl0aGVyIHRoZSBJRVRGIG9yIG90aGVyIGJvZGllcywgb3IgU1BzIG9uIHRoZWlyDQo+ID4gb3du KSBkZWZpbmUgb3RoZXIgc2VydmljZXMsIGl0IHdvdWxkIGJlIHZlcnkgY29udmVuaWVudCB0byBi ZSBhYmxlIHRvDQo+ID4gcmV1c2UgdGhlc2Ugc2VydmljZSBlbGVtZW50cy4NCj4gDQo+IEkgY29t cGxldGVseSB0YWtlIHlvdXIgcG9pbnQsIGJ1dC4uLg0KPiANCj4gV2hlbiB3ZSBzdGFydGVkIHRo ZSBMM1NNIHdvcmsgd2Ugd2VyZSBub3QgY2VydGFpbiAoYW5kIHNvbWUgcmVtYWluDQo+IHVuY2Vy dGFpbikgdGhhdCB0aGUgcHJvYmxlbSBjb3VsZCBiZSBhZGRyZXNzZWQgZXZlbiBmb3Igb25lIG9m IG91ciBtb3N0DQo+IHNpbXBsZSBzZXJ2aWNlcyAodGhlIEwzVlBOKSBsZXQgYWxvbmUgZm9yIGEg bW9yZSBnZW5lcmljIGNvbmNlcHQgb2YNCj4gc2VydmljZXMuIFRoZXJlZm9yZSwgdGhlIFdHIHdh cyBleHBsaWNpdGx5IHRhc2tlZCAocmVhZCB0aGUgY2hhcnRlcikgdG8NCj4gd29yayB3aXRoIGZv Y3VzIGFuZCBhdHRlbnRpb24gb24gTDNWUE4gb25seSBhbmQgdG8gZXhjbHVkZQ0KPiBjb25zaWRl cmF0aW9uIG9mIG90aGVyIHNlcnZpY2VzLg0KPiANCj4gVGhhdCwgaW4gaXRzZWxmLCBkb2VzIG5v dCBwcmVkaWNhdGUgYWdhaW5zdCBtb2R1bGFyaXNhdGlvbiwgYnV0IGl0IGRvZXMNCj4gbWFrZSBp dCBoYXJkIHRvIGNvbnNpZGVyIHdoaWNoIG1vZHVsZXMgdG8gaGF2ZSAoc2luY2Ugc29tZSBhc3Bl Y3RzIG9mDQo+IG1vZHVsYXJpc2F0aW9uIG11c3Qgc3VyZWx5IGNvbnNpZGVyIHRoZSBvdGhlciBz ZXJ2aWNlcyB0aGF0IG1pZ2h0IHVzZQ0KPiB0aGUgbW9kdWxlcykuDQo+IA0KPiBUaGVyZWZvcmUs IG15IGV4cGVjdGF0aW9uIG9mIHByb2dyZXNzIGlzLi4uDQo+IA0KPiAtIENvbnRpbnVlIHRvIHBy b2dyZXNzIEwzU00gdG93YXJkcyBjb21wbGV0aW9uDQo+IC0gUHVibGlzaCBhbiBSRkMgKGlmIGl0 IGNhbiBiZSBhZ3JlZWQgYW5kIGRvbmUpDQo+IC0gU3RhcnQgd29yayBvbiBhbm90aGVyIHNpbWls YXIgc2VydmljZSBtb2RlbCAoZS5nLiBMMlNNKQ0KPiAgICAtIElmIHRoZXJlIGlzIGVuZXJneQ0K PiAgICAtIElmIHRoZSBJRVNHIGdpdmVzIHVzIHBlcm1pc3Npb24NCj4gLSBMb29rIGZvciBjb21t b25hbGl0aWVzIGFuZCBtb2R1bGFyaXNhdGlvbnMNCj4gICAgLSBJZiB0aGV5IGV4aXN0IGl0IG1h eSBiZSBuZWNlc3NhcnkgdG8gcmV2aXNlIEwzU00NCj4gDQo+IFNvLCBmcm9tIHNvbWUgYXNwZWN0 cyB0aGlzIGRvZXMgbm90IGxvb2sgb3B0aW1hbC4gUGVyaGFwcyB5b3UgY291bGQNCj4gaGF2ZSBt YWRlIHRoaXMgY29tbWVudCBkdXJpbmcgY2hhcnRlcmluZy4NCj4gQnV0IGZyb20gYW5vdGhlciBw ZXJzcGVjdGl2ZSBpdCBlbmFibGVzIHNvbWUgaW5pdGlhbCBwcm9ncmVzcyBpbiBhIG5ldw0KPiBz dWJqZWN0IHNwYWNlIHRoYXQgdGhlIElFVEYgaGFzIG5vdCBwcmV2aW91c2x5IGF0dGVtcHRlZC4g SWYgaXQgaXMNCj4gc3VjY2Vzc2Z1bCB3ZSBjYW4gZGlnIGRlZXBlci4NCj4gDQo+IE92ZXJhbGwg KHNldHRpbmcgYXNpZGUgdGhlIGZhY3QgdGhhdCB3ZSBhcmUgYW55d2F5IGNvbnN0cmFpbmVkIGJ5 IG91cg0KPiBjaGFydGVyKSBJIGhhdmUgYSBmZWFyIG9mIG9jZWFuLWJvaWxpbmcuIEJ1dCBzb21l IGVhcmx5LCBwcmVjYXV0aW9uYXJ5DQo+IG1vZHVsYXJpc2F0aW9uIGlzIG5vdCBnb2luZyB0byBi ZSBhIHByb2JsZW0gc28gbG9uZyBhcyB3ZSBkb24ndCBzcGVuZA0KPiB0b28gbG9uZyBhcmd1aW5n IGFib3V0IGV4YWN0bHkgd2hhdCB0byBtb2R1bGFyaXNlLg0KPiANCj4gQWRyaWFuDQo+IA0KPiAN Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IEwzc20gbWFpbGluZyBsaXN0DQo+IEwzc21AaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sM3NtDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zDQo+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j DQo+IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXoNCj4gcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyDQo+IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcw0KPiBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQo+IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lDQo+IG91IGZhbHNpZmll LiBNZXJjaS4NCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkDQo+IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7DQo+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kDQo+IGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBi ZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlDQo+ IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMM3Nt IG1haWxpbmcgbGlzdA0KPiBMM3NtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbDNzbQ0K From nobody Thu Jul 23 03:19:49 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56031A033A for ; Thu, 23 Jul 2015 03:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mRRp7aUEFi8k for ; Thu, 23 Jul 2015 03:19:46 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2814F1A0338 for ; Thu, 23 Jul 2015 03:19:42 -0700 (PDT) Received: from [86.189.4.239] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZIDb0-0002m7-6O; Thu, 23 Jul 2015 11:19:22 +0100 Date: Thu, 23 Jul 2015 11:19:29 +0100 From: Rob Shakir To: 'Kireeti Kompella' , "=?utf-8?Q?Scharf=2C_Michael_(Michael)?=" , "=?utf-8?Q?adrian=40olddog.co.uk?=" , "=?utf-8?Q?stephane.litkowski=40orange.com?=" , "=?utf-8?Q?l3sm=40ietf.org?=" Message-ID: In-Reply-To: <655C07320163294895BBADA28372AF5D484379B9@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> <029d01d0c479$dc07ccd0$94176670$@olddog.co.uk> <10361_1437568788_55AF8F14_10361_7312_1_9E32478DFA9976438E7A22F69B08FF92166A3977@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <655C07320163294895BBADA28372AF5D484379B9@FR712WXCHMBA15.zeu.alcatel-lucent.com> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55b0bfb1_2096b6f2_17e" Archived-At: Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 10:19:49 -0000 --55b0bfb1_2096b6f2_17e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 23 July 2015 at 11:15:26, Scharf, Michael (Michael) (michael.scharf=40= alcatel-lucent.com) wrote: > > But some early, precautionary modularisation is not going to be a=C2=A0= > problem so long as we don't spend too long arguing about exactly what=C2= =A0 > to modularise.=C2=A0 >=C2=A0 > =46ully agree ..., some sections Kireeti was mentioning are evident to = be=C2=A0 > as a reusable component so we can do it now, for more complex things,=C2= =A0 > let's think about it after the module is (almost) finished.=C2=A0 There is great value in having a consistent model without complex externa= l dependencies, and we should aim at publishing that model soon. This sig= nificantly simplifies implementation.=C2=A0 Can you clarify which implementation you mean here, please=3F IMHO =E2=80= =94 there is a set of one off implementation effort to support the model = in a network mgmt system - but there is the implementation of changes acr= oss a set of services offered by an operator. I expect that more changes = happen within the operator=E2=80=99s services (new hardware, new constrai= nts from suppliers or external network dependencies being removed, new cu= stomer requirements) than happen for the NMS needing to support different= model features (from what I see today), hence, it=E2=80=99d be good to h= ave a debate as to which implementations we want to simplify. An approach that makes changes to services hard or costly to implement fo= r operators will result in any models produced in the IET=46 being unusab= le, or not helping with the current complexities we have. Best, r. --55b0bfb1_2096b6f2_17e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi, folks:

The draft minutes for L3SM at P= rague have just been uploaded

https://www.ietf.org/proceedings/9= 3/minutes/minutes-93-l3sm

Thanks Susan Hares for scribing= .

Please reply to the list if you= have any comments, addition and correction.

 

-Qin/Adrian (L3SM co-chairs)

--_000_B8F9A780D330094D99AF023C5877DABA847D1ED7nkgeml501mbschi_-- From nobody Tue Jul 28 08:34:37 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E231ACCFF for ; Tue, 28 Jul 2015 08:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 4eliSPR9pGDG for ; Tue, 28 Jul 2015 08:34:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0790.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:790]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B85D1ACCFB for ; Tue, 28 Jul 2015 08:34:33 -0700 (PDT) Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none; Received: from [172.29.35.108] (66.129.241.14) by BN3PR0501MB1090.namprd05.prod.outlook.com (10.160.113.12) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 28 Jul 2015 15:34:16 +0000 To: , "l3sm@ietf.org" References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> <55AFE9C4.5070704@juniper.net> <29351_1437643806_55B0B41E_29351_10618_1_9E32478DFA9976438E7A22F69B08FF92166A402F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <55B13F23.4030001@juniper.net> <12269_1437986269_55B5EDDD_12269_740_1_9E32478DFA9976438E7A22F69B08FF92166A4D53@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Eric C Rosen Message-ID: <55B7A0F4.8050007@juniper.net> Date: Tue, 28 Jul 2015 11:34:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <12269_1437986269_55B5EDDD_12269_740_1_9E32478DFA9976438E7A22F69B08FF92166A4D53@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: SN1PR0501CA0028.namprd05.prod.outlook.com (25.163.126.166) To BN3PR0501MB1090.namprd05.prod.outlook.com (25.160.113.12) X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 2:VwSBNwhhoUVgcg3sjflTUViyVMRklHyXv/NOXJuX52F7zV35IMQhVSJjj9D4osXKkrBV56m90U06Q5XsSptkxGPzrfS09HVLno+qRg1FjU8QkC+59IUM1/q/bM1T7LqbUfts0W0GpQHfPvG5Jj5Ak1d2Aji/16oqh/0SxZALZsw=; 3:3bq6cvQJMpVDq9y9oE6hizZrnY1YegsuVvFLnhX/EHnDlLkU9soL2CyKLc3oQ8STIve56gCxqQBVfI+zaL1csdqw+V63tIv2dp2/e2NqIqJ8QqIZbu5Rt9FIGSuw3TLYnollufAAGXzaw35aCGtAcg==; 25:oh2BM9gagQnGDChXQC7JGUdwxuiN/yMZJbc2HmdghJn35QRK00eBQMLgu/euDGczwpqVbmV+ZMmvTGMWOB+PlPijTYFz4zaviWyiznwhfwUhEl5TWOTOFfHoU8i/RBnWKtovqeyxljosGhqkqvh5+xzCqr3KmJKw6u3p7EgUmJCUEF3GHKCXJXa4h4c1ONY3DHgayFtx+qkaPLzVZzW9wirVEUO3Xj5v2tFcWONluoc2uZceux21MuL7YD/aaIDUxOkBVbYPO6KkdKjSEqs9NA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1090; X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 20:bOS2OQ14SkIvpqUwXofgmTBHrpCE5fwwIU7F2iSO3ZLxAJtkBBmO7ONsHgnS42fCBT+OgRZHqbk4gGgTuOEjvsyR2YvietZLrirfOU0Moe4aX4NzNn6KRNGQnSEPD3VeW2YAVOR3VKxuefLIXnfbSbNbvcMMA2sbZ5LvwYylVa4CV4Gp/VbYcpDrQceYQMYuv56LuyIDgv7mezUAneVjoczj4lhKOUxKUMH4iRNf+SGDGdPDuL6AJfhkERilodrapT2Canwmlrs5r10Ss3WFfS4kq+Y8w98vVeZfX5ffqrnT2czh9nMG7Vm+D+OYjUvE9oUkqNtf0av4xcs7Pp8O2K5BMRpP4QXOULxBjqGwkXO09EjXhRtKifixY887Ysz4gIt7UK3KxA89i8vDTPtnKtLscK1BDJf95iYXpeHW+NzdWqqGAsLom0LBm0dE0YVCvqg4C/dmRAkinQHENf91/2+GHThtDAetMItVfldG+CubTyiDqlYpY3bMPoW0B9xe; 4:ej0tpkxW//CcX6bGL9X0h2j5F2LMDkzNKNDbnVoXiEiTewynMRsRlcok7qMfa4IHPx0O6uIln9oF45Zux54I0oa12eVqTK7BW1ifeBU64gtC03P+ENWCTqN8ubdty8HdCeNqkSmwIgzQYdxqqb+uPjBdmCEbQ9h3jBYa+k+X5hOs0XwLoFcHgxKRunFD6L3/UUzON/9pnk7qHhHsUBO42aY1XbmEtXaidlsWmopHxpE52QGlQu80M1fA1L1z7vDwWgGjwtOps5xpgjkfLy/27fAGIM52Id3YGY04BXNhyNw= BN3PR0501MB1090: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN3PR0501MB1090; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1090; X-Forefront-PRVS: 06515DA04B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(479174004)(377454003)(24454002)(54356999)(65816999)(107886002)(76176999)(65806001)(42186005)(50986999)(83506001)(64126003)(23676002)(93886004)(87266999)(86362001)(19580395003)(80316001)(4001350100001)(122386002)(40100003)(5001770100001)(47776003)(36756003)(189998001)(62966003)(46102003)(33656002)(5001960100002)(77156002)(2950100001)(2501003)(230783001)(66066001)(65956001)(92566002)(77096005)(19580405001)(59896002)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1090; H:[172.29.35.108]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjA1MDFNQjEwOTA7MjM6T29jYkZmYW9SbmN2MW1JRS9Nb0FkNFhS?= =?utf-8?B?NVp3alRrZUxZU08wMEYwcFUxZXlvQ1h3QmYxZk1BTkMyZStuc3hieWpUQzBs?= =?utf-8?B?d1pNblhiUkVYaWExVEg4RXRVTGVrcmNaaDkydnAzcm9xUFlPR1psbUJZWmNz?= =?utf-8?B?Z1ZFdzE1YXcyanFZamRnYkZ3TVBoeDBsRlR0OWpvLzVETDk3YkJ4SWZBRmly?= =?utf-8?B?dVRrWDlOdENGMEtuWnJiTnErQXROTFRSZFVSWGtQaWtBMVNoSmhpWGY2aFlB?= =?utf-8?B?K1l4c294ZlAyVHVkY2RHcWRsUUMwUzN2SXRkaDVsb3k4OTJhM0o5NllQTlRN?= =?utf-8?B?QnpsVEt0N1orNjNGUm5Qc0ZUanRxM2p1cFZVMncxV3duUXoxRnF4dGtFWkVO?= =?utf-8?B?SHlzaUFqa3pmZEFic0lsZW5oWkZvNStnYjBmQ2JVbDljK2dpNlN6blFYN2I2?= =?utf-8?B?Tk9mdUwwbHhrYkh2YUVvdnJYWEltL0JKbnl2UGlIaHZVMWp0V1Q0RThCcTZ4?= =?utf-8?B?cFJ6Wno0akp6UXdsUm5KYkhFbTJ2eFZRMlBCSGRnLzBwc1UwUFZPRXZsMDJB?= =?utf-8?B?SDVvQWdQRFBRb0ZCL2VoY0hSVGE5RjYwelozOVl2MGRMWU9TaUw5SlN1a3Y4?= =?utf-8?B?cXQzYXIycDJVVmlNMDErS3J4RHc5aFlFVnJJMUdMVGd3d2o5alJJVnk5ckRV?= =?utf-8?B?QnpaWXZ5TmNtOEt4Q3V0bldrZ0VGaFJseE1VQ1BwVEkySEh1TjAyV3VndUM3?= =?utf-8?B?QnJad2ZLNFdGQkprcXp1bHBhWjVWZVo1Vm9mY1I5U0Z2UFIxMGpIRXd3bUdR?= =?utf-8?B?eEZjZ3RXQWJhYjM4K0dwcE1aVjBUWURkdVhOenhmSU51SUhTUEc1RGRGME8y?= =?utf-8?B?d3BRekU3N2FKSDAzRkxPeTJjWW4zYVArYUVqc1N1VVJSbjM4RExlcEcxZ2Mv?= =?utf-8?B?MUdITDRnOHJuOUIzRnFvem9mRkg2MEtzcjY0WG50aTZWNVpNRXJSUGh6SnFl?= =?utf-8?B?YnBPNHEzbnZxV2pNVGV5ZVNWOG1kTjMybXdzYit1Z2w0TXhEOUttdFpNT3BQ?= =?utf-8?B?M1BkV0RWRWFyUVBjTGt4ZTA2NEl3NzlyRHZFMzJoL01pN05kVkc5UWJnYlZB?= =?utf-8?B?MlZUVGhVdXdxTm0zRkg4WXhrOFlCZ3N2Z3dLd0c2NUpEQVpqd3QwS25idFlL?= =?utf-8?B?K2hvemNBd3RrOGxFeWJ1VC9EMWJZdDV3V2RMcS9hTFRYaytJRXdON1M2Z1dl?= =?utf-8?B?L3lWd1JZNFAwOEhzZDlkeVRibnNRTHFGaHFiZlh0dnRUOUM3YWxKcDZqZ3Qx?= =?utf-8?B?TnY0ZG95a2hFdi9ZMTJFOUJxdVYxOWpxamd5TVA0bUU0WFUxZzFJUWNBcmdD?= =?utf-8?B?N1BBajhOSWhTN2QzRUNKeGQ0TVVvVkpIRE9GSkxDKzRSVVNtcDJEU0hieGxn?= =?utf-8?B?UFdRdURWSjhlbkIvdCtxdXRUbjFUWnlrbXpjdGEreUNneFEyTnVKYzh2T3JJ?= =?utf-8?Q?abOvSD6z89A3uTT07ioxJ4ZV6cc=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR0501MB1090; 5:ip1bWCjZs2hD5AY7rNs24yJtfVBjq72tUyn622V36Pf2c38uHPmvLPFcK6fP7bM3I9/MCx9sbRCur1+nqMaL3x0S7BxS5HS6jp/bzhNfQ6fUexjVd/EHqzeyLVo5Qvjk+03DwCpwUi7BfD/ZKNzY0g==; 24:241A1X21Lhg7L8EGXUg9mpzwBun0bo+Ja1hY+pY8TPHoal5W2PUP9dkVbI5WvgJFPdmvL/aaR/jjUSG7gtPNRT/aeSu+Xw8wsALy399qiDg=; 20:nWX6A2ji5Aec9oPhx9wK16oXxIfKkO9JhKJo9GGGu0XmPsZT1SBlGKQ+ttQmmJPiZXQWjfQ84U0kNCIV8sSjbg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2015 15:34:16.8762 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1090 Archived-At: Cc: erosen@juniper.net Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 15:34:35 -0000 On 7/27/2015 4:37 AM, stephane.litkowski@orange.com wrote: > [SLI] in my mind, if the referenced IP address is an IP address > located on a PE, then the RP is the PE. If the referenced address is any anycast address, how do you know whether it is "located on a PE" or not? I'd have thought that the decision to assign the anycast address to the RP is based on whether or not you are offering the RP-as-PE service to the customer. Similarly, if you are offering BIDIR-PIM support to a customer by using the technique of section 11.1 of RFC6513, I don't think it's enough just to specify the RPA in the service model; you have to have some information that determines whether or not the PE has to advertise to the CE a route to the RPA. From nobody Fri Jul 31 04:19:23 2015 Return-Path: X-Original-To: l3sm@ietfa.amsl.com Delivered-To: l3sm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AB31A07BC for ; Fri, 31 Jul 2015 04:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 LbZJcn-E_9I5 for ; Fri, 31 Jul 2015 04:19:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8C01A070E for ; Fri, 31 Jul 2015 04:19:20 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id E8A362DC0EE; Fri, 31 Jul 2015 13:19:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id CC5D423805E; Fri, 31 Jul 2015 13:19:18 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0248.002; Fri, 31 Jul 2015 13:19:18 +0200 From: To: Eric C Rosen , "l3sm@ietf.org" Thread-Topic: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model Thread-Index: AQHQw8X3K3YLZClNO0qpeZYxRBC/cp3nugYAgADZWqCAAL2YgIAFtW5AgAHmOwCABJDzUA== Date: Fri, 31 Jul 2015 11:19:18 +0000 Message-ID: <10406_1438341558_55BB59B6_10406_52_1_9E32478DFA9976438E7A22F69B08FF92166BAF97@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <4B3B6546-2150-4EFB-B580-587A9EAD1E82@gmail.com> <55AFE9C4.5070704@juniper.net> <29351_1437643806_55B0B41E_29351_10618_1_9E32478DFA9976438E7A22F69B08FF92166A402F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <55B13F23.4030001@juniper.net> <12269_1437986269_55B5EDDD_12269_740_1_9E32478DFA9976438E7A22F69B08FF92166A4D53@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <55B7A0F4.8050007@juniper.net> In-Reply-To: <55B7A0F4.8050007@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.16.85415 Archived-At: Subject: Re: [L3sm] Comments on draft-ietf-l3sm-l3vpn-service-model X-BeenThere: l3sm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: L3VPN Service YANG Model discussion group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 11:19:22 -0000 QWdyZWUsIHdlIHdpbGwgZmluZCBhIHdheSB0byBleHByZXNzIGl0IGZyb20gYW4gYWJzdHJhY3Rp b24gcG9pbnQgb2Ygdmlldy4gRG8geW91IGhhdmUgYWxyZWFkeSBzb21ldGhpbmcgaW4gbWluZCA/ DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmljIEMgUm9zZW4gW21haWx0 bzplcm9zZW5AanVuaXBlci5uZXRdIA0KU2VudDogVHVlc2RheSwgSnVseSAyOCwgMjAxNSAxNzoz NA0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBTQ0UvSUJORjsgbDNzbUBpZXRmLm9yZw0KQ2M6IGVy b3NlbkBqdW5pcGVyLm5ldA0KU3ViamVjdDogUmU6IFtMM3NtXSBDb21tZW50cyBvbiBkcmFmdC1p ZXRmLWwzc20tbDN2cG4tc2VydmljZS1tb2RlbA0KDQpPbiA3LzI3LzIwMTUgNDozNyBBTSwgc3Rl cGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20gd3JvdGU6DQo+IFtTTEldIGluIG15IG1pbmQsIGlm IHRoZSByZWZlcmVuY2VkIElQIGFkZHJlc3MgaXMgYW4gSVAgYWRkcmVzcyANCj4gbG9jYXRlZCBv biBhIFBFLCB0aGVuIHRoZSBSUCBpcyB0aGUgUEUuDQoNCklmIHRoZSByZWZlcmVuY2VkIGFkZHJl c3MgaXMgYW55IGFueWNhc3QgYWRkcmVzcywgaG93IGRvIHlvdSBrbm93IHdoZXRoZXIgaXQgaXMg ImxvY2F0ZWQgb24gYSBQRSIgb3Igbm90PyAgSSdkIGhhdmUgdGhvdWdodCB0aGF0IHRoZSBkZWNp c2lvbiB0byBhc3NpZ24gdGhlIGFueWNhc3QgYWRkcmVzcyB0byB0aGUgUlAgaXMgYmFzZWQgb24g d2hldGhlciBvciBub3QgeW91IGFyZSBvZmZlcmluZyB0aGUgUlAtYXMtUEUgc2VydmljZSB0byB0 aGUgY3VzdG9tZXIuDQoNClNpbWlsYXJseSwgaWYgeW91IGFyZSBvZmZlcmluZyBCSURJUi1QSU0g c3VwcG9ydCB0byBhIGN1c3RvbWVyIGJ5IHVzaW5nIHRoZSB0ZWNobmlxdWUgb2Ygc2VjdGlvbiAx MS4xIG9mIFJGQzY1MTMsIEkgZG9uJ3QgdGhpbmsgaXQncyBlbm91Z2gganVzdCB0byBzcGVjaWZ5 IHRoZSBSUEEgaW4gdGhlIHNlcnZpY2UgbW9kZWw7IHlvdSBoYXZlIHRvIGhhdmUgc29tZSBpbmZv cm1hdGlvbiB0aGF0IGRldGVybWluZXMgd2hldGhlciBvciBub3QgdGhlIFBFIGhhcyB0byBhZHZl cnRpc2UgdG8gdGhlIENFIGEgcm91dGUgdG8gdGhlIFJQQS4NCg0KCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4K SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFz IGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2Vz IHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91 LgoK