We still hope that schema mount can handle cross-referencing across mounted modules. It is also needed when ietf-interfaces model is mounted to logical-network-element and network-instance models.
More comments for this case below in-line. Thanks, - Xufeng > -----Original Message----- > From: Teas [mailto:[email protected]] On Behalf Of Joel M. Halpern > Sent: Friday, April 29, 2016 1:05 PM > To: Tarek Saad (tsaad) <[email protected]>; Martin Bjorklund <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [Teas] [netmod] Use of schema mounts for common model > > With regard to leafrefs trying to point into groupings, would instance-identifiers > work for your use case? > In this case, it would be hard to specify the must conditions for these instance-identifiers to make them always applicable when the groupings are used in various situations. If we are willing to re-structure everything, the method used in draft-halpern-supa-generic-policy-data-model could be an option to explore. > Yours, > Joel > > On 4/29/16 12:17 PM, Tarek Saad (tsaad) wrote: > > Thanks Martin, please see inline.. > > > > > > On 2016-04-29, 6:29 AM, "Martin Bjorklund" <[email protected] > > <mailto:[email protected]>> wrote: > > > > "Tarek Saad (tsaad)" <[email protected] <mailto:[email protected]>> wrote: > > > > Hi authors/WG, > > In draft-ietf-teas-yang-te, we are driving the definition for a > > generic TE YANG model that can/may be used (and extended when > > necessary) for different data plane technologies (e.g. MPLS, > > OTN, WDM, > > etc.). > > Reviewing the schema mount idea presented in > > draft-ietf-netmod-schema-mount, we are thinking this proposal is > > useful and can facilitate the reuse of the our model in multiple > > places in the YANG tree (once per each technology), e.g.: > > ./mpls/mount-points/mount-point/module=ietf-te.yang > > ./otn/mount-points/mount-point/module=ietf-te.yang > > > > > > Schema mount is probably not the right solution to your problem. I > > think a better solution in your case is to define groupings. > > Groupings are designed to be re-used at different places in the > > hierarchy. > > > > > > We thought of this earlier, and found groupings pose their own set of > > challenges too.. Specifically: > > - a groupings with leafrefs could not reference data nodes that reside > > in another grouping > > - a grouping with leafrefs of relative path were challenge when the > > relative path references data nodes outside the grouping > > - the augmentation of the grouping by other modules is not as > > straightforward > > > > That said, the grouping proposal seems to > > > > one could also think that with groupings one could address reuse of > > the a model (e.g. Ietf-interfaces) for logical devices or VM (see > > below). In fact, in your draft (section 2) you explicitly discourage > > this approach as not scalable solution > > > > > > With the "uses" approach, ietf-interfaces would have to define a > > grouping with all its nodes, and the new model for logical devices > > would have to use this grouping. This is a not a scalable solution, > > since every time there is a new model defined, we would have to > > update our model for logical devices to use a grouping from the new > > model. Another problem is that this approach cannot handle vendor- > > > > > > > > We have a comment/concern/suggestion and we value your feedback. > > The generic TE model currently references data nodes in the global > > tree (e.g. from the ietf-interfaces model to define additional TE > > properties associated with a specific device interface). Our > > understanding after reading section 3.1 of your draft is the mounted > > model can *not* reference any data nodes outside the scope of the > > mount-point (e.g. global data nodes in the yang tree). This poses a > > limitation for us, do you have a suggestion for this problem? > > One possible solution we thought of was to replace the leaf-refs > > pointing to the global data nodes (e.g. Ietf-interfaces) with > > context > > names (e.g. the interface name).. This decouples the data-nodes > > defined in the TE generic model from those in the global tree > > (e.g. the actual interface ietf-interfaces model). Any feedback on > > this or better suggestions? > > In this case, there are multiple augmentations to ietf-te.yang, such as ietf-rsvp-te and ietf-sr-te. If ietf-te is a grouping, we cannot do the augmentations before ietf-te is used. Using the grouping would be very awkward when ietf-te is used. We would have to make the same many augmentations at that time. Even worse, there could be future augmentations, we cannot specify these augmentations now because they are not defined yet. > > > > If you use groupings instead, you can still use proper leafrefs. > > > > > > Not in all cases - as described above. > > > > Regards, > > Tarek > > > > > > > > /martin > > > > > > > > Regards, > > Tarek > > Excerpt from draft-ietf-netmod-schema-mount > > 3.1<https://tools.ietf.org/html/draft-ietf-netmod-schema-mount- > 01#section-3.1>. > > Augment and Validation in Mounted Data > > All paths (in leafrefs, instance-identifiers, XPath > > expressions, and > > target nodes of augments) in the data models mounted at a > > mount point > > are interpreted with the mount point as the root node, and the > > mounted data nodes as its children. This means that data > > within a > > mounted subtree can never refer to data outside of this subtree. > > > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > Teas mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/teas _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
