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

[Robert Wilton <[e-mail]>]

Hi Martin,

Thanks for the comments, please see inline ...

On 10/11/2016 15:30, Martin Bjorklund wrote:
> Robert Wilton <[e-mail]> 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:
>>
>>        +--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.
> Schema mount in itself does not specify (by design) anything about the
> 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.

>
> In the case of a network orchestrator that uses schema mount for
> network devices, the mounted paths are obviously not providing
> alternative paths.
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.

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



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


>
>
> /martin
> .
>