Subject: [L3sm] L3 service model suggestion

From: "Aijun Wang" <[email-masked]>
Date: Fri, 26 Feb 2016 09:22:15 +0800

Hi, Lucy:

Is it more clear to put the list site within the list vpn-svc? This
correlate naturally the relationship between vpn id and its associated
sites, and also the attributes of these sites.

For site that belong to multiple vpn, the site' information will be existed
in several specific vpn context. Considering the site's attribute may be
vary for different vpn, it is reasonable for the customer.

For site-template container, I propose:

1.  we change it into grouping site-template, and use it within list sites,
or

2. define the related items directly  within the list sites and eliminate
the site-template container.

Best Regards.

From: L3sm [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, February 25, 2016 11:59 PM
To: [email-masked]
Subject: [L3sm] L3 service model suggestion

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site
containers only. In order to address multiple vpn at one site, we need
vpn-svc per site container too. Some attributes under site container should
belong to vpn-svc per site container such as vpn-policy, service, etc. The
site container needs to have a parameter "multiplexing" to indicate if a
site will have single vpn or multiple vpn. This will address the issue of
multi-vpn at a site discussed in today's interim meeting.

Not sure why need site-template container.

Regards,

Lucy

---

From: Qin Wu <[email-masked]>
Date: Fri, 26 Feb 2016 03:27:21 +0000

Aijun:
I believe what you want is site attribute per vpn-svc while Lucy is talking about vpn-svc per site
They are two different things.

-Qin
发件人: L3sm [mailto:[email-masked]] 代表 Aijun Wang
发送时间: 2016年2月26日 9:22
收件人: Lucy yong; [email-masked]
主题: [L3sm] L3 service model suggestion

Hi, Lucy:

Is it more clear to put the list site within the list vpn-svc? This correlate naturally the relationship between vpn id and its associated sites, and also the attributes of these sites.
For site that belong to multiple vpn, the site’ information will be existed in several specific vpn context. Considering the site’s attribute may be vary for different vpn, it is reasonable for the customer.

For site-template container, I propose:
1.  we change it into grouping site-template, and use it within list sites, or
2. define the related items directly  within the list sites and eliminate the site-template container.

Best Regards.

From: L3sm [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, February 25, 2016 11:59 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [L3sm] L3 service model suggestion

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site containers only. In order to address multiple vpn at one site, we need vpn-svc per site container too. Some attributes under site container should belong to vpn-svc per site container such as vpn-policy, service, etc. The site container needs to have a parameter “multiplexing” to indicate if a site will have single vpn or multiple vpn. This will address the issue of multi-vpn at a site discussed in today’s interim meeting.

Regards,
Lucy

---

From: <[email-masked]>
Date: Fri, 26 Feb 2016 08:28:21 +0000

Hi,

Again,  in a multiVPN scenario, we have a SINGLE logical site so if you use site under vpn-svc you will have to duplicate all the site information (routing-protocols, security , ip addressing ...) and it's useless because it will be exactly the same. So the model becomes really heavy to use while today it's really flexible.
This duplication is a no GO for me. Now if you go to use a reference to a template, it's exactly the same like having a site-list with references only that I proposed, but Michael had a very good argument telling that splitting the site attributes in two subtree is a very bad idea.

I don't really understand the old argument telling that putting sites under vpn is more service oriented. This is for sure another way to model it, but the current way is also service oriented but we separate sites and VPN to have the best flexibility in mapping sites to VPNs. Multiple service providers are using this kind of separation between VPN and sites in their information system today (this was one of the first outcomes when we started this modeling exercice).

Now from an operational point of view (not configuration), people need to easy access the list of sites per VPN, we can create an read-only container for that purpose.

From: L3sm [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Friday, February 26, 2016 02:22
To: 'Lucy yong'; [email-masked]
Subject: [L3sm] L3 service model suggestion

Hi, Lucy:

Is it more clear to put the list site within the list vpn-svc? This correlate naturally the relationship between vpn id and its associated sites, and also the attributes of these sites.
For site that belong to multiple vpn, the site' information will be existed in several specific vpn context. Considering the site's attribute may be vary for different vpn, it is reasonable for the customer.

Best Regards.

Hi All,

Current L3vpn service model (the draft) specifies vpn-svc and site containers only. In order to address multiple vpn at one site, we need vpn-svc per site container too. Some attributes under site container should belong to vpn-svc per site container such as vpn-policy, service, etc. The site container needs to have a parameter "multiplexing" to indicate if a site will have single vpn or multiple vpn. This will address the issue of multi-vpn at a site discussed in today's interim meeting.

Regards,
Lucy

_________________________________________________________________________________________________________________________

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.

---

From: Lucy yong <[email-masked]>
Date: Fri, 26 Feb 2016 15:27:23 +0000

Hi,

Share my 2-cent.

A VPN has a list of sites, which can be covered by the attribute of a list of site under vpn-svc container. This attribute just contains the site reference.
L3SM needs a site container to cover site attributes because individual sites have different properties.
L3SM needs a vpn-svc per site container that contains the attributes for a vpn-svc relevant to a site, i.e. vpn end point at a site.

Using these three containers, we can model a site that can have either single VPN or multiple VPNs.

Does this make a sense?

Thanks,
Lucy

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 26, 2016 2:28 AM
To: Aijun Wang; Lucy yong; [email-masked]
Subject: RE: [L3sm] L3 service model suggestion

Hi,

From: L3sm [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Friday, February 26, 2016 02:22
To: 'Lucy yong'; [email-masked]<mailto:[email-masked]>
Subject: [L3sm] L3 service model suggestion

Hi, Lucy:

Best Regards.

Hi All,

Regards,
Lucy

Thank you.

---

From: Lucy yong <[email-masked]>
Date: Fri, 26 Feb 2016 16:00:35 +0000

Hi Stephane, et al,

I did not understand Michael's previous mail. So just give my opinion. Thank you to point out his concern.

IMO: Our goal here is to work out the model that can cover common L3 VPN services. If a site attaching to multiple VPNs is a common use case, we need to address it. We want to have one service model to cover single VPN and multiple VPN at a site too. I don't see that two list entries is a problem to concern here.

Regards,
Lucy

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, February 26, 2016 9:38 AM
To: Lucy yong; Aijun Wang; [email-masked]
Subject: RE: [L3sm] L3 service model suggestion

Yes this works but this was identified by Michael Scharf as an issue, see mail attached

"would require two different list entries to be present before a site can actually be configured. I would prefer to void such dependencies as far as possible, in order to simplify the use of the model and avoid internal inconsistencies."

From: Lucy yong [mailto:[email-masked]]
Sent: Friday, February 26, 2016 16:27
To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; [email-masked]<mailto:[email-masked]>
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Share my 2-cent.

Does this make a sense?

Thanks,
Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, February 26, 2016 2:28 AM
To: Aijun Wang; Lucy yong; [email-masked]<mailto:[email-masked]>
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Hi, Lucy:

Best Regards.

Hi All,

Regards,
Lucy

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 26 Feb 2016 16:12:19 +0000

>From a service design point of view, it works for me. But I'm not an implementor, so there may be some implementation constraints/requirement that we need also to take care of : so I cannot really go against Michael who provided an implementation view point.

Michael,

May be can you elaborate on the constraints you see by introducing a list of sites (just references) in the vpn-svc container ? Is it strong or not ?

Thx

From: Lucy yong [mailto:[email-masked]]
Sent: Friday, February 26, 2016 17:01
To: LITKOWSKI Stephane SCE/OINIS; Aijun Wang; [email-masked]
Subject: RE: [L3sm] L3 service model suggestion

Hi Stephane, et al,

Regards,
Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, February 26, 2016 9:38 AM
To: Lucy yong; Aijun Wang; [email-masked]<mailto:[email-masked]>
Subject: RE: [L3sm] L3 service model suggestion

Hi,

Share my 2-cent.

Does this make a sense?

Thanks,
Lucy

Hi,

Hi, Lucy:

Best Regards.

Hi All,

Regards,
Lucy

Thank you.

Thank you.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Fri, 26 Feb 2016 16:37:45 +0000

For what it is worth, I am a bit surprised by this discussion on optimizing the model for the multiVPN use case. I am not really aware of a strong interest in this particular use case, but obviously this depends on usage and deployment scenarios.

I'd suggest to keep the model simple for the case of a single VPN. For the vanilla L3VPN use case it would be good to avoid having to manipulate multiple lists, maintain cross-references, etc. Maybe this can be achieved my making all model components only required for multi VPN optional? KISS principle...

Michael

From: L3sm [mailto:[email-masked]] On Behalf Of EXT [email-masked]
Sent: Friday, February 26, 2016 5:12 PM
To: Lucy yong; Aijun Wang; [email-masked]; Scharf, Michael (Nokia - DE)
Subject: Re: [L3sm] L3 service model suggestion

Michael,

Thx

Hi Stephane, et al,

Regards,
Lucy

Hi,

Share my 2-cent.

Does this make a sense?

Thanks,
Lucy

Hi,

Hi, Lucy:

Best Regards.

Hi All,

Regards,
Lucy

Thank you.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Fri, 26 Feb 2016 17:14:24 +0000

Hi Michael,

Regarding our customers, I can tell that most of the big accounts are using multiVPN (or even all of them ?), subVPN is less used but there is an interest also.
MultiVPN is really typical scenario.

Best Regards,

From: Scharf, Michael (Nokia - DE) [mailto:[email-masked]]
Sent: Friday, February 26, 2016 17:38
To: LITKOWSKI Stephane SCE/OINIS; Lucy yong; Aijun Wang; [email-masked]
Subject: RE: [L3sm] L3 service model suggestion

Michael

From: L3sm [mailto:[email-masked]] On Behalf Of EXT [email-masked]<mailto:[email-masked]>
Sent: Friday, February 26, 2016 5:12 PM
To: Lucy yong; Aijun Wang; [email-masked]<mailto:[email-masked]>; Scharf, Michael (Nokia - DE)
Subject: Re: [L3sm] L3 service model suggestion

Michael,

Thx

Hi Stephane, et al,

Regards,
Lucy

Hi,

Share my 2-cent.

Does this make a sense?

Thanks,
Lucy

Hi,

Hi, Lucy:

Best Regards.

Hi All,

Regards,
Lucy

Thank you.

Thank you.

Thank you.