On 8/28/2017 7:35 AM, Martin Bjorklund wrote: > Lou Berger <[email protected]> wrote: >> Martin, >> See below. >> >> On 08/28/2017 06:28 AM, Martin Bjorklund wrote: >>> Lou Berger <[email protected]> wrote: >>>> Martin, >>>> See below >>>> >>>> >>>> On August 23, 2017 2:28:37 AM Martin Bjorklund <[email protected]> wrote: >>>> >>>>> Lou Berger <[email protected]> wrote: >>>>>> Hi Martin, >>>>>> >>>>>> See below. >>>>>> >>>>>> >>>>>> On 8/22/2017 6:20 AM, Martin Bjorklund wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Lada presented an open issue in schema mount in Prague. (See slide 6 >>>>>>> in >>>>>>> >>>>>> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount) >>>>>>> The original problem comes from the NI use case >>>>>>> (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model). In this >>>>>>> use case, interfaces are assigned to NIs by: >>>>>>> >>>>>>> augment /if:interfaces/if:interface: >>>>>>> +--rw bind-ni-name? -> /network-instances/network-instance/name >>>>>>> >>>>>>> Modules that are mounted within the NI might have references to >>>>>>> interfaces. The idea is that a specific NI can only reference the >>>>>>> interfaces that has been assigned to it. >>>>>>> >>>>>>> In schema mount, we have the "parent-reference" XPath expression that >>>>>>> in this case will be "/if:interfaces/if:interface". The problem is >>>>>>> that this XPath expression will evaluate to a node set that contains >>>>>>> *all* interfaces in the system. We would like this to contain just >>>>>>> the interfaces assigned to the NI. >>>>>>> >>>>>>> It turns out that this can be done with a simple change to the >>>>>>> "parent-reference" node. If we state that this XPath expression is >>>>>>> evaluated in an XPath context where the context node is the node in >>>>>>> the data tree where the mount point is defined (instead of "/"), we >>>>>>> can use as parent-reference: >>>>>>> >>>>>>> /if:interfaces/if:interface[ni:bind-network-instance-name = >>>>>>> ../ni:name] >>>>>>> >>>>>>> Putting this together we'd have: >>>>>>> >>>>>>> augment "/if:interfaces/if:interface" { >>>>>>> leaf bind-ni-name { >>>>>>> type leafref { >>>>>>> path "/network-instances/network-instance/name"; >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> container network-instances { >>>>>>> list network-instance { >>>>>>> key name; >>>>>>> leaf name { ... } >>>>>>> ... >>>>>>> container root { >>>>>>> // this would be the XPath context root for parent-reference >>>>>>> yangmnt:mount-point ni-root; >>>>>>> } >>>>>>> } >>>>>>> } >>>>>> note that the current NI definition is: >>>>> Yes I saw that. >>>>> >>>>>> module: ietf-network-instance >>>>>> +--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? >>>>> Note that the extension yangmnt:mount-point can only be present in a >>>>> container or list, not in a choice/case. >>>> Okay, I missed that restriction in your draft. What's the reason for >>>> not allowing mounts under choices/cases? Isn't the resulting path to >>>> data nodes indistinguishable when the parent is a list or container? >>> Suppose a server lists a couple of modules for "vrf-root" and some >>> other for "vsi-root" in the /schema-mounts/mount-point list. How can >>> a client tell if a certain NI instance is has the "vrf" modules or >>> "vsi" modules? >> umm, my understanding is that only one of the cases under a choice can >> be present in the data (tree) at a time so the client *can* only see one >> mount point {vrf-root, vsi-root or vv-root} node and all the mounted >> schemas will be under that '-root' node. What have I missed? > The mount point itself is not a node. okay, I think we're getting to the crux of this issue! I certainly didn't see this (that a schema-mount root node is *not* represented in the data, but only in the schema) stated in draft-ietf-netmod-schema-mount. In fact, I read the text as saying just the opposite:
The basic idea of schema mount is to label a data node in the parent schema as the mount point, and then define a complete data model to be attached to the mount point so that the labeled data node effectively becomes the root node of the mounted data model. Why don't you think an MP should be represented in the data (tree)? In our example usage (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B) we include the mount point as a node in the data. You're saying that this doesn't line up with your expectation, right? Can you please take a look at it and see if we have any other disconnects? > So the client will just see > some mounted top-level nodes. If you require that all mount points > have disjoint sets of modules, then this could work. But I assume > that this is not the case. <rest trimmed> Lou _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
