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

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 05 September 2019 18:27 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378E3120119 for <netmod@ietfa.amsl.com>; Thu, 5 Sep 2019 11:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD-76IiuAY_7 for <netmod@ietfa.amsl.com>; Thu, 5 Sep 2019 11:27:13 -0700 (PDT)
Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645C01200F3 for <netmod@ietf.org>; Thu, 5 Sep 2019 11:27:13 -0700 (PDT)
Received: by mail-pg1-x542.google.com with SMTP id n190so1890028pgn.0 for <netmod@ietf.org>; Thu, 05 Sep 2019 11:27:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=UdQoZxROcHZYjfMOlwtFHYft7J7mu9aelPRiMV5fNcw=; b=iky+arYJHXZFckOunGzt7TIpVRbR4yqyXf9XGjvWLR8ddaoqqRKXNeEh1JlpgQslIV Zo8M6iqkicJ2WkAHs5vjb72kYFxKfxdZf2yjosXjGE0KcsVKHwD+53T9YO06X/NwHvph ojfmwlS7bRtc6wKT2HhDfHRRycLz9N0TmznZLYvYzF7wgvymISGbsoqD82L2t4poVCEC q/ETbQ2AzMWwqn3WGHxch+TEw/trZpEMxHFy9bjvL9y99gsw9ueGnfuwn4FH2rx83OSp rn0NAPZTHehPaZvUFyPqeaK7pkuXlIXw9S7XGJt3jhEg4D6uIBII97Z5AswAo5gSJAhv c4PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UdQoZxROcHZYjfMOlwtFHYft7J7mu9aelPRiMV5fNcw=; b=r6GJmYn1WOeaMii+LrC7UM7ke8dxBqTjW6OqtiijnIjA4awZKyeWt7XZFVamfthKBD 4vcg+g/YkXEhfiwzKKw1g5HUUZr0Vm/FsGz2Gsl5VF1zI8tQgTHCe+FcNWKKJXP03Eoe GkWbHkd57ediWFJnFiY1gZE0vymsMfn0mqYf3uVKb+52p+N7SRoLmK3X39obcaBIaLVs G+tgqaxYd8RYbPQz2suWJk8hOs1lFJbUzOtX1+MZc2yPFhP/e7PO3S6H15zV86RixOaf Q5+T24loyPCSMyINV8iLmcdU26IyuCO2lW72hnmz+iSDzE2xzO0lVR4+0xcF93XrXwcR PkTQ==
X-Gm-Message-State: APjAAAVFopj4+FSQz8M4sEjjD4DXnrat1mbZWZE5p6kViiMyvWQDIA9t E0pT8c1Q8u/oDuRhoZcxP0Y=
X-Google-Smtp-Source: APXvYqySUFSd8IpE/Exb+koNw2V2UW9ar4IAWQka8QsAMCNQgGG6Mn7h/h8t5mWsWfGcIYyU/5/WpA==
X-Received: by 2002:a65:640a:: with SMTP id a10mr4374897pgv.338.1567708032645; Thu, 05 Sep 2019 11:27:12 -0700 (PDT)
Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id e129sm2757877pfa.92.2019.09.05.11.27.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Sep 2019 11:27:12 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_309C4C25-54BF-49EB-ABBC-63521627BB2A"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
X-Priority: Medium
In-Reply-To: <16d022a2635.cf0e2e825020.1253681289762507320@shytyi.net>
Date: Thu, 05 Sep 2019 11:27:10 -0700
Cc: Robert Varga <nite@hq.sk>, billwu <bill.wu@huawei.com>, netmod <netmod@ietf.org>, Diego Lopez <diego.r.lopez@telefonica.com>
Message-Id: <DD368137-2977-4039-9C3E-F5127EBB0864@gmail.com>
References: <155377227553.1573.8548464832229347361.idtracker@ietfa.amsl.com> <16caabd07ae.de4789c8151923.6368018099125205208@shytyi.net> <16cba30dec2.b91b31ed256364.8160264793634017255@shytyi.net> <16cd3d19305.11aec1852361697.7576623717058940792@shytyi.net> <5219ac80-b607-b4b4-8c77-72950d4c5137@hq.sk> <16cd8798b80.b402ce899813.5192375594519800096@shytyi.net> <16d022a2635.cf0e2e825020.1253681289762507320@shytyi.net>
To: Dmytro Shytyi <ietf.dmytro@shytyi.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7qiQkL5hSQfJ6rnNl7Z8_UJS1ok>
Subject: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Sep 2019 18:27:17 -0000

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 <ietf.dmytro@shytyi.net> wrote:
> 
> 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 <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: 
> 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:ietf.dmytro@shytyi.net <mailto:ietf.dmytro@shytyi.net>]
> >># # # # : 2019# 8# 28#  21:46
> >># # # : Robert Varga <nite@hq.sk <mailto:nite@hq.sk>>; Qin Wu <bill.wu@huawei.com <mailto:bill.wu@huawei.com>>
> >># # : netmod <netmod@ietf.org <mailto:netmod@ietf.org>>
> >># # : 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 <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
> >netmod@ietf.org <mailto:netmod@ietf.org>
> >https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> ______________
> Dmytro SHYTYI
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com