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

From: Dmytro Shytyi <[email-masked]>
Date: Tue, 22 Oct 2019 23:42:44 +0200

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:[email-masked]> 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/>

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 22 Oct 2019 23:04:48 +0000

> augment "/ietf-nfv:ucpe/ietf-if:interfaces/ietf-if:interface" {

This is _not_ augmenting into ietf-interfaces.

>    +--rw ietf-ucpe:Name              string
 
If 'ucpe-if:interfaces' is supposed to be RFC 8343 interfaces, then
(1) you can't do this and (2) you do not want to do this.

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

You are not composing and reusing models, you cut and paste models,
creating modified copies that do not interoperate. This is not what
the IETF tries to do.

The standard interfaces model is in /if:interfaces. There is likely no
point of replicating it elsewhere.

> Could you suggest something? 

I have not seen a reason why scheme#1 is a good idea, I have given
reasons why copying is a bad idea. It appears to me like you are
trying to invent a different tree structure for a specific kind of
devices but having per device class different trees is not what we aim
for in the IETF. We aim for reuse of models across a wide range of
different devices.

/js