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

Dmytro Shytyi <> Wed, 28 August 2019 13:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73BA6120041 for <>; Wed, 28 Aug 2019 06:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P76uD9_Of1_n for <>; Wed, 28 Aug 2019 06:46:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 980A6120059 for <>; Wed, 28 Aug 2019 06:46:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1566999941; cv=none;; s=zohoarc; b=dgbsPA8wP/odp426PxwBidyJkMJ+QyheabzIT3khEyB82JtfqGIYLqfm8TJEOBtkos4qjF1Pu68E6w8c3C48yl9iTaKpLsPmxC9iTJ4P5LSpt7aer8YLvPmz+JoC0FYZv60WqJGPXVwpHkX4Zvy2TcFlP3Ydu/9n5xnUh+2m/co=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=zohoarc; t=1566999941; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=55Pojq/tarHWkh5IldVjCbYcnuzpYh4kE+VPP8dEzA8=; b=cuQK7PLuPaOXuos4/0gWQZz5BCgMgbkmY/cKBqN0Id/xe8pg+vyMeD1sf251I+JqLaKM84Ho9gf6THr7BZDGW+ERbno/xHpSxz9NhIJ12ShLtqe9JKhlSKOR2XE0jF+ffA62QZLzUOa9+fzANpAnUfqDLmLoC71nwGjoN2d3yHE=
ARC-Authentication-Results: i=1;; dkim=pass; spf=pass; dmarc=pass header.from=<> header.from=<>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1566999941; s=hs;;; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=13140; bh=55Pojq/tarHWkh5IldVjCbYcnuzpYh4kE+VPP8dEzA8=; b=T6M4PLvrxVpJ42aGqtw7iwjT3Cr6HSV+j9SrD014ihsw9Vm+x51iEWw1SC6gXf6P RsIClnqM3jU80cuina7maS7kGWGMNAWPsJtxU59wmQONA90R5tafJ5P27cCHtE8FLbD gW68XDvx8dS4x823EI8n6+0FK+/3QsaA0X5NGPp4=
Received: from ( []) by with SMTPS id 1566999940046215.864047056338; Wed, 28 Aug 2019 15:45:40 +0200 (CEST)
Received: from by with SMTP id 156699993997155.762287354506384; Wed, 28 Aug 2019 15:45:39 +0200 (CEST)
Date: Wed, 28 Aug 2019 15:45:39 +0200
From: Dmytro Shytyi <>
To: Robert Varga <>, billwu <>
Cc: netmod <>
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_29082_1382235135.1566999939968"
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
X-ZohoMailClient: External
Archived-At: <>
Subject: Re: [netmod] New Version draft-shytyi-netmod-vysm-02.txt as Working Group document.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Aug 2019 13:46:03 -0000


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

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

>virtualization -> networks/network


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

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


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)


>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


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.



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


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.


Best regards,