Subject: [netmod] Differentiating the types of Mount

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 16 Mar 2016 03:59:50 +0000

To help differentiate between concepts and drafts, below are strawman definitions for the various types of Mount which we have been discussing over the last year in Netmod.   Thoughts/suggestions?

YANG Mount
----------------  
Definition: An abstracted term for a mechanism that a parent YANG model can use to link in YANG information defined or located elsewhere.  
Purpose: Provides model flexibility by enabling the growth of YANG trees via an explicit reference to other YANG information and structures. 

Schema Mount
-------------------
Definition: A type of YANG Mount where a new YANG Schema is constructed by inserting any existing YANG schema under a parent model within a local datastore.   Objects populated into the mounted schema are only instantiated as part of the parent's hierarchy.  
Purpose: This allows reuse of existing model definitions to facilitate implementation of alternative model structures in multiple contexts.  In effect, it allows to define models which reuse other model definitions as if they had been defined as a special kind of grouping.  

Alias Mount
---------------
Definition: A type of YANG Mount which allows to provide an alternative path to local objects of YANG data.  
Purpose: Enables multiple concurrent context specific object models without replicating instance data.  This allows programmers access common objects via the hierarchies that best make sense to them. (E.g. Symbolic link in a file system.)

Peer Mount
--------------
Definition: A type of YANG Mount which enables access to remote objects as if they were contained within a local datastore dynamically.
Purpose: Provides an on-demand virtual federated datastore that provides visibility and location transparency of YANG-data across device boundaries.  Retains clear authoritative ownership.  Eliminates many tasks otherwise needed to synchronize, reconcile aggregate, validate information replicated across these devices. (E.g. File share to remote host in a file system.)

Thanks, 
Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Mar 2016 12:23:29 +0100

> To help differentiate between concepts and drafts, below are strawman definitions for the various types of Mount which we have been discussing over the last year in Netmod.   Thoughts/suggestions?

Trying to rewrite the definition to be more consistent with existing
terminology:

  The abstract concept of incorporating a YANG-defined data tree (the
  mounted data tree) into a existing YANG-defined data tree (the
  parent data tree).

Well, this is not really correct, perhaps we have to just say 'tree'
instead of 'data tree' since a schema mount (as I understand it) seems
to incorporate a schema tree into another schema tree while the other
two mounts incorporate a data tree into a data tree. So perhaps the
general definition is something like this:

  The abstract concept of incorporating a YANG-defined data tree or
  schema tree (the mounted data or schema tree) into a existing
  YANG-defined data tree or schema tree (the parent data tree).

The schema mount then essentially removes data tree and the other two
mounts remove the schema tree from this definition.

Is your alias mount simply a special case of a peer mount where the
peer is local? Or is there more to it? In other words, would it be
reasonable to think of the terms in this way:

         +-> schema (tree) mount
	 |
mount -> |                        +-> local data tree (alias) mount
         +-> data (tree) mount -> |
                                  +-> remote data tree (peer) mount

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 16 Mar 2016 15:12:07 +0000

> From: Juergen Schoenwaelder , March 16, 2016 7:23 AM
> 
> > To help differentiate between concepts and drafts, below are strawman
> definitions for the various types of Mount which we have been discussing over
> the last year in Netmod.   Thoughts/suggestions?
> >
> > YANG Mount
> > ----------------
> > Definition: An abstracted term for a mechanism that a parent YANG model can
> use to link in YANG information defined or located elsewhere.
> > Purpose: Provides model flexibility by enabling the growth of YANG trees via
> an explicit reference to other YANG information and structures.
> 
> instead of 'data tree' since a schema mount (as I understand it) seems to
> incorporate a schema tree into another schema tree while the other two
> mounts incorporate a data tree into a data tree. So perhaps the general
> definition is something like this:
> 

This works for me.

> Is your alias mount simply a special case of a peer mount where the peer is
> local? Or is there more to it? 

>From a syntax standpoint, peer mount is more general.  But underneath, things get more complicated.

For example, many of the initial concerns about peer mount were on the implications of synchronizing objects across distributed systems.  (I.e., Eventual consistency is not appropriate when attempting to manage some type of objects.)  Alias mount shouldn't have this issue.

Eric

> In other words, would it be reasonable to think of the terms in this way:
>          +-> schema (tree) mount
> 	 |

The formatting came through mixed up, and I didn't want to make any assumptions by doing my own reformatting.  If the answer above doesn't suffice, resend the example.

Eric

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 16 Mar 2016 15:33:11 +0000

Hi,

I have one addition on top of Eric's response

--- Alex

> peer is local? Or is there more to it?

<ALEX> So, yes, alias mount is a special and simple case.  Perhaps the most relevant aspect to characterize this is that the authoritative owner in alias mount is the same Netconf server, whereas in peer mount authoritative owners will be different.  For this reason, peer mount will be better suited for read-only views.  </ALEX>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 16 Mar 2016 15:35:24 +0000

Thank you Eric and Juergen, this is really helpful, especially the diagram.

Is there an implementation distinction between alias-mount and peer-mount?  I’m hoping that there is one solution for both.  Is there a difference with edits?  E.g., a remote data mount is read-only, whereas a local data mount is read-write?

Kent

On 3/16/16, 11:12 AM, "netmod on behalf of Eric Voit (evoit)" <[email-masked] on behalf of [email-masked]> wrote:

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

---

From: STUART VENTERS <[email-masked]>
Date: Wed, 16 Mar 2016 16:58:11 +0000

Defining a schema-tree seems Yang's strong suite.
I'm not sure if the suite extends to defining what goes into a data-tree governed by the schema-tree.

Perhaps:

YANG Mount
 ----------------
 Definition: An abstracted term for a YANG mechanism that grafts a sibling schema-tree as a subtree of a parent schema-tree.
 Purpose: Provides flexibility by enabling the growth of YANG models via an explicit reference to other YANG models defined elsewhere.

Given the ability to specify a combined schema-tree, maybe something at the protocol level could specify what data to use to populate the grafted tree.
This could provide a place to specify details like who has ownership of the data, if it is RW, etc.

NETCONF Mount
------------------
Definition: An abstracted term for a NETCONF mechanism to construct a combined data-tree according to a schema defined with YANG mount.
Purpose: ...

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, March 16, 2016 6:23 AM
To: Eric Voit (evoit)
Cc: [email-masked]; Martin Bjorklund (mbjorklu)
Subject: Re: [netmod] Differentiating the types of Mount

Well, this is not really correct, perhaps we have to just say 'tree'
instead of 'data tree' since a schema mount (as I understand it) seems to incorporate a schema tree into another schema tree while the other two mounts incorporate a data tree into a data tree. So perhaps the general definition is something like this:

The schema mount then essentially removes data tree and the other two mounts remove the schema tree from this definition.

Is your alias mount simply a special case of a peer mount where the peer is local? Or is there more to it? In other words, would it be reasonable to think of the terms in this way:

         +-> schema (tree) mount
	 |

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 16 Mar 2016 17:19:37 +0000

> From: STUART VENTERS, March 16, 2016 12:58 PM
> 

Hi Stuart,

Open Daylight has found Mounting YANG data from one device to another has proven central to their effort.  Doing a quick Google search for "mount site:opendaylight.org" gives 800+ results.

Based on that, I was hoping that being defining the variants of Mount across different constituencies would help us not collide as the technologies evolve.  This includes a shared definition of "YANG Mount" which shows what is common across all efforts.

Thanks,
Eric
 
> Perhaps:
> 
> YANG Mount
>  ----------------
>  Definition: An abstracted term for a YANG mechanism that grafts a sibling
> schema-tree as a subtree of a parent schema-tree.
>  Purpose: Provides flexibility by enabling the growth of YANG models via an
> explicit reference to other YANG models defined elsewhere.
> 
> Given the ability to specify a combined schema-tree, maybe something at the
> protocol level could specify what data to use to populate the grafted tree.
> Definition: An abstracted term for a NETCONF mechanism to construct a
> combined data-tree according to a schema defined with YANG mount.
> Purpose: ...
> 
> 
> 
> local? Or is there more to it? In other words, would it be reasonable to think of
> the terms in this way:
> 
>          +-> schema (tree) mount
> 	 |

---

From: STUART VENTERS <[email-masked]>
Date: Wed, 16 Mar 2016 19:48:50 +0000

Eric,

I did the suggested OpenDaylight  (ODL)search, and yes there is a lot of activity there.  There are a lot of trees in that forest.

The best overview I found seems to be here.
https://wiki.opendaylight.org/view/OpenDaylight_Controller:_SAL_Architecture_Overview#Nested_Subsystems

Mapping my words to ODL,
My Sibling is the ODL Nested system.
My Parent might be ODL Top-level Subsystem?

Having had lunch to think about it, I don't think I should have picked NetConf as a place to choose what data to mount.
I suspect it should be somewhere in the application, separate for both Yang and Netconf.
ODL appears to use the Northbound Restconf interface to do this function
<module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config">

Stepping back, for this mounting stuff, there are at least 3 issues:
1) Specifying a where in the Parent schema to put the sibling schema.
2) Specifying the type of the sibling.
3) Specifying what sibling data instance to put at a specific parent node data instance.

I think Yang would be a great place to do 1 and 2, but  I think the application should handle 3.
ODL appears to put 1) in Yang,  I'm not sure about 2), and 3) in the application.
Your proposed definition's mention of data-tree appears to put 3 into Yang with appears to conflict with ODL.

Since you clearly don't want however Yang turns out to collide with ODL, but appear to be proposing something that collides, I must not understand?

Another use case:
ODL Yang device mounting is about grafting and removing whole, existing devices as branches in a single tree on a running system.
For this, there may be some benefit in treating the grafted branch as a special sort of node in the tree.
Having a special keyword like 'mount' might help this, or the application function that does 3) above could handle it.

Another use case is simply making a big device model by grafting together smaller, whole, existing models.
In this case, the benefit may be to make the grafted branch look like a non-special vanilla node in the tree.
In this case, I don't see the benefit over a special keyword like 'mount' over an existing one like 'uses'.

Regards,

Stuart

-----Original Message-----
From: Eric Voit (evoit) [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2016 12:20 PM
To: STUART VENTERS
Cc: [email-masked]; Martin Bjorklund (mbjorklu); 'Juergen Schoenwaelder'
Subject: RE: [netmod] Differentiating the types of Mount

Hi Stuart,

Thanks,
Eric
 
> Perhaps:
> 
> YANG Mount
>  ----------------
>  Definition: An abstracted term for a YANG mechanism that grafts a 
> sibling schema-tree as a subtree of a parent schema-tree.
>  Purpose: Provides flexibility by enabling the growth of YANG models 
> via an explicit reference to other YANG models defined elsewhere.
> 
> Given the ability to specify a combined schema-tree, maybe something 
> at the protocol level could specify what data to use to populate the grafted tree.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 16 Mar 2016 22:35:46 +0000

Hi Stuart,

Thanks for the thoughts.   More in-line...

> From: STUART VENTERS. March 16, 2016 3:49 PM
> 
> Eric,
> 
> I did the suggested OpenDaylight  (ODL)search, and yes there is a lot of activity
> there.  There are a lot of trees in that forest.
> 

ODL Mounts instance data.  One example showing how applications can get to that can be seen at:
http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount-point/

> Since you clearly don't want however Yang turns out to collide with ODL, but
> appear to be proposing something that collides, I must not understand?

I don't see the collision of (3) with the originally proposed definition for "Peer Mount".   It might be worth looking at:
https://tools.ietf.org/html/draft-clemm-netmod-mount-03 
which was used an initial seed for ODL's implementation of Peer Mount.

> Another use case:
> ODL Yang device mounting is about grafting and removing whole, existing
> devices as branches in a single tree on a running system.

Grafting, yes.  Not sure about removing as the Mount is a reference, not an actual relocation.

> that does 3) above could handle it.

There certainly are trade-offs between application-centric data representation and infrastructure-centric representation.  Open Daylight is a good test-case here as it provides network-wide abstractions to a diverse application set.   (I.e., the end-goal of Peer Mount always has been simplifying life for the application developer, and these network-wide abstractions are intended for this purpose.)
 
> existing one like 'uses'.

Peer Mount and Alias Mount are intended to enable the referencing of existing, populated data trees.   

Eric
 
> Open Daylight has found Mounting YANG data from one device to another has
> proven central to their effort.  Doing a quick Google search for "mount
> site:opendaylight.org" gives 800+ results.
> 
> Based on that, I was hoping that being defining the variants of Mount across
> different constituencies would help us not collide as the technologies evolve.
> This includes a shared definition of "YANG Mount" which shows what is common
> across all efforts.
> 
> Thanks,
> Eric
> 
> > Perhaps:
> >
> > YANG Mount
> >  ----------------

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 18 Mar 2016 21:25:01 +0000

I have placed the Mount definitions from the email discussion into:
draft-voit-netmod-yang-mount-requirements-00

This -00 draft isn't really that new.  It is just our recent email exchanges incorporated into the last version of:
draft-voit-netmod-peer-mount-requirements-03
But I renamed the -03 draft into an -00 one to acknowledge the growth of the mount concepts beyond Peer and Alias Mount.  (I.e., it was a convenient place to store the definitions/differentiations.)  

At this point the authors don't plan on incorporating the full set of requirements from Schema/Structural Mount into this document unless there is WG desire to consolidate Mount requirements in one place.

Eric