Re: [netmod] Mounting YANG-Defined Information from Remote Datastores

["Alexander Clemm (alex)" <[e-mail]>]

Hi Andy,

Correct, if information in the server (S1 in this case) is updated, the change will show up in the places that mount that information (S2 and S3, in this case), just like changes made by a provisioning system to a server will show up in other applications when they obtain a view of the configuration information on a server.  

Our proposal does not make transactionality issues disappear, just like a provisioning system cannot guarantee transactionality to its clients if the underlying server(s) do not provide corresponding support as well.  These dependencies and what our proposal does and does not do are something we will make clearer in the next revision.  At the same time, with the mount proposal, it is always clear who the authorative copy/owner of data is where the data is maintained, validated, etc. There is an authorative copy, and authorative owner; this is not about "peers" sharing "equal copies" that need to be kept in synch etc.  Instead, any mount client is "just a client", similar to e.g. a service provisioning app.  Another way to look at a mount client is as a "proxy", retrieving and accessing information on another client's behalf.  The fact that the client "mounts" information from the server does not change anything for the server; it does not affect its model, nor how the server maintains its datastore.   The mount proposal does make it easier for such a client application to render information that it accesses from another system in a way that does not require to maintain and implement a separate set of data models that would in effect duplicate the same information.  

Regards
--- Alex

-----Original Message-----
From: Andy Bierman [mailto:[e-mail]] 
Sent: Friday, March 22, 2013 7:08 PM
To: Alexander Clemm (alex)
Cc: [e-mail]; Eric Voit (evoit); Jan Medved (jmedved)
Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores

Hi,

Let me try a simple example:

There are 3 servers (S1, S2, S3):

      +------------------+
       |      S1        | --> /public
       +-----------------+


      +------------------+
       |      S2        | -->  mount(S1:/public)
       +-----------------+


      +------------------+
       |      S3        | --> mount(S1:/public)
       +-----------------+

S1 is the server that is sharing the subtree /public.
S2 and S3 both 'clients', and mount S1:/public in their configs.
Any changes to /public done on any server magically appear on the other 2 servers.  Correct or not?

IMO, NFS is a fairly heavy-weight protocol and making NETCONF as complex as NFS is not a feature.



Andy


On Fri, Mar 22, 2013 at 5:41 PM, Alexander Clemm (alex) <[e-mail]> wrote:
> Hello Andy,
>
> What we have in mind is a little less complicated than what you are concerned with.
>
> Think of a mount client as a client app, like other client apps.  This can be transparent to the owner/server of the datastore with the data items that are mounted.  The owner/server of the datastore with mounted data items really isn't affected at all, nor are other client applications that interact with the same server; the mount client constitutes just another client application.  The "ownership" of the data - the master copy, if you will - is not in question, and not changed by our proposal.  Validation still occurs in the original datastore.  The mount client merely "renders" the information that is retrieved, and operated on, in a way that makes it appear as if it were part of its own datastore.  However, the mount client now does have the capability to validate "its" configurations in its own datastore (the ones that it actually owns, not ones that are mounted) against other configurations in the network.  This is a problem today, where you need to rely on external applications to ensure network-wide consistency.
>
> Many uses for this only require providing visibility and the ability to retrieve information.  Only some of the use cases involve the need to actually modify information from remote.  Where that is the case, the mount client acts analogous to a provisioning application as far as the server is concerned.  Obviously, transactionality is an issue for a mount client, just like it is an issue to a provisioning application.  Where a client app is not able to obtain a needed lock, for instance, it cannot provide a lock to its own applications, which is really no different from the situation that a provisioning application that provisions a service across a network would face.
>
> Regards
> --- Alex
>
> -----Original Message-----
> From: Andy Bierman [mailto:[e-mail]]
> Sent: Friday, March 22, 2013 9:05 AM
> To: Alexander Clemm (alex)
> Cc: [e-mail]; Eric Voit (evoit); Jan Medved (jmedved)
> Subject: Re: [netmod] Mounting YANG-Defined Information from Remote 
> Datastores
>
> Hi,
>
> I'm not sure I understand the use-cases here.
> This is certainly a different approach to network-wide config.
> This would seem to require that all the NETCONF servers sharing the same config subtree need to be highly coordinated, since operations on each server affect all the others.
>
> For example, if a client takes out a partial-lock on a shared node from server-1, it has to check all the other servers and the lock is shared across all servers. Access control would also be shared I guess.
>
> Do the contexts of shared nodes in candidate configs magically change or do they stay out-of-date if modified in another server?
> Does the entire running config in every server have to validate before any 1 server can commit a change to a shared node?
>
> The complexities this adds to the NETCONF transaction model and 
> confirmed commit procedure are dramatic.  The possibilities for 
> must/when expressions to evaluate differently in each server just adds 
> to the fun ;-)
>
> In previous discussions on network-wide configuration it was assumed a YANG model representing the network wide feature would be provided by a single server, and it is an implementation detail how that server interacts with other network devices.
>
> I do not see the advantages of treating the config like an NFS file system.
>
>
>
> Andy
>
>
> On Fri, Mar 22, 2013 at 8:00 AM, Alexander Clemm (alex) <[e-mail]> wrote:
>> Hi,
>>
>>
>>
>> We just posted last night a new Internet Draft "Mounting YANG-Defined 
>> Information from Remote Datastores", see 
>> http://tools.ietf.org/html/draft-clemm-netmod-mount-00.
>>
>>
>>
>> The draft addresses the problem of how to reference information from 
>> remote datastores, without needing to actually replicate that 
>> information (in its own model and datastore).  This helps address 
>> multiple problems, for example the issue of maintaining an 
>> authorative set of global configuration settings that are shared and 
>> exposed by multiple devices, and the issue of allowing one device to 
>> expose information about the network and other devices without need for replication, but in a federated way.
>>
>>
>>
>> The abstract reads as follows:
>>
>>    This document introduces a new capability that allows YANG 
>> datastores
>>
>>    to reference and incorporate information from remote datastores.
>>
>>    This is accomplished using a new YANG data model that allows to
>>
>>    define and manage datastore mount points that reference data nodes 
>> in
>>
>>    remote datastores.  The data model includes a set of YANG 
>> extensions
>>
>>    for the purposes of declaring such mount points.
>>
>>
>>
>> We are looking forward to discussing this with the working group and 
>> welcome your feedback.
>>
>>
>>
>> Regards
>>
>> --- Alex
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>