Re: [netmod] [OPSAWG] draft-shytyi-opsawg-vysm-04

Dmytro Shytyi <ietf.dmytro@shytyi.net> Tue, 22 October 2019 21:42 UTC

Return-Path: <ietf.dmytro@shytyi.net>
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 67DD01200FD; Tue, 22 Oct 2019 14:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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, 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 (1024-bit key) header.d=shytyi.net
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 xcB2eN7Ydy4P; Tue, 22 Oct 2019 14:42:55 -0700 (PDT)
Received: from sender11-of-o52.zoho.eu (sender11-of-o52.zoho.eu [185.20.211.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C4F1200FB; Tue, 22 Oct 2019 14:42:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1571780564; cv=none; d=zohomail.eu; s=zohoarc; b=a6JaiEfemg/3/NGoXkeYVQYy82brBT3p3z6Qr92e2U/er27uhouctxsHHoi1tFe98EO6V2ScEQKRS7mAjeDJMuQ2gRORn+Rwnkx8k49hwpt5i4opkfrUG1Kj+9wlwP3qJ/SX8FPQ03w72hK3wgFhFYeLgixF7SCphlGcYYjwiAA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.eu; s=zohoarc; t=1571780564; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=TyG/7D5qQrFVqbQMa0eaha7R9/P0Zf6TUAr7hQWaNMU=; b=KS7tE2P9DwLAQOhivSyhpBuAZ8ZmXDDWiRoh4YdiklYZKrB+DWCqTL4ykZqLwOCes4e3HFoREhB2i9kT7rDTm6iJlvhsEumvJ3HnPtef0e/A5lxiCoOPMRxQDIqcjdL+rSIvVXh8Hn1HStNelZ1O/h8UecbROVeUKUILLLJBU48=
ARC-Authentication-Results: i=1; mx.zohomail.eu; dkim=pass header.i=shytyi.net; spf=pass smtp.mailfrom=ietf.dmytro@shytyi.net; dmarc=pass header.from=<ietf.dmytro@shytyi.net> header.from=<ietf.dmytro@shytyi.net>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1571780564; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Cc:Message-Id:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=42859; bh=TyG/7D5qQrFVqbQMa0eaha7R9/P0Zf6TUAr7hQWaNMU=; b=HibSrmT/c5GrPWiR9EJYQh6qh71tfOujfHDs7Ej27SQ7WPc9z8p56so+p0s2nKmC GhDQA2zzq3hsn5qj7spPTzmD8rEnROEv3f78R75h9HO7XhCa75ZYhlMFh4tfXz+M+0m uKdwr8yDGLQ6WSM9807Vdy+x3Obxj8SJLajxgnMU=
Received: from mail.zoho.eu by mx.zoho.eu with SMTP id 1571780564112127.56383192439819; Tue, 22 Oct 2019 23:42:44 +0200 (CEST)
Date: Tue, 22 Oct 2019 23:42:44 +0200
From: Dmytro Shytyi <ietf.dmytro@shytyi.net>
To: =?UTF-8?Q?=22Sch=C3=B6nw=C3=A4lder=2C_J=C3=BCrgen=22?= <J.Schoenwaelder@jacobs-university.de>
Cc: "Martin Bjorklund" <mbj@tail-f.com>, "netmod" <netmod@ietf.org>, "opsawg" <opsawg@ietf.org>
Message-Id: <16df56c1488.12bf5b05d97805.101466112881248875@shytyi.net>
In-Reply-To: <20191022204302.5me6qb65f3zkrqad@anna.jacobs.jacobs-university.de>
References: <8736fmtk3d.fsf@nic.cz> <20191021.134014.40553165389352172.mbj@tail-f.com> <039001d588c2$bb3d7e20$4001a8c0@gateway.2wire.net> <20191022.133131.983827662033885262.mbj@tail-f.com> <16df50844b1.bbb67c6096091.5644334168758722892@shytyi.net> <20191022200554.dt6x57eksvqbvngj@anna.jacobs.jacobs-university.de> <16df527b509.f1eff96d96574.7542135600963858099@shytyi.net> <20191022204302.5me6qb65f3zkrqad@anna.jacobs.jacobs-university.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_275998_583245835.1571780564105"
X-Priority: Medium
User-Agent: Zoho Mail
X-Mailer: Zoho Mail
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/O83ltT8DCB063rDFOUu__Re910g>
Subject: Re: [netmod] [OPSAWG] draft-shytyi-opsawg-vysm-04
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: Tue, 22 Oct 2019 21:42:58 -0000

Hello,





>[since you sent the same email to two WGs, I have added both to Cc in 

>this reply. i don't think we should have parallell discussions in 

>different MLs] 



Dmytro Shytyi <mailto:ietf.dmytro@shytyi.net> wrote: 

> Hello Jurgen, 

> 

> 

> 

> Thank you for your comment, 

> 

> 

> 

> Yeap I think it is a great idea to explain why do we need the adjustments  of RFC 8343 in the case of draft-shytyi-opsawg-vysm-04. 

> 

> 

> 

> What do you think about this: 

> 

> 1. uCPE phy interface has "vPorts" to witch "vLinks are 

> assigned". "vLinks "connect" the phy interface with  "vPort" of 

> vswitch. Thus we may add to the derieved from RFC 8343 module the 

> list of "vPorts" for each phy interface. 



>>You should use "augment" if you want to add additional nodes to an 

>>existing module. 



[Dmytro] Yes I agree, it is exatly what we did in the  draft-shytyi-opsawg-vysm-04. We augmented "vPorts" to the interfaces :)

The same "augment i think it could be appropriate to use in the derived module from "ietf-interfaces" (RFC 8343) to agment the yang model "ietf-ucpe"



> example with 1 phy interface: 

> 

> 

> 

>                               +------------------------------------- 

> 

>                               |                  UCPE 

> 

>                   +------------+ 

> 

>                   |                        |------vPort 1---vlink---(vport_sw)vswitch(vport_sw)--vlink---.....----WAN 

> 

> LAN----|   Phy             |------vPort 2 

> 

>                   |   interface     | 

> 

>                   +-------------+ 

> 

>                               | 

> 

>                               +---------------------------------------------- 

> 

> 2. If we include the yang module from the RFC 8343 to the set of yang models by default it goes in the root of config mode. i.e: 

> 

> EXAMPLE: 

> 

> config t 

> 

>       interfaces interface.... 

> 

> 

> 

> When we have a parent module we need to place the RFC 8343 module to under the parent module (like in the draft draft-shytyi-opsawg-vysm-04).  





>Have you looked at the models in RFC 8529 and RFC 8530? Perhaps you 

>can use them, rather than creating another special module for this 

>particular use case? 



[Dmytro] Thank you for this suggestion, @Martin.



I can imagine that we could  assing "ietf-interfaces" to VSI as described in the RFC 8529. @Martin, looging the schema of yang models for rfc 8529(below) can we assign more than one (>1) LNE to the interface (both for rfc 8529 and 8530)?

In the uCPE usecase you may have multiple swithes assigned to the same port.



+--rw network-instances
        +--rw network-instance* [name]
           +--rw name           string
           +--rw enabled?       boolean
           +--rw description?   string
           +--rw (ni-type)?
           +--rw (root-type)
              +--:(vrf-root)
              |  +--mp vrf-root
              +--:(vsi-root)
              |  +--mp vsi-root
              +--:(vv-root)
                 +--mp vv-root



   module: ietf-interfaces
      +--rw interfaces
      |  +--rw interface* [name]
      |     +--rw name                        string
      |     +--rw ip:ipv4!
      |     |  +--rw ip:enabled?                      boolean
      |     |  +--rw ip:forwarding?                   boolean
      |     |  +--rw ip:mtu?                          uint16
      |     |  +--rw ip:address* [ip]
      |     |  |  +--rw ip:ip               inet:ipv4-address-no-zone
      |     |  |  +--rw (ip:subnet)
      |     |  |     +--:(ip:prefix-length)
      |     |  |     |  +--rw ip:prefix-length?   uint8
      |     |  |     +--:(ip:netmask)
      |     |  |        +--rw ip:netmask?         yang:dotted-quad
      |     |  +--rw ip:neighbor* [ip]
      |     |  |  +--rw ip:ip                  inet:ipv4-address-no-zone
      |     |  |  +--rw ip:link-layer-address yang:phys-address
      |     |  +--rw ni:bind-network-instance-name?   string
      |     +--rw ni:bind-network-instance-name?   string




/martin 










On Tue, Oct 22, 2019 at 10:28:03PM +0200, Dmytro Shytyi wrote: 
> 
> Cut and paste to change the 'nesting' is _not_ proper usage of 
> YANG. The value of YANG is that objects with the same semantics are 
> predictable, this gives you interoperability. By copying modules to 
> other places (and tweaking semantics), you break the interoperability 
> promise. 
> 
> /js 
> 
> 
> [Dmytro]. 
> 
> I find the task much easier if we could just augment the interfaces module without changing it. I see it the next way . The "ietf-interfaces" yang module initially was created  for the config, when you have: 
> 
> config t  
> 
>       interfaces interface ... 
> 
> Here we have different condition of "nesting"... when module "ucpe-ietf-interfaces" (not "ietf-interfaces") shout augment another module ("ietf-ucpe") 
> 
> 
> 
> We augment vPorts to phy interfaces. 
 
>I do not understand your explanation. The ietf-interfaces hierarchy can 
>be found on page 5 of RFC 8343. You can augment additional nodes into 
>it.


[Dmytro] Yes  we can augment additional nodes into "ietf-interfaces" it is what we do in the draft-shytyi-opsawg-vysm-04 :


augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" {
       list ports {
         key "port";
         leaf port {
           type string;
           description
             "Name of the connector";
         }



We wold like to have this:

module: ietf-ucpe
+--rw ietf-ucpe:ucpe* [name]
   +--rw ietf-ucpe:Name              string
   |
   +--rw ucpe-if:interfaces

            ....





> >Cut and paste to change the 'nesting' is _not_ proper usage of 
> 
> YANG. 
> 
> [Dmytro] 
> 
> If I understood correctly I can't just derive the parts from the exisiting module  (by referencing them) to the new module. 
> 
 
I have no idea what you mean with "(by referencing them) to the new 
module". You can of course refer to definitions in ietf-interfaces. 
 
> So I have two questions: 
> 
> If i cant derive the parts from existing module while creating a new, how to address this issue(when we want "ucpe-ietf-interfaces" to augment "ietf-ucpe"). Could you suggest something? 
>I likely do not understand but you can of course augment 
>ietf-interfaces with additional nodes that refer to ietf-ucpe 
>definitions if that is what you are looking for.


[Dmytro] Yes we can augment the "ietf-interfaces" with new modules. Hovewer in the draft-shytyi-opsawg-vysm-04 we are looking to augment module "ietf-ucpe" with modified "ietf-interfaces".  Example

SCHEME #1

module: ietf-ucpe
+--rw ietf-ucpe:ucpe* [name]
   +--rw ietf-ucpe:Name              string
   |
   +--rw ucpe-if:interfaces

            ....



To have a result similar to the scheme#1 (above) we derived the "ietf-interfaces" to "ietf-ucpe-interfaces". And "ietf-ucpe-interfaces" was modified (ex. with augment statement,etc..):

module ietf-ucpe-interfaces {
         import ietf-ucpe { prefix ietf-vysm; }
         ...
         augment "/ietf-vysm:ucpe"{
               container interfaces {
                     description "Interface parameters.";
                     list interface {
                     ...
                     }
         }
   }



If i cant derive the parts from existing module (ietf-interfaces) while creating a new("ietf-ucpe-interfaces) how we can get the result similar to scheme#1?

Could you suggest something? 
 
> So the  here I have a question: How we will resolve the leafref in the draft-shytyi-opsawg-vysm-04. if we will not do the augmentation of "ietf-ucpe" in the ""ucpe-ietf-interfaces? 
> 
> augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" { 
>        list ports { 
>          key "port"; 
>          leaf port { 
>            type string; 
>            description 
>              "Name of the connector"; 
>          } 
>          leaf link { 
>            type leafref { 
>              path "../../../../ietf-nfv:links/ietf-nfv:link"; 
>            } 
>            description 
>              "Link that is connected to the port 
>               via connector"; 
>          } 
>          description 
>            "Set of the connectors the physical 
>             interface has"; 
>        } 
>        description 
>          "ucpe ports of the interface"; 
>      } 
>    } 
 
>I think it is possible to have a path contraint on a leafref that 
>refers to definitions in other modules (see the ABNF definition 
>path-arg which resolves to absolute-path and relative-path and 
>descendant-path and in there you find node-identifier which can carry 
>an optional prefix that allows to refer to definitions in other 
>namespaces). 




/js 
 
-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH 
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany 
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>