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

[Maxim Klyus <[e-mail]>]

Hi Qin,

My comments inline.


>>-----Original Message-----
>>From: Qin Wu [mailto:[e-mail]]
>>Sent: Monday, September 28, 2015 12:19 PM
>>To: Maxim Klyus; [e-mail]
>>Cc: [e-mail]
>>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.

>>>[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] 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.

> [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] 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.

>>>[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] 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)

> [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,  [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
>>>maybe VAS placement matters.

[MK] Need time to think on it.

>>>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] I hope so, option 2 is more interesting.

> [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?

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

>Regards,
>Max Klyus

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

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:[e-mail]]
发送时间: 2015年9月23日 16:38
收件人: [e-mail]; Qin Wu
抄送: [e-mail]
主题: [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:  [e-mail]       |      Owner:  draft-ltsd-l3sm-l3vpn-
     Type:  enhancement              |  [e-mail]
 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.


________________________________
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.


________________________________
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.