Subject: [netmod] Comparison of structural-mount and ysdl drafts

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jan 2016 11:51:38 +0000

Hi Lada, Martin,

I've reviewed both draft-bjorklund-netmod-structural-mount-00 and 
draft-lhotka-netmod-ysdl-00.

In comparing these two drafts, the main differences that I perceive are:

1) structural-mount allows the mounted data model to publish its 
supported schema at the mount point, but ysdl requires the mounting 
device to know and publish the schema for all mounted data models.
2) A corollary of (1) is that structural-mount also allows different 
schema data models to be published at the mount point (e.g. under a 
list), but ysdl does not.
3) structural-mount has a mount node embedded directly in the schema, 
where as for ysdl, the equivalent mount points are only specified in the 
ysdl meta-schema.
4) ysdl is extensible to cover other non mount related use-cases (such 
as anydata) where being able to dynamically make available the schema is 
useful.
5) structural-mount also covers RPCs and Notifications, whereas these 
appear to be outside the scope of ysdl.
6) The ysdl meta-data language appears to be more flexible, and hence 
also more complex, than the equivalent "mount-points" schema defined in 
structural-mount.
7) For structural-mount the "mount-points" table is returned as a normal 
oper data YANG module in the mounting device, whereas for ysdl, protocol 
extensions would be required to NETCONF/RESTCONF to access the schema 
meta-data.

Considering these differences:

For points (1) and (2), I can think of scenarios where having a mounted 
device being able to provide its schema via yang-library and for that 
schema to differ for different mounted devices is probably a requirement 
for some plausible mount scenarios.  E.g. one that I can think of is the 
case that you have a YANG controller that is exposing an aggregated YANG 
model for a set of devices, it seems that you would need to be 
accommodate mounted devices that are made by different vendors and 
running different software versions which would imply that their schema 
may also be different.

For point (3), this is a matter of preference, I like that fact that the 
mount point is explicit in the schema in structural-mount.  The ysdl 
meta-schema appears to be more flexible because it can in effect put 
mount points anywhere, but even with structural mount this same 
flexibility could presumably still be achieved by augmenting with a 
mount point.

For point (4), I think that this is useful functionality, and perhaps if 
structural-mount is to be used as the base draft going forward it might 
be worth considering whether the solution could be able to cover, or be 
cleanly extended, to this use case.

For point (5), I definitely think that it is beneficial that 
structural-mount has an intuitive solution for RPCs and Notifications.

For points (6) and (7) my gut instinct is that the structural-mount 
would be easier to standardize and also less work to implement.

Some of my points above may be incorrect, and that might swing the 
balance between the two solutions, so please correct me if I have got 
anything wrong.  Otherwise, just considering the written drafts as they 
stand now, my personal preference is that I would favour using 
structural-mount as a starting point for a solution.

Martin, I also have some comments/questions on the structural-mount 
draft, I'll put these into a separate email.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Jan 2016 13:41:56 +0100

> device to know and publish the schema for all mounted data models.

I am not sure what you mean by "publish" but I think really the only
difference is that structural-mount provides schema information as
regular state data and YSDL as meta-data.

In my view, the definition of a data model schema is really
meta-data. The module "ietf-yang-structural-mount" and its data would
require special treatment anyway - for example, it has to be found in a
well-known location, so it cannot itself be mounted.

> list), but ysdl does not.

True, but it can be easily emulated by using either a choice (or a
"dynamic choice" using "when") and defining different sub-schemas as
different cases. I'd argue this is a more robust approach.

> appear to be outside the scope of ysdl.

This is just an omission on the part of YSDL. The approach proposed for
structural-mount can be used as well.

> extensions would be required to NETCONF/RESTCONF to access the schema 

First, structural-mount uses an extension that has to be considered
mandatory because otherwise no interoperability can take place. So I
don't think that it seamlessly integrates into NETCONF/RESTCONF.

And second, I actually considered to simply extend yang-library with the
YSDL data, but I decided to keep it separate in order to avoid
additional delays for the yang-library spec.

> running different software versions which would imply that their schema 

Right, you would use a (dynamic) choice in this case.

> mount point is explicit in the schema in structural-mount.  The ysdl

But this means using a YANG extension with all the problems regarding
conformance. And this extension is quite far-reaching.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Robert Wilton <[email-masked]>
Date: Fri, 22 Jan 2016 13:28:14 +0000

Hi Lada,

Please see inline ...

> regular state data and YSDL as meta-data.
I was really referring to the inline-yang-library option in structural 
mount that allows the actual YANG schema to be deferred to the mounted 
device implementing yang-library (and which is available at the mount 
point).  This is the option that I would anticipate would be used in the 
LNE model.

> well-known location, so it cannot itself be mounted.
Yes, I can see how it is meta-data, but I'm not sure that it is 
significantly different from the information provided in yang-library 
which is represented a s regular YANG operational module.

For structural-mount: A mounted model should be able to make the 
mount-points structure available at the mount point if required. I.e. 
the solution is able to naturally recurse (as Martin confirmed in reply 
to Robert Varga's email).

> different cases. I'd argue this is a more robust approach.
I don't think that emulating this with a choice is going to be 
particularly clean.  In addition, the device that is doing the mounting 
doesn't necessarily know what models the mounted device actual 
implements.  For ysdl to work for this scenario, the mounting device 
would probably need to query the yang-library (and/or ysdl 
meta-information to allow the solution to recurse) for each mounted 
device to construct the meta-data for it.  At this point I would argue 
that it is easier to just provide direct access to the yang-library for 
the mounted device (as structural-mount solution proposes).

> structural-mount can be used as well.
OK.

> don't think that it seamlessly integrates into NETCONF/RESTCONF.
I think that only clients and devices that need to mount other models 
would need to support it.  Whether this means it becomes mandatory would 
presumable depend on how widely the mount node used in standard YANG models.

> Right, you would use a (dynamic) choice in this case.
As per above, I'm not really convinced that this works as a solution.

> conformance. And this extension is quite far-reaching.
I would think that depends on how many models end up needing to mount 
other models.

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Jan 2016 15:59:52 +0100

> On 22 Jan 2016, at 14:28, Robert Wilton <[email-masked]> wrote:
> 
> Hi Lada,
> 
> Please see inline ...
> 
> I was really referring to the inline-yang-library option in structural mount that allows the actual YANG schema to be deferred to the mounted device implementing yang-library (and which is available at the mount point).  This is the option that I would anticipate would be used in the LNE model.

YSDL doesn't address any kind of remote mounts. It just adds a pull-style method for the schema construction but everything is local to the device. I think that mounting data from other devices is a different matter with specific problems (access) that don't exist in YSDL.

> Yes, I can see how it is meta-data, but I'm not sure that it is significantly different from the information provided in yang-library which is represented a s regular YANG operational module.

It doesn't really matter how the schema info is retrieved, as long as it is state data available at a well-known location. As I wrote, YSDL could be just an augmentation of yang-library.

Lada

> 
> For structural-mount: A mounted model should be able to make the mount-points structure available at the mount point if required. I.e. the solution is able to naturally recurse (as Martin confirmed in reply to Robert Varga's email).
> 
>> 
> I don't think that emulating this with a choice is going to be particularly clean.  In addition, the device that is doing the mounting doesn't necessarily know what models the mounted device actual implements.  For ysdl to work for this scenario, the mounting device would probably need to query the yang-library (and/or ysdl meta-information to allow the solution to recurse) for each mounted device to construct the meta-data for it. At this point I would argue that it is easier to just provide direct access to the yang-library for the mounted device (as structural-mount solution proposes).
> 
>> 
> I think that only clients and devices that need to mount other models would need to support it.  Whether this means it becomes mandatory would presumable depend on how widely the mount node used in standard YANG models.
> 
>> 
> I would think that depends on how many models end up needing to mount other models.
> 
> Thanks,
> Rob
> 
> 
>> 
>> Lada
>>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 25 Jan 2016 22:53:00 +0000

Robert,

Per (1) below, if you are looking to mount yang from one device to another, the drafts to look at are:
   draft-clemm-netmod-mount-03
   draft-voit-netmod-peer-mount-requirements-03

At this point NETMOD as a whole has not attempted to address whether any common syntax or requirements should bind this aggregate set of four drafts.

Eric

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
> Sent: Friday, January 22, 2016 10:00 AM
> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
> Cc: [email-masked]
> Subject: Re: [netmod] Comparison of structural-mount and ysdl drafts
> 
> 
> > I was really referring to the inline-yang-library option in structural mount that
> allows the actual YANG schema to be deferred to the mounted device
> implementing yang-library (and which is available at the mount point).  This is
> the option that I would anticipate would be used in the LNE model.
> 
> YSDL doesn't address any kind of remote mounts. It just adds a pull-style method
> for the schema construction but everything is local to the device. I think that
> mounting data from other devices is a different matter with specific problems
> (access) that don't exist in YSDL.
> 
> >
> >>
> >> require special treatment anyway - for example, it has to be found in
> >> a well-known location, so it cannot itself be mounted.
> > Yes, I can see how it is meta-data, but I'm not sure that it is significantly
> different from the information provided in yang-library which is represented a s
> regular YANG operational module.
> 
> It doesn't really matter how the schema info is retrieved, as long as it is state
> data available at a well-known location. As I wrote, YSDL could be just an
> augmentation of yang-library.
> 
> Lada
> 
> >
> > For structural-mount: A mounted model should be able to make the mount-
> points structure available at the mount point if required. I.e. the solution is able
> to naturally recurse (as Martin confirmed in reply to Robert Varga's email).
> >
> >>
> > I don't think that emulating this with a choice is going to be particularly clean.
> In addition, the device that is doing the mounting doesn't necessarily know what
> models the mounted device actual implements.  For ysdl to work for this
> scenario, the mounting device would probably need to query the yang-library
> (and/or ysdl meta-information to allow the solution to recurse) for each
> mounted device to construct the meta-data for it. At this point I would argue
> that it is easier to just provide direct access to the yang-library for the mounted
> device (as structural-mount solution proposes).
> >
> >>
> >>> 3) structural-mount has a mount node embedded directly in the
> >>> schema, where as for ysdl, the equivalent mount points are only
> >>> specified in the ysdl meta-schema.
> >>> 4) ysdl is extensible to cover other non mount related use-cases
> >>> (such as anydata) where being able to dynamically make available the
> >>> schema is useful.
> >>> 5) structural-mount also covers RPCs and Notifications, whereas
> >>> these appear to be outside the scope of ysdl.
> >> This is just an omission on the part of YSDL. The approach proposed
> >> for structural-mount can be used as well.
> > OK.
> >
> >>
> >>> 6) The ysdl meta-data language appears to be more flexible, and
> >>> hence also more complex, than the equivalent "mount-points" schema
> >>> defined in structural-mount.
> >>> 7) For structural-mount the "mount-points" table is returned as a
> >>> normal oper data YANG module in the mounting device, whereas for
> >>> ysdl, protocol extensions would be required to NETCONF/RESTCONF to
> >>> access the schema meta-data.
> > I think that only clients and devices that need to mount other models would
> need to support it.  Whether this means it becomes mandatory would
> >> And second, I actually considered to simply extend yang-library with
> >> the YSDL data, but I decided to keep it separate in order to avoid
> >>> For points (1) and (2), I can think of scenarios where having a
> >>> mounted device being able to provide its schema via yang-library and
> >>> for that schema to differ for different mounted devices is probably
> >>> a requirement for some plausible mount scenarios.  E.g. one that I
> >>> can think of is the case that you have a YANG controller that is
> >>> exposing an aggregated YANG model for a set of devices, it seems
> >>> that you would need to be accommodate mounted devices that are made
> >>> by different vendors and running different software versions which
> >>> would imply that their schema may also be different.
> >>> For point (3), this is a matter of preference, I like that fact that
> >>> the mount point is explicit in the schema in structural-mount.  The
> >>> ysdl
> >>> For point (4), I think that this is useful functionality, and
> >>> perhaps if structural-mount is to be used as the base draft going
> >>> forward it might be worth considering whether the solution could be
> >>> able to cover, or be cleanly extended, to this use case.
> >>>
> >>> balance between the two solutions, so please correct me if I have
> >>> got anything wrong.  Otherwise, just considering the written drafts
> >>> as they stand now, my personal preference is that I would favour
> >>> using structural-mount as a starting point for a solution.
> >>>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod