Re: [L3sm] L3SM Meeting at IETF93

[<[e-mail]>]

Hi,

Thanks for your comment, pls see inline

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

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.

[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 [mailto:[e-mail]] On Behalf Of Qin Wu
Sent: Monday, July 20, 2015 10:28 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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

_________________________________________________________________________________________________________________________

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.