Re: [L3sm] L3SM Meeting at IETF93

<> Tue, 21 July 2015 16:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F20B1B2F74 for <>; Tue, 21 Jul 2015 09:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GInOY35XI0ZQ for <>; Tue, 21 Jul 2015 09:16:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89D261A8AAB for <>; Tue, 21 Jul 2015 09:16:19 -0700 (PDT)
Received: from (unknown [xx.xx.xx.200]) by (ESMTP service) with ESMTP id CD974C09A6; Tue, 21 Jul 2015 18:16:17 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (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
To: Aijun Wang <>, 'Qin Wu' <>, "" <>
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$>
In-Reply-To: <012101d0c35c$955b2390$c0116ab0$>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166A344BOPEXCLILMA4corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.7.21.153615
Archived-At: <>
Cc: "" <>, 'Chongfeng Xie' <>
Subject: Re: [L3sm] L3SM Meeting at IETF93
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


Thanks for your comment, pls see inline

From: L3sm [] On Behalf Of Aijun Wang
Sent: Tuesday, July 21, 2015 04:26
To: 'Qin Wu';
Cc:; 'Chongfeng Xie'
Subject: Re: [L3sm] L3SM Meeting at IETF93

Hi, all:

I read the slides that posted  at, 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.

[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 particular VPN.

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.
[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 service provider" ?
I definitely agree that not having the LAN segmentation would clearly simplify but I think we cannot avoid it.

Aijun Wang

China Telecom Corporation Limited Beijing Research Institute
Intelligent Network Product Line

From: L3sm [] On Behalf Of Qin Wu
Sent: Monday, July 20, 2015 10:28 PM
Subject: [L3sm] L3SM Meeting at IETF93


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

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

The meeting Room is Karlin I/II.



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.