Subject: Re: [mpls] [netmod] Use of schema mounts for common model

From: Robert Wilton <[email-masked]>
Date: Tue, 3 May 2016 15:34:44 +0100

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-masked] 
> <mailto:[email-masked]>> wrote:
>
>     "Tarek Saad (tsaad)" <[email-masked] <mailto:[email-masked]>> 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-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 5 May 2016 16:28:20 +0200

Hello,

As I see it the problem is that as we don't know the mount
relationships early. All you can say in the constraint is "point
at some interface". So having a specific path statement is not
feasible.

Using instance-identifiers may help. While it is hard it is not
impossible to constrain instance-identifiers. You can put a
regular expression on their "string" representation, e.g.
rematch(.,'/.*/interface[name=.*]')

This would alow you to point at an interface anywhere (as long as
the list is named interface with a key called name :-( ). Note the
regexp is not 100% OK.

regards Balazs

On 2016-04-29 22:55, Xufeng Liu wrote:

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-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, April 29, 2016 1:05 PM
To: Tarek Saad (tsaad) <[email-masked]>; Martin Bjorklund

<[email-masked]>

Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
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:

"Tarek Saad (tsaad)" <[email-masked] <mailto:[email-masked]>>

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

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

mounted

model can *not* reference any data nodes outside the scope of

the

poses a

(e.g. the actual interface ietf-interfaces model). Any feedback

on

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.

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

subtree.

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Mon, 9 May 2016 15:44:22 +0000

Hi Robert,

Thanks. Please see inline…

From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 3, 2016 at 10:34 AM
To: Tarek Saad <[email-masked]<mailto:[email-masked]>>
Cc: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Use of schema mounts for common model

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.

[TS]: Currently the TE tunnel model has a global list of interfaces. The team has discussed the idea of continuing to have a single global list and then assigning the tunnel technology type on per tunnel. This implicates the following:

  1.  There will be 1 full list of TE tunnels for all technology types. The list will be keyed by {(tunnel name)+(tunnel-technology-type)}. On nodes that may support multiple technology types (e.g. Packet and optical), the tunnels/LSPs for multiple technologies will be intermixed in the same list.
  2.  The same goes for the list of LSPs (instantiations of tunnels on ingress/transit/egress nodes.. In this case, such LSPs of different technology parts will be intermixed too.

This is possible, but may not be most elegant way of presenting this.. We were hoping it will be possible to have the segregation on per technology by mounting the tunnel list under the respective technology (packet, otn, etc.)..
Lastly, playing devil’s advocate :), one could argue it’s also possible to have one global list of interfaces in the interfaces model and make the device/VM an attribute (and part of the key) of the interface list.. That is an interface name foo can appear multiple times in the interface list (once per VM or physical).. Of course, IMO the mounting proposal is more elegant in this case..

Regards,
Tarek

Thanks,
Rob

On 2016-04-29, 6:29 AM, "Martin Bjorklund" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

"Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi authors/WG,
necessary) for different data plane technologies (e.g. MPLS, OTN, WDM,

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

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

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?

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-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/netmod