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

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 22 Mar 2013 15:00:14 +0000

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Mar 2013 09:05:16 -0700

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

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Sat, 23 Mar 2013 00:41:33 +0000

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:[email-masked]] 
Sent: Friday, March 22, 2013 9:05 AM
To: Alexander Clemm (alex)
Cc: [email-masked]; 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) <[email-masked]> wrote:
> Hi,
>
>
>
> We just posted last night a new Internet Draft "Mounting YANG-Defined 
> Information from Remote Datastores", see 
> 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.
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Mar 2013 18:26:28 -0700

Hi,

So a section of config is never actually shared?

If 2 clients mount the same shared config sub-tree,
then don't each of these servers think they own that sub-tree?
But when 1 server modifies the shared data, isn't the
data in the other server changed as well?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Mar 2013 19:08:01 -0700

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

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 25 Mar 2013 21:37:28 +0000

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:[email-masked]] 
Sent: Friday, March 22, 2013 7:08 PM
To: Alexander Clemm (alex)
Cc: [email-masked]; Eric Voit (evoit); Jan Medved (jmedved)
Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores

Hi,

      +------------------+
       |      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) <[email-masked]> wrote:
> 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 ;-)
>
>> 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.
>>
>>
>>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Mar 2013 15:34:23 -0700

"Instead, any mount client is "just a client", similar to e.g. a
service provisioning app."

Whatever the NETCONF server advertises as configuration in its
running config, a NETCONF client will think it is "just a server".
This breaks existing NETCONF clients.

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 25 Mar 2013 23:09:28 +0000

I am not clear how the presence of one Netconf client will break another Netconf client.   
I don't think there is anything that would prohibit a system that implements a Netconf client to act as a server to another application.  
How to have such a system implement full transactional capabilities has challenges, much like full transactionality is a challenge for a service provisioning application.  Agree, we need to call these out, in particular in as far it would mean not being able to support full transactional capabilities (at the level of the mount client in as far as it acts as a server to another app - I think it is these higher apps that you are concerned about - the clients of the clients, so to speak).   
--- Alex

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, March 25, 2013 3:34 PM
To: Alexander Clemm (alex)
Cc: [email-masked]; Eric Voit (evoit); Jan Medved (jmedved)
Subject: Re: [netmod] Mounting YANG-Defined Information from Remote Datastores

"Instead, any mount client is "just a client", similar to e.g. a service provisioning app."

Whatever the NETCONF server advertises as configuration in its running config, a NETCONF client will think it is "just a server".
This breaks existing NETCONF clients.

Andy

On Mon, Mar 25, 2013 at 2:37 PM, Alexander Clemm (alex) <[email-masked]> wrote:
>> must/when expressions to evaluate differently in each server just 
>> adds to the fun ;-)
>>
>>> We just posted last night a new Internet Draft "Mounting 
>>> YANG-Defined Information from Remote Datastores", see

---

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Mar 2013 16:26:59 -0700

Hi,

I am still not clear what problem is being solved here.
It sure looks like a really complicated form of NETCONF Proxy.
Operators begged us at the IAB Workshop on NM
not to let proxy servers anywhere near NETCONF.

You talk about mounting read-only shared config so
it can be rendered properly in an application.
This sounds like a mid-level manager job.

The NETCONF transaction model and definition of the running
datastore is very clear, and already complicated enough.
The protocol does not allow for "guest config" that is really
shared.  One could view it is just a huge implementation
detail I guess, making it completely proprietary and outside
the scope of the standard.

It also seems to be quite a security hole.
A vulnerability in server A can allow config
in server B to be changed.  A hole in the
access control could allow a hacker to mount
additional remote config sections from other routers,
spreading the attack through the network.

Andy

---

From: Anton Tkáčik <[email-masked]>
Date: Tue, 26 Mar 2013 13:59:46 +0100 (CET)

Hi,
The interesting idea in this draft is to reuse of existing YANG schemas
and nesting their data definitions in the other schemas (config/running tree).

YANG in current state does not allow reusing of containers defined in another modules
(it could be done by using anyxml statement but we loose machine-readable
semantics of the nested data).

For example if we want to model logical subsystems of network element by reusing ietf-interfaces
currently we have only one option:

    rw if:interfaces
    rw ls:logical-systems
    +-- rw ls:logical-system [id]
        +-- rw ls:interfaces

Where interfaces is leaflist of instance-identifier or leafref of interfaces.

With the nesting of data, the model is more straighforward and also the interfaces
for logical subsystem are separated in the tree.

rw ls:logical-systems
+-- rw ls:logical-system
    +-- rw if:interfaces

So I would suggest explore the use cases for the nesting YANG schemas / modules
in the tree, because mounting of remote datastores is only special use case 
of the YANG data nesting.

Anton Tkacik

----- Original Message -----
> From: "Andy Bierman" <[email-masked]>
> To: "Alexander Clemm (alex)" <[email-masked]>
> Cc: "Jan Medved (jmedved)" <[email-masked]>, [email-masked]
> Sent: Tuesday, March 26, 2013 12:26:59 AM
> Subject: [netmod] Mounting YANG-Defined Information from Remote Datastores
> 
> Hi,
> 
> > I don't think there is anything that would prohibit a system that
> > implements a Netconf client to act as a server to another application.
> > How to have such a system implement full transactional capabilities has
> > challenges, much like full transactionality is a challenge for a service
> > provisioning application.  Agree, we need to call these out, in particular
> > in as far it would mean not being able to support full transactional
> > capabilities (at the level of the mount client in as far as it acts as a
> > server to another app - I think it is these higher apps that you are
> > concerned about - the clients of the clients, so to speak).
> > --- Alex
> >
> > Whatever the NETCONF server advertises as configuration in its running
> > config, a NETCONF client will think it is "just a server".
> >> 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 serv
>  er 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
> >>
> >>> 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
> >>>
> >>> 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?
> >>>
> >>> 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.
> >>>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Mar 2013 07:06:08 -0700

What about the augment-stmt?
Why don't you think that counts as reuse.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Mar 2013 08:25:53 -0700

> and nesting their data definitions in the other schemas (config/running tree).

I did not realize you were trying to relocate data nodes or replicate them
in different parts of the config, for objects that are not defined in groupings.

I don't agree that replicating the interface list under some other (vendor)
config is a good idea.  I think leafrefs are a better design than replicating
the data nodes. Relocating data from its YANG defined location to a
different part of the tree is pointless for applications.  They use whatever
instance-identifier is plugged in and do not care where it is in the tree.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Mar 2013 15:02:38 +0100

Hi Alex,

while I do understand the use cases, there is one tough issue that the draft doesn't touch upon, namely client authentication. Consider a client connecting to a proxy server (= mount client) via ssh and using certificate authentication. How is the proxy server supposed to authenticate against the mount server without having the client's private key?

We all know that authentication in the original NFS is broken, and requiring things like Kerberos for NETCONF is a non-starter.

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Mar 2013 15:20:02 +0100

Hi,

> and nesting their data definitions in the other schemas (config/running tree).

IMO the draft is about sharing a subtree from a remote datastore (i.e., an instance document in XML terms) and not about reusing schemas. The draft assumes that all checks are done on the mount server.

> for logical subsystem are separated in the tree.

YANG is not designed to allow such an bottom-up approach. Note that this could for example break XPath expressions.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Mar 2013 07:47:54 -0700

> IMO the draft is about sharing a subtree from a remote datastore (i.e., an instance document in XML terms) and not about reusing schemas. The draft assumes that all checks are done on the mount ser…

The operators at the IAB NM Workshop discussed why they
did not like SNMP Proxy, citing cascading security vulnerabilities
and unwarranted complexity.  NETCONF Proxy looks even worse.

The server mounting the shared data sub-trees is still obligated
to provide all the functionality it advertises to RFC 6241 compliant
clients.  In order for the config nodes to be read-only, the server
must advertise deviation statements that change the config=true
to config=false nodes.

In order for the shared data nodes to be config=true,
the server must honor all supported operations,
including locking.  Locks on shared nodes has to be enforced
on all servers that have the shared data.  There is no authoritative
server according to RFC 6241.  There is only the 1 server that
the client is managing with 1 NETCONF session.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Mar 2013 08:30:56 -0700

Hi,

This seems to make existing NETCONF security weaknesses
even worse.

A NETCONF client that is able to invoke the <lock> operation on
the running config on 1 server will prevent all sessions on all
other servers from writing any of the shared config in the
locked server.  This gets complicated with N servers, each with
potentially different shared data.  Once any shared data is locked,
no server that has that data can allow its config to be
globally locked (already partially locked).

The normal datastore edit procedure (lock + edit + unlock)
will create a management plane bottleneck for all the
servers sharing data.  Clients will compete for locks (first wins)
across all servers, not 1.  Could be an interesting DoS attack.

Andy