Subject: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

From: Dmytro Shytyi <[email-masked]>
Date: Thu, 05 Sep 2019 18:02:59 +0200

Dear All,

Please find the updated version of the VYSM Internet Draft(v0.2).

The new version of draft introduces an extension of the yang model defined in previous version. From now the VYSM supports (0day configuration)/(bootstrap) of the VNFs hosted in the uCPE.

With 0day configuration in the uCPE we can setup minimal required configuration of vRouter (such as ip address, hostname,etc..), SD-WAN (address of the SD-WAN manager, dhcp activation, etc..), etc..

Details:

A new version of I-D, draft-shytyi-netmod-vysm-02.txt 

has been successfully submitted by Dmytro Shytyi and posted to the 

IETF repository. 

Name:        draft-shytyi-netmod-vysm 

Revision:    02 

Title:        Virtualization YANG Servise Model (VYSM) 

Document date:    2019-09-04 

Group:        Individual Submission 

Pages:        10 

URL: https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-02.txt 

Status: https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/ 

Htmlized: https://tools.ietf.org/html/draft-shytyi-netmod-vysm-02 

Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm 

Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-netmod-vysm-02 

Abstract: 

This document provides a specification of the Virtual Network 

Functions YANG Service Model (VYSM). The VNF YANG Service Model 

serves as a base framework for managing an universal Customer- 

Premises Equipment (uCPE) NFV subsystem from the Orchestrator. 

>># # # : Dmytro Shytyi [mailto:mailto:[email-masked]]

>># # # # : 2019# 8# 28#  21:46

>># # # : Robert Varga <mailto:[email-masked]>; Qin Wu <mailto:[email-masked]>

>># # : netmod <mailto:[email-masked]>

>># # : Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.

>>Hello,

>>Please find comments inline.

>>>On 27/08/2019 18:03, Dmytro Shytyi wrote:

>>>> Dear All,

>>>> I am one of the authors of ID VYSM and I would like to draw your

>>>> attention to the evolution of the

>>>> draft https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt.

>>>> Recently we produced (but did not submitted yet) a new version of ID

>>>> (02) and I beleive it fits the netmod working group.

>>>> We would be gratefull if you could suggest if the new version(02) of the

>>>> document  could become an official work item of the WG?

>>>>       If yes, could you please indicate which modifications must be done

>>>> in the document before submition.

>>>Hmm, looking over the model, it would seem there is quite a bit of

>>>overlap with RFC8345 -- to the point I believe the model could be

>>>formulated in terms of RFC8345 specialization:

>>First of all I would like to thank you for this comment. 

>>-Dmytro

>>>virtualization -> networks/network

>>>device/links/interfaces/switches/vms are probably a mix of

>>>node/termmination-point/link extensions with conjunction with

>>>supporting-{topology,node,link}.

>>I can imagine mapping:

>>virtualization (ID) -> networks/network (RFC 8345)

>>links (ID)- >link;(RFC 8345)

>>ports (ID)-> termination points;(RFC 8345)

>>But still.. it seems here we have to create extension of the model proposed in RFC 8345.

>>Precisely for node (RFC 8345) we may add types (switches, vms) and futer add leafs /listsfor type if required (ex: #RAM,#vCPUs and other leafs for VMs)

>>-Dmytro

>>>How would the draft relate to RFC8345? Should it perhaps call out it is

>>>a different take on the similar problem, specialized to a particular

>>>use-case?

>>One can suggest that  in the RFC8345 Figure 1, the block "service Topology model" can include the proposed in the draft network service descriptor with appropriate modification of mapping according to the RFC8345.

>>Meanwhile I find that the proposed solution(ID) try to solve the problem descibed below:

>>The uCPE management mechanism may involve not only YANG modules but  also the speficif logic written in programming languages. The proposed organisation of yang model is an attempt to find the best fit  for combination (YANG modules + specific logic written in python for example )  to manage different existing NFVIs in the uCPE (by the orchestrator).

>>In the case of uCPE, the mapping (w/wo additinal logic) of "variables " between service yang modules (in the orchestrator) and NETCONF payload(that is sent to the uCPE) will be more complex (requires additional transformations in the logic) with generic approach, then the solution presented in the ID, that is tailored to the uCPE. 

>>Therefore I find the proposed solution as a stadalone generic approach to manage multiple vendor uCPE that appears to be a particular case tailored for uCPE NFVIs that may be not nesseraly follows RFC8345. I would be pleased if you could comment this.

>>-Dmytro

>>>Regards,

>>>Robert (with RFC8345 co-author hat on)

>>>+1, in addition, I am wondering whether this is something related to overlay topology model, if yes, how it is different from DC Fabric topology model defined in RFC8542? 

>>>-Qin 

>>Thank you for your comment. The RFC8542 condisers PODs in the DC network. uCPE is located on the customer site. if we consider that uCPE is A POD (with links and nodes like VMs and swithces) then in the RFC8542 describes different PODs in the network that are interconnected with links. The yang model proposed in the ID ifocuses only on the uCPE interiour network service, not the interconnection between the uCPEs. Aslo, I explained the difference about extension neded for type of nodes,vms leafs and furter complexity in the mapping logic in the reponce to Robert.

>>-Dmytro

>>[Qin]:So you focus on interconnection between local vPE and remote vPE?

>[Dmytro]:

>Thank you for this question. It seems that the next version of draft should include the explanation of the uCPE interiour network service.

>Example: We can have multiple VMs instantiated in the uCPE (vFW,vRouter/vCPE,SD-WAN). With support of links and swithes  VMs may create a service chains.

>Example of service chains:

>1)WAN--vRouter(vCPE)-link-uCPEvSW -link2-vFirewall-LAN

>2)WAN--SDWAN--vFirewall--LAN

>>It is not clear whether we should distinguish VM from switch. In my understanding, Upon VNF is instantiated, there is no difference between virtual and physical worlds.

>[Dmytro]:

>The VM/VNF in the uCPE could be a vROuter or Vfirewall or an SD-WAN that is not a default part of virtual network resources of the uCPE (chapter 3 in the ID).

>The switch (ex. Open vSwith) in the uCPE is a default part of uCPE network virtual resources (chapter 3 in the ID).

>Thus we need to distingish swithes and VNFs to not to mix uCPE network virtual resources and VNFs.

>Another reason why the destingishing is required: because VM and SW have different device-attributes. SW does not require VNFD attributtes.

>If we do not distinguish nodes, and only extend the grouping "device attributes" for required attributes the switch will have the properties that are  unused leafs which represent the VM-device-attributes.

>>VNF lifecycle management is separated from topology construction, wrong?

>[Dmytro]:

>a) In case of the NFVIs uCPE the same High Level interface allows to configure both topology construction and VM lifecycle management in the same transaction.

>b) We can not activate Network Service Descriptor without consituent VM node information. At the moment of NSD activation we already have to set the VM node information such as VM capabilities that can be created (previosly)/(at the moment of configuration of NSD) but have to be a part of the network service descriptor at the moment of activation.

>[Dmytro]

>The Internet Draft also defines the term uCPE that is not defined at IETF yet.

>_______________________________________________

>netmod mailing list

>mailto:[email-masked]

>https://www.ietf.org/mailman/listinfo/netmod

______________
Dmytro SHYTYI

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 5 Sep 2019 11:27:10 -0700

I find the representation of a service model in this draft for a uCPE as too simple. In reality, on a uCPE, you could be running a Network Service (NS), which is composed of multiple VNFs interconnected together. This service model does not address such a configuration. Besides, how is the configuration of a uCPE device for a VNF different from configuration of a VNF in a provider Network Function Virtualization Infrastructure (NFVI) like OpenStack or VMware VIO? And would you not need to enable the service on the provider side to make the services running on the uCPE functional?

There is significant amount of work that has been done in ETSI on the configuration and management of VNF and NS. Authors should spend some time going through the specifications specified by ETSI to make sure they are not re-specifying work that has been done there, and instead see how they could augment the work that has already been defined.

Authors can start by going through IFA010 <https://docbox.etsi.org/ISG/NFV/Open/Publications_pdf/Specs-Reports/NFV-IFA%20010v3.1.1%20-%20GS%20-%20MANO%20Functional%20Rqmts%20Spec.pdf>,  IFA011 <https://docbox.etsi.org/ISG/NFV/open/Publications_pdf/Specs-Reports/NFV-IFA%20011v3.1.1%20-%20GS%20-%20VNF%20Packaging%20Spec.pdf>, IFA014 <https://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/031/03.01.01_60/gs_nfv-ifa031v030101p.pdf>, and its YANG specification in SOL006 <https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/006/02.06.01_60/gs_nfv-sol006v020601p.pdf>.

Cheers.

> On Sep 5, 2019, at 9:02 AM, Dmytro Shytyi <[email-masked]> wrote:
> 
> Dear All,
> 
> URL: https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-02.txt <https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-02.txt> 
> Status: https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/ <https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/> 
> Htmlized: https://tools.ietf.org/html/draft-shytyi-netmod-vysm-02 <https://tools.ietf.org/html/draft-shytyi-netmod-vysm-02> 
> Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm <https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm> 
> Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-netmod-vysm-02 <https://www.ietf.org/rfcdiff?url2=draft-shytyi-netmod-vysm-02> 
> 
> Abstract: 
> >># # # : Dmytro Shytyi [mailto:[email-masked] <mailto:[email-masked]>]
> >># # # : Robert Varga <[email-masked] <mailto:[email-masked]>>; Qin Wu <[email-masked] <mailto:[email-masked]>>
> >># # : netmod <[email-masked] <mailto:[email-masked]>>
> >>>> draft https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt <https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt>.
> >>One can suggest that  in the RFC8345 Figure 1, the block "service Topology model" can include the proposed in the draft network service descriptor with appropriate modification of mapping according to the RFC8345..
> >>
> >[email-masked] <mailto:[email-masked]>
> >https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> ______________
> Dmytro SHYTYI
> 
> 
> 
> 
> [email-masked]

Mahesh Jethanandani
[email-masked]

---

From: Dmytro Shytyi <[email-masked]>
Date: Thu, 05 Sep 2019 23:03:26 +0200

[Dmytro]
Hello Mahesh Jethanandani,

Thank you for your comment.

Please find answers inline.

>I find the representation of a service model in this draft for a uCPE as too simple. In reality, on a uCPE, you could be running a Network Service (NS), which is composed of multiple VNFs interconnected together. This service model does not address such a configuration.

[Dmytro]

This service model presented in the draft supports N VMs in the NS and addreses configuration with multiple VMs and switches with plenty of links. It is well tested (with service chained VMs) on equipent from different well known suppliers. The idea to have complex flexible service in the network service orchestrator for uCPE.

in the yang model we have list (marked by pyang with "*") of VMs where the key is name of the vm, thus you may define as much VM as you wish.

Example of 2 VMs that are service chained (swLAN-VM1-swService-VM2-swWAN)

      +--rw vms* [vm]

                      +--rw vm             string

                      +--rw ports* [port]

                      |  +--rw port    string

                      |  +--rw name?   string

                      |  +--rw link?   -> ../../../links/link

                      +--rw ram?           string

                      +--rw cpu?           string

                      +--rw storages* [id]

                      |  +--rw id          string

                      |  +--rw location?   string

                      +--rw day0-config

                         +--rw location?        string

                         +--rw day0-var-path?   string

                         +--rw variable* [name]

                            +--rw name     string

                            +--rw value?   string

So basically  the list "+--rw wms* [vm]" can be represented/"expanded" in this way where the names and number ov vms(N) is set by user:

 >>>>>       +--rw vm1             string

                       |     +--rw ports* [port]

                       |     |  +--rw port    string

                       |     |  +--rw name?   string

                       |     |  +--rw link?   -> ../../../links/link

                       |     +--rw ram?           string

                       |     +--rw cpu?           string

                       |     +--rw storages* [id]

                       |     |  +--rw id          string

                       |     |  +--rw location?   string

                       |     +--rw day0-config

                       |     |  +--rw location?        string

                       |     |  +--rw day0-var-path?   string

                       |     |  +--rw variable* [name]

                       |     |     +--rw name     string

                       |     |     +--rw value?   string

>>>>>        +--rw vm2             string

                       |     +--rw ports* [port]

                       |     |  +--rw port    string

                       |     |  +--rw name?   string

                       |     |  +--rw link?   -> ../../../links/link

                       |     +--rw ram?           string

                       |     +--rw cpu?           string

                       |     +--rw storages* [id]

                       |     |    +--rw id          string

                       |     |  +--rw location?   string

                       |     +--rw day0-config

                       |     |    +--rw location?        string

                       |     |  +--rw day0-var-path?   string

                       |     |  +--rw variable* [name]

                       |     |     +--rw name     string

                       |     |     +--rw value?   string

                        ....

                      |                      

 >>>>>       +--rw vmN             string

                            +--rw ports* [port]

                            |  +--rw port    string

                            |  +--rw name?   string

                            |  +--rw link?   -> ../../../links/link

                            +--rw ram?           string

                            +--rw cpu?           string

                            +--rw storages* [id]

                            |  +--rw id          string

                            |  +--rw location?   string

                            +--rw day0-config

                               +--rw location?        string

                               +--rw day0-var-path?   string

                               +--rw variable* [name]

                                  +--rw name     string

                                  +--rw value?   string

>Besides, how is the configuration of a uCPE device for a VNF different from configuration of a VNF in a provider Network Function Virtualization Infrastructure (NFVI) like OpenStack or VMware VIO?

[Dmytro]

Modern uCPE support netconf. And if you go to the YANG RFC6020 you will find the next statement:

   "YANG is a data modeling language used to model configuration and

   state data manipulated by the Network Configuration Protocol

   (NETCONF), NETCONF remote procedure calls, and NETCONF notifications."

When we talk about Openstack it is YAML, not YANG. 

>And would you not need to enable the service on the provider side to make the services running on the uCPE functional?

[Dmytro]

Indeed, to manage the uCPE located on the client side we need to enable the provider side. The presented model is this actually "sits" in orchestaror that is located on the provider side. In the draft it is mentioned that it is "network service yang model- NSYM" that is in the orchestrator (according to the rfc8199).

[Dmytro]

The uCPE management mechanism(in the service provider network service orchestrator)  may involve not only YANG modules but also the speficic logic written in programming languages. The proposed organisation of yang model is a solution that provides the best fit for combination (YANG modules + specific logic written in python for example )  to manage different existing NFVIs in the uCPE (by the orchestrator).

In the case of uCPE, the mapping (w/wo additinal logic) of "variables " between service yang modules (in the orchestrator) and NETCONF payload(that is sent to the uCPE) will be more complex (requires additional transformations in the logic) with generic approach, then the solution presented in the ID, that is tailored to the uCPE.Therefore I find the proposed solution as a stadalone generic approach to manage multiple vendor uCPE that appears to be a particular case tailored for uCPE NFVIs that may be not nesseraly follows RFC8345. I would be pleased if you could comment this.

>Authors can start by going through IFA010,  IFA011, IFA014, and its YANG specification in SOL006.

[Dmytro]

I would like to draw your attention that these documents seems to be directed to the generic solution including also cloud environment, that brings a lot of complexity. There is some difference between cloud and client site.

For example, case for VNFD, in the cloud we need to have flavours, different VDUs For VNFD, to change the VM capacities according to the load as we have the extendible infrastructure.

The ucpe has limited resources, not as a cloud infrastructure in the data center.

For example, in the case of NSD: NSD includes the VLD that defines Virtual Links. But in the uCPE case you may have virtual links + virtual switches that are not part of the NSD defined in the ETSI.

For example, i'm not avare of VNFD that brings option of (0day configuration)/bootstrap for VNF. Moreover in the proposed model there is a possibility to set variables that will be substituted in the ".iso" bootstrap image (ex.cloudinit) that is assigned to the VM in the uCPE.

Thus the generic solution of ETSI leads to more complex implementations of the code that is responsible for mapping between YANG/XML when the solution proposed in the Inernet Draft is tailored to the uCPE use-case and should bring the simplisity when developping the mapping logic and inroduce features that are not presented by ETSI.

>>On Sep 5, 2019, at 9:02 AM, Dmytro Shytyi <mailto:[email-masked]> wrote:

>>A new version of I-D, draft-shytyi-netmod-vysm-02.txt\A0

>>has been successfully submitted by Dmytro Shytyi and posted to the\A0

>>IETF repository.\A0

>>Name:\A0\A0\A0\A0\A0\A0\A0\A0draft-shytyi-netmod-vysm\A0

>>Revision:\A0\A0\A0\A002\A0

>>Title:\A0\A0\A0\A0\A0\A0\A0\A0Virtualization YANG Servise Model (VYSM)\A0

>>Document date:\A0\A0\A0\A02019-09-04\A0

>>Group:\A0\A0\A0\A0\A0\A0\A0\A0Individual Submission\A0

>>Pages:\A0\A0\A0\A0\A0\A0\A0\A010\A0

>>URL: https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-02.txt\A0

>>Status: https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/\A0

>>Htmlized: https://tools.ietf.org/html/draft-shytyi-netmod-vysm-02\A0

>>Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm\A0

>>Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-netmod-vysm-02\A0

>>Abstract:\A0

>>This document provides a specification of the Virtual Network\A0

>>Functions YANG Service Model (VYSM). The VNF YANG Service Model\A0

>>serves as a base framework for managing an universal Customer-\A0

>>Premises Equipment (uCPE) NFV subsystem from the Orchestrator.\A0

>>>># # # # : 2019# 8# 28#\A0 21:46

>>>>>>\A0

>>>>>> draft\A0https://http://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt.

>>>>>>\A0

>>>>>> document\A0 could become an official work item of the WG?

>>>>>> \A0 \A0 \A0 If yes, could you please indicate which modifications must be done

>>>>>\A0

>>>>First of all I would like to thank you for this comment.\A0

>>>>>\A0

>>>>One can suggest that\A0 in the RFC8345 Figure 1, the block "service Topology model" can include the proposed in the draft network service descriptor with appropriate modification of mapping according to the RFC8345..

>>>>The uCPE management mechanism may involve not only YANG modules but\A0 also the speficif logic written in programming languages. The proposed organisation of yang model is an attempt to find the best fit\A0 for combination (YANG modules + specific logic written in python for example )\A0 to manage different existing NFVIs in the uCPE (by the orchestrator).

>>>>In the case of uCPE, the mapping (w/wo additinal logic) of "variables " between service yang modules (in the orchestrator) and NETCONF payload(that is sent to the uCPE) will be more complex (requires additional transformations in the logic) with generic approach, then the solution presented in the ID, that is tailored to the uCPE.\A0

>>>>>+1, in addition, I am wondering whether this is something related to overlay topology model, if yes, how it is different from DC Fabric topology model defined in RFC8542?\A0

>>>>>-Qin\A0

>>>Example: We can have multiple VMs instantiated in the uCPE (vFW,vRouter/vCPE,SD-WAN). With support of links and swithes\A0 VMs may create a service chains.

>>>If we do not distinguish nodes, and only extend the grouping "device attributes" for required attributes the switch will have the properties that are\A0 unused leafs which represent the VM-device-attributes.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 5 Sep 2019 18:43:05 -0700

Hi Dmytro,

First of all, I find the discussion within the netmod WG as just the wrong place to have this discussion. You will be hard pressed to find too many people who can give you critical feedback on the model in this WG.

See inline with [mj]

> On Sep 5, 2019, at 2:03 PM, Dmytro Shytyi <[email-masked]> wrote:
> 
> [Dmytro]

[mj] You have introduced concept of interfaces, ports, and switches that does not exist in the NFV world. VNFs have virtual links and connection points. There is no (physical) port or interface that one connects to in a VNF. It might exist on the server on which the VM runs but not in a VNF or a virtualization instance.

>  >>>>>       +--rw vm1             string
>  >>>>>       +--rw vmN             string

[mj] I understand how you instantiate multiple VMs. What I do not understand is for example, your representation of a link. Currently, it points to a link definition within the same Virtualization instance. How does that tell me what is it connected to?

Why is CPU defined as a string? And what does “Amount of cpus” mean? Number of CPUs? Same for RAM.

Also VMs have images and storage. If your storage is an image, where is the storage (disk) definition? 

Again, definition of CPUs, RAM, storage belong in a VNF Descriptor (VNFD), not in a service model. One needs that information at the time of instantiation of a VNF, not at the time of turning up a service.

> When we talk about Openstack it is YAML, not YANG. 

[mj] If I give you a YANG model to configure OpenStack, tell me how would that be different from configuring a uCPE?

> Indeed, to manage the uCPE located on the client side we need to enable the provider side. The presented model is this actually "sits" in orchestaror that is located on the provider side. In the dr…

[mj] By sitting in the orchestrator, you have not defined how the service on the provider side is enabled.

> The uCPE management mechanism(in the service provider network service orchestrator)  may involve not only YANG modules but also the speficic logic written in programming languages. The proposed org…

[mj] IETF does not specify implementation or logic written in a programming language.

> In the case of uCPE, the mapping (w/wo additinal logic) of "variables " between service yang modules (in the orchestrator) and NETCONF payload(that is sent to the uCPE) will be more complex (requir…

[mj] To me this sounds like an implementation level detail for a uCPE. Again, not something that IETF standardizes. 

> The ucpe has limited resources, not as a cloud infrastructure in the data center.

[mj] Define a single flavor in case of uCPE and keep it simple.

> For example, in the case of NSD: NSD includes the VLD that defines Virtual Links. But in the uCPE case you may have virtual links + virtual switches that are not part of the NSD defined in the ETSI.

[mj] But you are allowed to define more than 2 links. Why do you need to define a switch?

> For example, i'm not avare of VNFD that brings option of (0day configuration)/bootstrap for VNF. Moreover in the proposed model there is a possibility to set variables that will be substituted in t…

[mj] That is considered part of the workflow. Your workflow engine will allow you to set variables that are substituted in the ISO image or when the image boots up.

> The Internet Draft also defines the term uCPE that is not defined at IETF yet.

[mj] I do not think this is the right WG or even the right body to standardize this model.

Mahesh Jethanandani
[email-masked]

> 
> >>On Sep 5, 2019, at 9:02 AM, Dmytro Shytyi <[email-masked] <mailto:[email-masked]>> wrote:
> >>Dear All,
> >>URL: https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-02.txt\A0 <https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-02.txt/A0>
> >>Status: https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm/\A0 <https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm//A0>
> >>Htmlized: https://tools.ietf.org/html/draft-shytyi-netmod-vysm-02\A0 <https://tools.ietf.org/html/draft-shytyi-netmod-vysm-02/A0>
> >>Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm\A0 <https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm/A0>
> >>Diff: https://www.ietf.org/rfcdiff?url2=draft-shytyi-netmod-vysm-02\A0 <https://www.ietf.org/rfcdiff?url2=draft-shytyi-netmod-vysm-02\A0>
> >>Abstract:\A0
> >>
> >>>>>> draft\A0https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt <http://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-01.txt>.

---

From: Dmytro Shytyi <[email-masked]>
Date: Sun, 22 Sep 2019 21:41:55 +0200

Hello Mahesh,

I would like to thank you for your comments.

---- On Fri, 06 Sep 2019 03:43:05 +0200 Mahesh Jethanandani <mailto:[email-masked]> wrote ----

Hi Dmytro,

[Dmytro] Thank you for this suggestion.

See inline with [mj]

On Sep 5, 2019, at 2:03 PM, Dmytro Shytyi <mailto:[email-masked]> wrote:

[Dmytro]

[Dmytro]

[Dmytro] The uCPEs have these items. Therefore the model that was created was created for uCPE management part. I will adjust the draft regarding your comment. 

      +--rw vms* [vm]

                      +--rw vm             string

                      +--rw ports* [port]

                      |  +--rw port    string

                      |  +--rw name?   string

                      +--rw ram?           string

                      +--rw cpu?           string

                      +--rw storages* [id]

                      |  +--rw id          string

                      |  +--rw location?   string

                      +--rw day0-config

                         +--rw location?        string

                         +--rw variable* [name]

                            +--rw name     string

                            +--rw value?   string

 >>>>>       +--rw vm1             string

                       |     +--rw ports* [port]

                       |     |  +--rw port    string

                       |     |  +--rw name?   string

                       |     +--rw ram?           string

                       |     +--rw cpu?           string

                       |     +--rw storages* [id]

                       |     |  +--rw id          string

                       |     +--rw day0-config

                       |     |     +--rw name     string

                       |     |     +--rw value?   string

                       |     +--rw ports* [port]

                       |     |  +--rw port    string

                       |     |  +--rw name?   string

                       |     +--rw ram?           string

                       |     +--rw cpu?           string

                       |     +--rw storages* [id]

                       |     |    +--rw id          string

                       |     +--rw day0-config

                       |     |     +--rw name     string

                       |     |     +--rw value?   string

                        ....

                      |                      

 >>>>>       +--rw vmN             string

                            +--rw ports* [port]

                            |  +--rw port    string

                            |  +--rw name?   string

                            +--rw ram?           string

                            +--rw cpu?           string

                            +--rw storages* [id]

                            |  +--rw id          string

                            |  +--rw location?   string

                            +--rw day0-config

                               +--rw location?        string

                               +--rw variable* [name]

                                  +--rw name     string

                                  +--rw value?   string

[Dmytro] Thank you for suggestion, I will add this to the next version.

The XML example below presents the configuration of the next service in the uCPE, where: vSW(LAN), vSW(WAN), vSW(Service) - virtual switches; l1,l2,l3,l4 - virtual links; VMs represent PNFs (Physical Network Fuctions) that could be bootstrapped with 0day config/license.
  
+--------+      +-------------+      +------------+
|vSW(LAN)|--l2--|VNF-vFirewall|--l3--|            |
+--------+      +-------------+      |            |
+--------+      +-------------+      |vSW(Service)|
|vSW(WAN)|--l1--|   VNF_vCPE  |--l4--|            |
+--------+      +-------------+      +------------+
     
  <ucpe xmlns="urn:ietf:params:xml:ns:yang:ietf-ucpe">
      <name>ucpe1</name>
      <links>
        <link>l1</link>
      </links>
      <links>
        <link>l2</link>
      </links>
      <links>
        <link>l3</link>
      </links>
      <links>
        <link>l4</link>
      </links>
      <switches>
        <switch>lan</switch>
        <ports>
          <port>10</port>
          <name>l2p10</name>
          <link>l2</link>
        </ports>
      </switches>
      <switches>
        <switch>service</switch>
        <ports>
          <port>10</port>
          <name>l3p10</name>
          <link>l3</link>
        </ports>
        <ports>
          <port>11</port>
          <name>l4p10</name>
          <link>l4</link>
        </ports>
      </switches>
      <switches>
        <switch>wan</switch>
        <ports>
          <port>10</port>
          <link>l1</link>
        </ports>
      </switches>
      <vms>
        <vm>VNF-vCPE</vm>
        <ports>
          <port>1</port>
          <name>l1p1</name>
          <link>l1</link>
        </ports>
        <ports>
          <port>2</port>
          <name>l4p2</name>
          <link>l4</link>
        </ports>
        <ram>2048</ram>
        <cpu>2</cpu>
        <storages>
          <id>1</id>
          <location>http://192.168.2.1/vCPE-x86.qcow2</location>
        </storages>
        <day0-config>
          <location>https://192.168.2.1/vCPE-day0.iso</location>
          <day0-var-path>/config.rom</day0-var-path>
          <variable>
            <name>hostname</name>
            <value>IETF-vCPE</value>
          </variable>
          <variable>
            <name>ipaddress</name>
            <value>192.168.1.2 255.255.255.0</value>
          </variable>
        </day0-config>
      </vms>
      <vms>
        <vm>VNF-vFirewall</vm>
        <ports>
          <port>1</port>
          <name>l3p1</name>
          <link>l3</link>
        </ports>
        <ports>
          <port>2</port>
          <name>l2p2</name>
          <link>l2</link>
        </ports>
        <ram>2048</ram>
        <cpu>2</cpu>
        <storages>
          <id>1</id>
          <location>http://192.168.2.1/vFirewall-x86.qcow2</location>
        </storages>
        <day0-config>
          <location>https://192.168.2.1/vFirewall-day0.iso</location>
          <day0-var-path>/config.rom</day0-var-path>
          <variable>
            <name>hostname</name>
            <value>vFirewall</value>
          </variable>
          <variable>
            <name>ipaddress</name>
            <value>192.168.1.3 255.255.255.0</value>
          </variable>
        </day0-config>
      </vms>
    </ucpe>

[Dmytro]

Yes, it is better to set int. Yes Number of CPUs. It will be fixed.

[Dmytro]

storage is a list where items are locations of the iso/qcow2/(for example vdi)". further the mapping logic creates a disk based on the image location.

We could have multiple storages, thus multiple disks. (This one should be modified. Thank you for suggestion. For example we may add type of the disk (for example IDE).

[Dmytro]

We could talk about VNFD, NSD, Forwarding graphs. But uCPE that exists nowadays, all of them are following this way? 

[Dmytro]

[Dmytro]

The question that you may face is how you are going to configure with YANG modle for Openstack the  uCPE when you have Ports and Swithes to configure and variables that you want to pass to the uCPE VNF? 

[Dmytro]

[Dmytro]

Yes it is not defined. I don't think this is a part to define in this draft as this darft is related to the uCPE management.(i.e. creation of the uCPE service) that may be connected for example to the 1/10G Internet link of ISP.

[Dmytro]

[Dmytro]

Yes. It can specify the YANG model. And based on the YANG model there will be logic written. So the YANG model should be chosen wisely by taking into account the work that needs to be done after.

[Dmytro]

There are implementation details for each uCPE. And those are not covered by the document. The YANG model should be chosen such that in the future implementators would have less pain to integrate the YANG model with logic.

[Dmytro]

[Dmytro]

Why flavors are needed if the idea is not appropriate to the uCPE)fixed configuration)?

Links have 2 termination points. They interconnect switches with VMs/Physical Ports.

[Dmytro]
This YANG model allows to pass variables to the workflow. I do not see anything wrong with that if we consider this YANG model as management layer of uCPE.
Thus the generic solution of ETSI leads to more complex implementations of the code that is responsible for mapping between YANG/XML when the solution proposed in the Inernet Draft is tailored to the uCPE use-case and should bring the simplisity when developping the mapping logic and inroduce features that are not presented by ETSI.

[Dmytro]Than you for your comment.

Mahesh Jethanandani

mailto:[email-masked]

>>URL: https://www.ietf.org/internet-drafts/draft-shytyi-netmod-vysm-02.txt/A0

>>Status: https://datatracker.ietf.org/doc/draft-shytyi-netmod-vysm//A0

>>Htmlized: https://tools.ietf.org/html/draft-shytyi-netmod-vysm-02/A0

>>Htmlized: https://datatracker.ietf.org/doc/html/draft-shytyi-netmod-vysm/A0