Subject: [netmod] Interplay between YANG network instances and schema mount

From: Robert Wilton <[email-masked]>
Date: Thu, 10 Nov 2016 14:52:53 +0000

Hi,

The network-instances draft (draft-ietf-rtgwg-ni-model) uses YANG mount 
to allow relevant parts of the YANG schema to be made available under a 
particular network instance (e.g. as per the diagram on section 3.2), 
reproduced inline here:

       +--rw yanglib:modules-state           [RFC7895]
       +--rw if:interfaces                   [RFC7223]
       |  +--rw bind-network-instance-name="green" string
       +--rw network-instances
          +--rw network-instance* [name]
             +--rw name="green"    string
             +--rw type?                           identityref
             +--rw enabled=true                    boolean
             +--rw description="The Green VRF"     string
             +--rw network-instance-policy
             |  ... (RT=1000:1, RD=1.2.3.4)
             +--rw root?                           yang-schema-mount
                +--rw yanglib:modules-state  [RFC7895]
                +--rw if:intefaces           [RFC7223]
                +--rw mm:network-services
                +--rw nn:oam-protocols
                +--rw oo:routing
                +--rw pp:mpls

My assumption is that the mounted YANG modules are just providing 
alternative paths in the schema for the same underlying data nodes that 
are also available without going via the schema-mount path. I further 
presume that datanodes could be read/written in both places (of course 
subject to NACM), and that any changes to data nodes made in one place 
must be immediately reflected in both places.

To give a concrete example, assuming that "eth0" was bound to 
network-instance "foo" then:
  network-instances/network-instance[name="foo"]/root/interfaces/interface[name="eth0"] would be pointing to the same actual data node as /interfaces/interface[name="eth0"].

Is my interpretation of how schema mount is anticipated to work in this 
scenario correct?

If my understanding is correct then this would seem to imply:
  - semantic validation of the the datatree can be performed by ignoring 
schema mounted nodes altogether.
  - leafrefs logically exist independently of the schema mounted nodes.
  - leafrefs viewed under a schema mount can, in some cases, be 
simplified to look like the reference is local within the mounted schema 
tree, but in the case that I'm considering here, it isn't obvious to me 
that all such leafrefs must necessarily never reference nodes outside of 
this subtree.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Nov 2016 16:30:30 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> Hi,
> 
> The network-instances draft (draft-ietf-rtgwg-ni-model) uses YANG
> mount to allow relevant parts of the YANG schema to be made
> available under a particular network instance (e.g. as per the
> diagram on section 3.2), reproduced inline here:
> 
> alternative paths in the schema for the same underlying data nodes
> that are also available without going via the schema-mount path.

Schema mount in itself does not specify (by design) anything about the
underlying instrumentation of mounted data models.

In the case of a network orchestrator that uses schema mount for
network devices, the mounted paths are obviously not providing
alternative paths.

But I think it is fine if some usage of schema mount wants this
semantics.  It needs to be defined in the module that uses schema
mount.

> I
> further presume that datanodes could be read/written in both places
> (of course subject to NACM), and that any changes to data nodes made
> in one place must be immediately reflected in both places.

>  network-instances/network-instance[name="foo"]/root/interfaces/interface[name="eth0"]
>  would be pointing to the same actual data node as
>  /interfaces/interface[name="eth0"].
> 
> Is my interpretation of how schema mount is anticipated to work in
> this scenario correct?
> 
>  - semantic validation of the the datatree can be performed by
>    ignoring schema mounted nodes altogether. 
>    simplified to look like the reference is local within the mounted
>    schema tree, but in the case that I'm considering here, it isn't
>    obvious to me that all such leafrefs must necessarily never
>    reference nodes outside of this subtree.

The last bullet might be a problem...

/martin

---

From: Robert Wilton <[email-masked]>
Date: Thu, 10 Nov 2016 16:24:10 +0000

Hi Martin,

Thanks for the comments, please see inline ...

> underlying instrumentation of mounted data models.
OK, I think that was sort of the answer that I was expecting.

But perhaps the text in the schema-mount draft could be clearer on this 
point.  To me, instrumentation seems like it is referring to 
implementation, where as my question is not about implementation at all, 
but about the logical relationship between the data nodes in the tree.

> network devices, the mounted paths are obviously not providing
I agree.  There is something quite different between mounting a single 
copy of remote data, vs mounting a second "view" of some locally 
available data that is already available on a different path.

It also feels like the use of mount in the LNE case is somewhat 
different from the use of mount in the NI draft.

> semantics.  It needs to be defined in the module that uses schema
I actually think that we probably need some schema mount extensions to 
further refine how it can be used and the semantic meaning of the 
mounted data.  In particular, this makes it easier for tooling to use 
modules that contain mounted data without requiring hard-coded logic.  
Such extensions could include:

1) Indicating that is it an entire "device" data model that is being 
mounted, and hence no leafrefs outside of the mount root are allowed. 
(LNE mount case)

2) Indicating that the mount point only represents an alternative "view" 
on to data that is available in the schema via other paths (NI mount 
case?).   I think that this could potentially also allow sub-trees to be 
mounted, and also leafrefs to reference nodes outside the mounted tree.

3) A way of indicating that a mount point is remote, and details about 
which system the data is being mounted from (probably via extensions to 
the ietf-yang-schema-mount YANG module).

4) Statically specifying a set of modules that will always be available 
at the mount point (but allowing later revisions, augmentations, and 
addition modules to also be mounted at the same place).

> The last bullet might be a problem...
Is it a problem is all use cases of schema-mount, or just some of them?  
If we were to standardize some extensions at the same time, then could 
this restriction move into one/some of those extensions?

Thanks,
Rob

> .