Re: [netmod] Differentiating the types of Mount

["Eric Voit (evoit)" <[e-mail]>]

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.
> 
> 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.

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.

> 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.

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.)
 
> 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'.

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

Eric
 
> Regards,
> 
> Stuart
> 
> 
> -----Original Message-----
> From: Eric Voit (evoit) [mailto:[e-mail]]
> Sent: Wednesday, March 16, 2016 12:20 PM
> To: STUART VENTERS
> Cc: [e-mail]; Martin Bjorklund (mbjorklu); 'Juergen Schoenwaelder'
> Subject: RE: [netmod] Differentiating the types of Mount
> 
> > From: STUART VENTERS, March 16, 2016 12:58 PM
> >
> > 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.
> 
> 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.
> > 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:[e-mail]] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Wednesday, March 16, 2016 6:23 AM
> > To: Eric Voit (evoit)
> > Cc: [e-mail]; Martin Bjorklund (mbjorklu)
> > Subject: Re: [netmod] Differentiating the types of Mount
> >
> > On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote:
> > > 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.
> >
> > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <http://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod