Re: [L3sm] L3SM Meeting at IETF93

"Aijun Wang" <wangaijun@tsinghua.org.cn> Tue, 21 July 2015 02:26 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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 <l3sm@ietfa.amsl.com>; 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 <l3sm@ietfa.amsl.com>; 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 <l3sm@ietf.org>; 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 <wangaijun@tsinghua.org.cn>
To: 'Qin Wu' <bill.wu@huawei.com>, l3sm@ietf.org
References: <B8F9A780D330094D99AF023C5877DABA847CF5C4@nkgeml501-mbs.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA847CF5C4@nkgeml501-mbs.china.huawei.com>
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: <http://mailarchive.ietf.org/arch/msg/l3sm/tN6mxL8DH1SNtfx_DeINngEHzew>
Cc: adrian@olddog.co.uk, 'Chongfeng Xie' <xiechf@ctbri.com.cn>
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 <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2015 02:26:30 -0000

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