Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

From: Maxim Klyus <[email-masked]>
Date: Fri, 25 Sep 2015 12:32:43 +0000

Dear Qin,

You are absolutely right, my initial proposal focused on the VAS service, but when this particular VAS is exactly the solid part of the VPN service, in other words when impossible to deliver VPN service itself without this VAS, because of SP can have some specifically defined VPN service provisioning schemas (with additional components like vCPE, vCE, vPE... etc). So VPN service here will be depended on this VAS.
As you fairly noted the VPN service also can be delivered with such VASs as FW, DPI, etc... however VPN service will be independent from this VASs.
Also you are right it will really hard to list all possible services and I think we definitely don't need to do it.

So I see 2 possible options how to solve above problem:

1) In scope of the existing l3sm-l3vpn service draft:
 define a generic VAS leaf

generic-vas-components-leaf
    +--vas-component                                          reference  (ref to specific service-model which can be delivered later.....vCPE, vCE, FW)
           +--description                                          string
           +--vas-component-type                          enumeration (mandatory/optional) <--indicates VPN service dependency
           +--vas-component-redundancy             enumeration  (yes/no)

OR

2) In scope of the L3SM group:
define a generic service model / customer faced service template (technology independent) which can refers to service specific models

generic-service-model
    +--name                                                                   string     <--- this attribute will be moved from the existing L3vpn model
    +--id                                                                          uint32    <--- this attribute will be moved from the existing L3vpn model
    +--customer-name                                                  string     <--- this attribute will be moved from the existing L3vpn model
    +--admin-state                                                        enumeration (enabled/disabled)
    +--oper-state                                                            enumeration (enabled/disabled)
    +--service-components
         +--service-component                                        reference  (ref to specific service-model...l3vpn, FW, DPI)
               +--service-component-description            string
               +--service-component-type                         enumeration (mandatory/optional)  <--indicates type of dependency
               +--service-component-redundancy            enumeration  (yes/no)

Best Regards,
Max Klyus

发件人: l3sm issue tracker [mailto:[email-masked]]
发送时间: 2015年9月23日 16:38
收件人: [email-masked]; Qin Wu
抄送: [email-masked]
主题: [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

#7: Generic VAS

 Nowadays, VPNs are generally selled with VAS options.
 some examples of VASs that are generally added on top of a VPN include:
 -       Cloud access with FW
 -       Internet access with FW + possibly Web content filtering
 -       DPI
 -       Acceleration

 Maxim Klyus proposed to define Generic VAS leaf with similar redundant  parameters for L3VPN service.
 Maxim Klyus also viewed CloudAccess as one example of Generic VAS.

 However there are many many services, it is challenging to list all of  them.Do we need to consider VAS in the L3SM service model? Do we need to  have a seperate model to provide VAS support by augumenting L3SM service  model?

--
-------------------------------------+----------------------------------
-------------------------------------+---
 Reporter:  [email-masked]       |      Owner:  draft-ltsd-l3sm-l3vpn-
     Type:  enhancement              |  [email-masked]
 Priority:  minor                    |     Status:  new
Component:  draft-ltsd-l3sm-l3vpn-   |  Milestone:
  service-model                      |    Version:
 Severity:  -                        |   Keywords:  VAS
-------------------------------------+----------------------------------
-------------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/l3sm/trac/ticket/7>
l3sm <http://tools.ietf.org/l3sm/>

________________________________
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 28 Sep 2015 09:24:00 +0800

Hi, Maxim:

Would you like to give some VAS examples that the VPN service must dependent on? For such VAS services, it should be defined within the current VPN service model. For other VPN independent service, such as DPI, FW etc., we should define separate service models. In order to begin such work, the chart of the L3SM should be updated first? 

Aijun Wang

China Telecom Corporation Limited Beijing Research Institute 
Intelligent Network Product Line

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Friday, September 25, 2015 8:33 PM
To: [email-masked]
Cc: Qin Wu
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

________________________________
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
_______________________________________________
L3sm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l3sm

---

From: Qin Wu <[email-masked]>
Date: Mon, 28 Sep 2015 09:18:38 +0000

Maxim:
The options you gave below are interesting, I am wondering how do we model characteristics for each VAS,
I see the only characteristics you want VAS to have is redundancy, or high availability?
Is there any other characteristics we should also consider? Regarding redundancy, do we need to distinct active-active from active-standby, do we need to support N+1 redundancy or other type of redundancy?

In addition, How VAS characteristics are different from standard VPN service?
I believe VAS is more policy driven and rely on topology information such as VLANs or packet (re)classification to determine service policy selection, I am wondering whether packet classification is needed for VAS just as we did for standard VPN service. 

Also VAS can act on network layer or other OSI layer, do we need to care which layer it is applied? Do we need to distinct VAS placed within the site from VAS placed between any two site?
What else we need to consider? Transport dependency? Traffic Selection?

-Qin
-----邮件原件-----
发件人: Maxim Klyus [mailto:[email-masked]] 
发送时间: 2015年9月25日 20:33
收件人: [email-masked]
抄送: Qin Wu
主题: RE: [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: Qin Wu <[email-masked]>
Date: Mon, 28 Sep 2015 09:19:29 +0000

Aijun:
VAS can be additional service offered by L3VPN service provider to customer using IP infrastructure besides standards service offering. 
VPN service doesn't need to depend on any VAS service if VAS is offered by the third party or other ASP.
but blending VAS into VPN service can make customer receive something beyond their basic needs.
Therefore VAS can be part of VPN service if VAS service leverages the same IP infrastructure used for VPN service.

-Qin
-----邮件原件-----
发件人: Aijun Wang [mailto:[email-masked]] 
发送时间: 2015年9月28日 9:24
收件人: 'Maxim Klyus'; [email-masked]
抄送: Qin Wu
主题: RE: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi, Maxim:

Aijun Wang

China Telecom Corporation Limited Beijing Research Institute Intelligent Network Product Line

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Friday, September 25, 2015 8:33 PM
To: [email-masked]
Cc: Qin Wu
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: Maxim Klyus <[email-masked]>
Date: Mon, 28 Sep 2015 09:53:20 +0000

Hi Ajun,

As I said in my previous letter depending on service provisioning schema and definitions where our VPN service starts and ends, theoretically we can put absolutely any specific details inside term VPN service, but I don't think it will be good solution, because it will be absolutely not scalable.  Simple example of VPN service dependency - SP can have some mandatory requirements like all VPN services should be provisioning through virtual CPE/ virtual CE and  vCPE, vCE also separate services in this case, because it could be provided by itself, but VPN service in this case can't be provided without vCPE/vCE service.
I'm not sure I'm competent enough to answer the last question.

Best Regards,
Max Klyus

-----Original Message-----
From: Aijun Wang [mailto:[email-masked]]
Sent: Monday, September 28, 2015 4:24 AM
To: Maxim Klyus; [email-masked]
Cc: 'Qin Wu'
Subject: RE: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi, Maxim:

Aijun Wang

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Friday, September 25, 2015 8:33 PM
To: [email-masked]
Cc: Qin Wu
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: Maxim Klyus <[email-masked]>
Date: Mon, 28 Sep 2015 10:33:54 +0000

Hi, Qin.

My answers inline.

-----Original Message-----
From: Qin Wu [mailto:[email-masked]]
Sent: Monday, September 28, 2015 12:19 PM
To: Maxim Klyus; [email-masked]
Cc: [email-masked]
Subject: RE: [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Maxim:
[Qin] The options you gave below are interesting, I am wondering how do we model characteristics for each VAS, I see the only characteristics you want VAS to have is redundancy, or high availability?
[Qin] Is there any other characteristics we should also consider? Regarding redundancy, do we need to distinct active-active from active-standby, do we need to support N+1 redundancy or other type of redundancy?

[MK] good pointing it might be useful.

[Qin] In addition, How VAS characteristics are different from standard VPN service?
[Qin] I believe VAS is more policy driven and rely on topology information such as VLANs or packet (re)classification to determine service policy selection, I am wondering whether packet classification is needed for VAS just as we did for
[Qin] standard VPN service.

[MK] Here I'm not sure I'm on the same page with you, because in my mind VAS service should be the reference to another service model.
[MK] I don't want to put every VAS details within VPN model because I don't think it will be the good solution.
[MK] But yes VAS can contain a reference to IETF QoS classification service model which already exist and can be used for traffic reclassification.

[Qin] Also VAS can act on network layer or other OSI layer, do we need to care which layer it is applied? Do we need to distinct VAS placed within the site from VAS placed between any two site?
[Qin] What else we need to consider? Transport dependency? Traffic Selection?

[MK] I'm not sure again. Yes, theoretically we can call - "VAS" everything, but in my mind it should be reference to some models we can define (or already defined by IETF) and reuse later.
[MK] Let take some concrete example like vCPE/vCE https://tools.ietf.org/html/draft-fu-dmm-vcpe-models-00
[MK] vCPE can cover many OSI layers, but I really don't know what we need to consider about this fact?
[MK] VAS in the middle is possible, good example btw, but I don't see if VAS placement plays much sense.
[MK] Traffic selection (path selection?) is more addressed to TE models if I understand you right.

Regards,
Max Klyus

-Qin
-----邮件原件-----
发件人: Maxim Klyus [mailto:[email-masked]]
发送时间: 2015年9月25日 20:33
收件人: [email-masked]
抄送: Qin Wu
主题: RE: [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 29 Sep 2015 09:32:38 +0800

Hi, Maxim and Qin:

L3VPN is one kind of service provided by the ISP's infrastructure network, and other VAS services just accompany it(as mentioned in another mail from Qin: " ....but blending VAS into VPN service can make customer receive something beyond their basic needs. Therefore VAS can be part of VPN service if VAS service leverages the same IP infrastructure used for VPN service."). So I prefer we defines or extract the VAS service model out of the basic L3VPN service model.
Virtual CE/virtual CPE is another kind of service and can/should also be defined separately. Such virtual service will be just treated as one normal network node, and should be referred within the L3VPN service model, if they have some special characteristic that different from the physical CPE or CE.

Aijun Wang

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Monday, September 28, 2015 5:53 PM
To: Aijun Wang; [email-masked]
Cc: 'Qin Wu'
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi Ajun,

Best Regards,
Max Klyus

-----Original Message-----
From: Aijun Wang [mailto:[email-masked]]
Sent: Monday, September 28, 2015 4:24 AM
To: Maxim Klyus; [email-masked]
Cc: 'Qin Wu'
Subject: RE: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi, Maxim:

Aijun Wang

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Friday, September 25, 2015 8:33 PM
To: [email-masked]
Cc: Qin Wu
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: Qin Wu <[email-masked]>
Date: Tue, 29 Sep 2015 03:24:48 +0000

Hi, Maxim:
-----邮件原件-----
>发送时间: 2015年9月28日 18:34
>收件人: Qin Wu; [email-masked]
>抄送: [email-masked]

My answers inline.

>> [Qin] I believe VAS is more policy driven and rely on topology information such as VLANs or packet (re)classification to determine service policy selection, I am wondering whether packet 
>>classification is needed for VAS just as we did for

> [MK] Here I'm not sure I'm on the same page with you, because in my mind VAS service should be the reference to another service model.

[Qin]: If my understanding your proposal correctly, you propose VAS service model to reference a new service model unspecified. The new service model include vCPE service model, vCE service model, FW service model, etc.
I have a little concern about this. Since these new models are not specified, to make L3SM service model to reference these new model means L3SM service model adds dependency on these new service model, we end up with never finishing L3SM service model without starting to work on these new service model.

> [MK] I don't want to put every VAS details within VPN model because I don't think it will be the good solution.

[Qin]: Yes, I agree we don't need to put VAS details, but we should add key requirements for VAS from customer perspective. E.g., redundancy or resilience is one of key requirements for VAS.

> [MK] I'm not sure again. Yes, theoretically we can call - "VAS" everything, but in my mind it should be reference to some models we can define (or already defined by IETF) and reuse later.

[Qin]: That's a good point, We should reference that is more relevant to L3VPN service model, e.g.,
https://tools.ietf.org/html/draft-rfernando-bess-service-chaining-01
https://tools.ietf.org/html/draft-fm-bess-service-chaining-01
https://tools.ietf.org/id/draft-fang-l3vpn-data-center-interconnect-03.txt
https://tools.ietf.org/id/draft-fang-l3vpn-virtual-ce-03.txt
https://tools.ietf.org/html/draft-ietf-bess-virtual-pe-00

we should also reference some other work that have already been defined by IETF, more focus on the work that should at least be working group draft or a document agreed by IETF working group.
https://tools.ietf.org/html/draft-ietf-bess-virtual-pe-00
right now, virtual CE hasn't get agreed by BESS working group. Virtual PE got a good progress and have become a WG draft.

> [MK] Let take some concrete example like vCPE/vCE https://tools.ietf.org/html/draft-fu-dmm-vcpe-models-00

[Qin]: The idea of vCPE is just to shift functionality provided by CPE to the network side.
Do you think vCPE or vCE is a VAS or not? I thought L4 to L7 service function can be regarded as VAS.

> [MK] vCPE can cover many OSI layers, but I really don't know what we need to consider about this fact?

[Qin]: You are right, whether it is layer 4 or layer 7, it doesn't matter. 
>[Qin]: The reason to consider this is we have various VAS located from Layer 4 to Layer 7,

[Qin]: Yes, VAS can be placed anywhere as the customer wants. If we consider a set of VAS placement, e.g.,
https://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases
maybe VAS placement matters.

We should make sure which scenario the L3SM service model is dealing with?
(1) Service model that is only applied to traditional L3VPN network, the traditional L3VPN 
is extended to DC network through vPE, vPE is only deployed in DC network,
L3SM service model provides cloud access container to
allow customer in the traditional L3VPN network to access to internet or Cloud/DC network. 
(2) Service model that is generic enough to apply to not only traditional L3VPN network but also DC network,
I hope we are dealing with (2).

> [MK] Traffic selection (path selection?) is more addressed to TE models if I understand you right.

[Qin]: See
https://tools.ietf.org/html/rfc7498
I am wondering how many requirements applied to Service chaining are also applied to VAS?

-Qin
-----邮件原件-----
发件人: Maxim Klyus [mailto:[email-masked]]
发送时间: 2015年9月25日 20:33
收件人: [email-masked]
抄送: Qin Wu
主题: RE: [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: Qin Wu <[email-masked]>
Date: Tue, 29 Sep 2015 08:14:49 +0000

Aijun:
How we gonna characterize Generic VAS from customer perspective? I would encourage to discuss how generic VAS service can be modeled.
Is redundancy parameters or resilience parameters sufficient enough to describe Generic VAS characteristics?
I believe these are something we should dig into and explore first.

-Qin
-----邮件原件-----
发件人: Aijun Wang [mailto:[email-masked]] 
发送时间: 2015年9月29日 9:33
收件人: 'Maxim Klyus'; Qin Wu
抄送: [email-masked]
主题: RE: [L3sm] [l3sm] #7 (draft-ietf-l3sm-l3vpn-service-model): Generic VAS

Hi, Maxim and Qin:

Aijun Wang

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Monday, September 28, 2015 5:53 PM
To: Aijun Wang; [email-masked]
Cc: 'Qin Wu'
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi Ajun,

Best Regards,
Max Klyus

-----Original Message-----
From: Aijun Wang [mailto:[email-masked]]
Sent: Monday, September 28, 2015 4:24 AM
To: Maxim Klyus; [email-masked]
Cc: 'Qin Wu'
Subject: RE: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi, Maxim:

Aijun Wang

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Friday, September 25, 2015 8:33 PM
To: [email-masked]
Cc: Qin Wu
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: <[email-masked]>
Date: Tue, 29 Sep 2015 17:24:09 +0000

Hi all,

To be honest, I'm not sure we need to go too deep in VAS.
Yes VAS are critical pieces for L3VPN services : we do not sell anymore VPNs without VAS :)
But clearly the charter of L3SM is focused on L3 VPN  only that means IMO transport only.

Trying to accomadate VAS in a generic way is a complex modeling that would require more time and as I said, it should be out of scope of this work (Chairs to confirm ...)

Now there is one "VAS" that I would like to keep : the cloud access. Because cloud access is not a VAS as a DPI or FW or others ... it only defines a transport interconnection between VPNs (Customer VPN and Cloud VPN). This interconnection is a bit similar to interAS gateways (that we also need to think about ...). That why I think this could be in the scope of this model, while FW, DPI or generic structures of advanced services are out ...

Best Regards,

Stephane

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, September 28, 2015 11:19
To: Aijun Wang; 'Maxim Klyus'; [email-masked]
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Aijun:

-Qin
-----邮件原件-----
发件人: Aijun Wang [mailto:[email-masked]] 
发送时间: 2015年9月28日 9:24
收件人: 'Maxim Klyus'; [email-masked]
抄送: Qin Wu
主题: RE: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi, Maxim:

Aijun Wang

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Friday, September 25, 2015 8:33 PM
To: [email-masked]
Cc: Qin Wu
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

_________________________________________________________________________________________________________________________

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: Rob Shakir <[email-masked]>
Date: Tue, 29 Sep 2015 18:45:37 +0100

On 29 September 2015 at 18:24:33, [email-masked] ([email-masked]) wrote:
> Now there is one "VAS" that I would like to keep : the cloud access. Because cloud access  
> is not a VAS as a DPI or FW or others ... it only defines a transport interconnection between  
> VPNs (Customer VPN and Cloud VPN). This interconnection is a bit similar to interAS gateways  
> (that we also need to think about ...). That why I think this could be in the scope of this  
> model, while FW, DPI or generic structures of advanced services are out ...

I strongly agree with Stephane here. In addition to it adding significant scope to the model, it also seems (to me) very unlikely that we can cater for all the nuances of different service provider’s offerings.

IMHO, the L3SM model should act as a ‘base’ for service-provider specific service models to be built on top of - which means that it is fair to take more complex features out of scope.

r.

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 29 Sep 2015 19:01:33 +0000

Hi Qin,

My comments inline.

>>Maxim:
>> [Qin] The options you gave below are interesting, I am wondering how
>>do we model characteristics for each VAS, I see the only characteristics you want VAS to have is redundancy, or high availability?
>> [Qin] Is there any other characteristics we should also consider?
>>Regarding redundancy, do we need to distinct active-active from active-standby, do we need to support N+1 redundancy or other type of redundancy?

>> [Qin] I believe VAS is more policy driven and rely on topology
>>information such as VLANs or packet (re)classification to determine
>>service policy selection, I am wondering whether packet classification
>>is needed for VAS just as we did for

>>>I have a little concern about this. Since these new models are not specified, to make L3SM service model to reference these new model means L3SM service model adds dependency on these new service model, we end up with never >>>finishing L3SM service model without starting to work on these new service model.

[MK] You are correct regarding my proposal, but I don't think we need to concern much about "dependency fact" because in my perception we just keep the opportunity to use other IETF models (existing or TBD) for the L3SM model. In other
[MK] words L3SM model don't need to be dependent on other models since it just can refer to it in terms of VAS leaf where we defining only basic generic attributes not more.

>> [Qin] Also VAS can act on network layer or other OSI layer, do we
>>need to care which layer it is applied? Do we need to distinct VAS placed within the site from VAS placed between any two site?

> [MK] Let take some concrete example like vCPE/vCE
> https://tools.ietf.org/html/draft-fu-dmm-vcpe-models-00

>>>Do you think vCPE or vCE is a VAS or not? I thought L4 to L7 service function can be regarded as VAS.

[MK] I think vCPE and vCE are definitely the VASs (constituent VAS if I will be more exact). In my understanding VAS - is something can be proposed to customer as finished service (customer faced).
[MK] But you are right VAS also can be represented with more simple services based on L4 and L7 functions (DPI, Firewall,NAT, etc...) and even L3 (like virtual routers)

>[Qin]: The reason to consider this is we have various VAS located from
>Layer 4 to Layer 7,  [MK] VAS in the middle is possible, good example btw, but I don't see if VAS placement plays much sense.

>>>[Qin]: Yes, VAS can be placed anywhere as the customer wants. If we consider a set of VAS placement, e.g., https://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases

[MK] Need time to think on it.

>>>(1) Service model that is only applied to traditional L3VPN network, the traditional L3VPN is extended to DC network through vPE, vPE is only deployed in DC network, L3SM service model provides cloud access container to allow customer in >>>the traditional L3VPN network to access to internet or Cloud/DC network.
>>>(2) Service model that is generic enough to apply to not only traditional L3VPN network but also DC network, I hope we are dealing with (2).

[MK] I hope so, option 2 is more interesting.

>>>I am wondering how many requirements applied to Service chaining are also applied to VAS?

[MK] Here I'm not sure if SFC can be recognized like a VAS.

-Qin
-----邮件原件-----
发件人: Maxim Klyus [mailto:[email-masked]]
发送时间: 2015年9月25日 20:33
收件人: [email-masked]
抄送: Qin Wu
主题: RE: [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: Maxim Klyus <[email-masked]>
Date: Tue, 29 Sep 2015 19:18:28 +0000

Hi Stephane,

I agree with you, we absolutely don't need to go deep.
The only proposal from my side is just to make VAS generic (with really basic attributes) and define it like a reference in order to be able connect it to future an existing IETF work.

Best Regards,
Max Klyus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, September 29, 2015 8:24 PM
To: Qin Wu; Aijun Wang; Maxim Klyus; [email-masked]
Subject: RE: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi all,

To be honest, I'm not sure we need to go too deep in VAS.
Yes VAS are critical pieces for L3VPN services : we do not sell anymore VPNs without VAS :) But clearly the charter of L3SM is focused on L3 VPN  only that means IMO transport only.

Best Regards,

Stephane

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, September 28, 2015 11:19
To: Aijun Wang; 'Maxim Klyus'; [email-masked]
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Aijun:

-Qin
-----邮件原件-----
发件人: Aijun Wang [mailto:[email-masked]]
发送时间: 2015年9月28日 9:24
收件人: 'Maxim Klyus'; [email-masked]
抄送: Qin Wu
主题: RE: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi, Maxim:

Aijun Wang

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Friday, September 25, 2015 8:33 PM
To: [email-masked]
Cc: Qin Wu
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

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: Qin Wu <[email-masked]>
Date: Wed, 30 Sep 2015 02:55:00 +0000

-----邮件原件-----
发件人: Maxim Klyus [mailto:[email-masked]] 
发送时间: 2015年9月30日 3:02
收件人: Qin Wu; [email-masked]
抄送: [email-masked]
主题: RE: [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi Qin,

My comments inline.

>>>I have a little concern about this. Since these new models are not specified, to make L3SM service model to reference these new model means L3SM service model adds dependency on these new service…

[MK] You are correct regarding my proposal, but I don't think we need to concern much about "dependency fact" because in my perception we just keep the opportunity to use other IETF models (existing or TBD) for the L3SM model. In other [MK] words L3SM model don't need to be dependent on other models since it just can refer to it in terms of VAS leaf where we defining only basic generic attributes not more.

[Qin]: Right now, we only have one service model, that is L3VPN service model.
In your option (1), it doesn't need to reference existing service model(L3VPN service model) since VAS you proposed is part of L3VPN service model, but you need to reference some service models that haven't been defined yet, it is not reasonable to do this, I think the right approach is to defined other service models first, and then we can add reference to these new service models in the L3VPN service model

In the option (2), you may not follow L3SM session in Prague meeting, L3VPN service model developed right now in L3SM WG is
(a) specific to L3VPN,but could be generic to apply to other service, 
(b) limited to L3VPN, but could be extended to L2VPN in the future which requires recharter.
Right now L3VPN service model follows modularity approach and contain quite a lot of generic components that can be reused in the other type of VPN service models, What we really need to explore is whether there is possibility to extend L3VPN service model to support L2VPN service, DC VPN service or how L2VPN service, DC VPN service can be modeled differently from L3VPN service model before we go for generic service model. 

Also if Generic VAS is not part of L3VPN service model, I doubt it is in the scope of L3SM WG.

>>>https://tools.ietf.org/id/draft-fang-l3vpn-data-center-interconnect-0
>>>3.txt https://tools.ietf.org/id/draft-fang-l3vpn-virtual-ce-03.txt

[Qin]: I think DC overlay service model or Cloud VPN service model could follow the similar model structure proposed by L3VPN service model.

[Qin]:Yes, SFC can not be views as VAS, what I suggest is to sort out SFC service requirements or characteristics that are also applied to VAS.

-Qin
-----邮件原件-----
发件人: Maxim Klyus [mailto:[email-masked]]
发送时间: 2015年9月25日 20:33
收件人: [email-masked]
抄送: Qin Wu
主题: RE: [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: Qin Wu <[email-masked]>
Date: Wed, 30 Sep 2015 03:50:13 +0000

-----邮件原件-----
>发件人: [email-masked] [mailto:[email-masked]] 
>发送时间: 2015年9月30日 1:24
>收件人: Qin Wu; Aijun Wang; 'Maxim Klyus'; [email-masked]

>To be honest, I'm not sure we need to go too deep in VAS.

[Qin]: I will not encourage authors of draft-ietf-l3sm-l3vpn-service-model to delve into VAS too much. But I did see some interests within L3SM WG in this topic.
We should not prevent people to make some survey in this area and discuss it. 
yes, we should make sure we are on the right direction. But it will be great to let people to discuss what VAS service characteristics look like and how much complexity it add.

>Yes VAS are critical pieces for L3VPN services : we do not sell anymore VPNs without VAS :) But clearly the charter of L3SM is focused on L3 VPN  only that means IMO transport only.

[Qin]: Good point.

>Trying to accommodate VAS in a generic way is a complex modeling that would require more time and as I said, it should be out of scope of this work (Chairs to confirm ...)

[Qin]:
With co-chair hat on …
I believe Generic VAS support is out of scope of L3SM service model work since based on current charter L3SM WG has short timeframe and we should focus basic L3VPN service.
but how L3VPN service model is extended to support VAS or even complicated Service chaining is still an interesting topic.  We should look at it after we complete L3SM service model work. 
With co-chair hat off …
From discussion we had so far on list, I see to support VAS (whether it is in the L3VPN service model or not )is still pretty much premature since we don't have any VAS service model that has been developed yet, we don't have a good foundation or existing IETF work that is concrete enough for us to define these VAS model. Unless we get concrete proposal for VAS support, we should not add this to L3VPN service model.

>Now there is one "VAS" that I would like to keep : the cloud access. Because cloud access is not a VAS as a DPI or FW or others ... it only defines a transport interconnection between VPNs > (Customer VPN and Cloud VPN). This interconnection is a bit similar to interAS gateways (that we also need to think about ...). That why I think this could be in the scope of this model, while FW, >DPI or generic structures of advanced services are out ...

[Qin]: Yes, Cloud access also provides internet access support or define transport interconnection between Customer VPN and internet. I agree we should keep cloud access in this work.

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, September 28, 2015 11:19
To: Aijun Wang; 'Maxim Klyus'; [email-masked]
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Aijun:

-Qin
-----邮件原件-----
发件人: Aijun Wang [mailto:[email-masked]]
发送时间: 2015年9月28日 9:24
收件人: 'Maxim Klyus'; [email-masked]
抄送: Qin Wu
主题: RE: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Hi, Maxim:

Aijun Wang

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Maxim Klyus
Sent: Friday, September 25, 2015 8:33 PM
To: [email-masked]
Cc: Qin Wu
Subject: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

Dear Qin,

OR

generic-service-model

Best Regards,
Max Klyus

#7: Generic VAS

---

From: Qin Wu <[email-masked]>
Date: Wed, 30 Sep 2015 04:01:43 +0000

Okay, let us close this issue as open issue for L3SM service model work(i.e., draft-ietf-l3sm-l3vpn-service-model) and leave this for further discussion when we need to extend L3SM model to support VAS in the future.
Thanks Maxim, Aijun, Stephane and Rob to get this issue closed.

-Qin
-----邮件原件-----
发件人: Rob Shakir [mailto:[email-masked]] 
发送时间: 2015年9月30日 1:46
收件人: Qin Wu; Aijun Wang; 'Maxim Klyus'; [email-masked]; [email-masked]
主题: Re: [L3sm] [l3sm] #7 (draft-ltsd-l3sm-l3vpn-service-model): Generic VAS

On 29 September 2015 at 18:24:33, [email-masked] ([email-masked]) wrote:
> Now there is one "VAS" that I would like to keep : the cloud access. 
> Because cloud access is not a VAS as a DPI or FW or others ... it only 
> defines a transport interconnection between VPNs (Customer VPN and 
> Cloud VPN). This interconnection is a bit similar to interAS gateways 
> (that we also need to think about ...). That why I think this could be in the scope of this model, while FW, DPI or generic structures of advanced services are out ...

r.