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

[Dmytro Shytyi <[e-mail]>]

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:[e-mail]> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany 
Fax:   [phone]         <https://www.jacobs-university.de/>