Hi Tarek,
I'm also wondering whether using schema mount in this way might be a bit
like using a sledgehammer to crack a nut.
With interfaces, there is a per device global list of interfaces where
each list entry can have a different type and different properties.
Currently these are using the iana:iftype to differentiate their
different schema modes, but there is an idea to use more abstract
identities.
I'm not really familiar with the tunnel YANG models, but I was wondering
whether the same approach has been considered for the TE tunnel YANG
models at all?
I.e. rather than having a separate protocol instantiation for each
different data plane technology, instead have a per device global list
of tunnels that hold the configuration and operational state, making use
of when statements and identities (if required) to manage dataplane
specific leaves. Each protocol specific data plane module could also
maintain a protocol specific list containing leaf-refs back to the
appropriate tunnels in the master list.
Thanks,
Rob
On 29/04/2016 17:17, 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?
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
