Subject: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 30 Oct 2014 19:16:53 +0000

Andy,

Two weeks ago I promised a useful YANG model which exposes both device and domain config.  The model is here:

http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-model-00.txt

A simple "Cloud Policer" application can sit completely upon the model.  The algorithm might be:

(1) The Operator enters a maximum data rate across a federation (Cloud) of devices

(2) Sum the current bandwidth across the collection of devices in the federation (via RFC 7223 YANG device interface statistics)

(3) Policed Bandwidth rate each device = (current traffic to the device / current federation traffic) * Operator established Federation Max rate

(4) Go back to step (2)

If we set the federation bandwidth to 100MB/s, and then vary the offered to two devices, the result looks like this.

Effectively we are showing the config of domain and device upon one graph.  And the device config is varying over time based on Peer Mounted RFC 7223 YANG interface statistics.

This is running code.  The code is portable so that it can run on a controller, or it can run upon a designated router within the federation.

Eric

From: Andy Bierman, October 14, 2014 6:47 PM
<snip>

I do not agree that the "collection of device models" is a very interesting solution
for network management at the network level.  We have dabbled with "network-wide"
configuration a couple times, only to drop the issue.  IMO the models at this level
describe the network, not the devices.  There is some glue that tells the controller what devices are
available, and how to talk to them, but the goal is to handle the device level details
as part of the controller data model implementation.

<Eric> We have a YANG model for Cloud Policer and DDoS Thresholding which exposes the interplay of domain and device view.   I will strive to get it posted as a new draft before Oct 27th.  (IETF 91 cut-off date.)

Eric

Eric Voit
Principal Engineer - CSG

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Oct 2014 13:17:57 -0700

On Thu, Oct 30, 2014 at 12:16 PM, Eric Voit (evoit) <[email-masked]> wrote:

> A simple “Cloud Policer” application can sit completely upon the model.
> The algorithm might be:
>
>
>
> (2) Sum the current bandwidth across the collection of devices in the
> federation (via RFC 7223 YANG device interface statistics)
>
>
>
> (3) Policed Bandwidth rate each device = (current traffic to the device /
> current federation traffic) * Operator established Federation Max rate
>
>
>
> (4) Go back to step (2)
>
>
>
> If we set the federation bandwidth to 100MB/s, and then vary the offered
> to two devices, the result looks like this.
>
>
>
> Effectively we are showing the config of domain and device upon one
> graph.  And the device config is varying over time based on Peer Mounted
> RFC 7223 YANG interface statistics.
>
>
>
> This is running code.  The code is portable so that it can run on a
> controller, or it can run upon a designated router within the federation.
>

I don't think the application needs YANG Mount to accomplish its task.
This has nothing to do with the issue of device-configured vs.
controller-configured data collection.  Any controller can collect some
subtrees
from each device and use the data somehow.  Just use NETCONF or
RESTCONF as-is.  It really complicates the architecture to use mount points,
especially if every controller is going to replicate data from every server
in
different ways, and force the devices to do all the work.

> Eric

Andy

>
>
>
>
> *From:* Andy Bierman, October 14, 2014 6:47 PM
>
> <snip>
>
>
>
> <Eric> We have a YANG model for Cloud Policer and DDoS Thresholding which
> exposes the interplay of domain and device view.   I will strive to get it
> posted as a new draft before Oct 27th.  (IETF 91 cut-off date.)
>
>
>
> Eric
>
>
>
>
>
>
>
>
>
> Eric Voit
>
> Principal Engineer - CSG
>
>
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 30 Oct 2014 16:31:26 -0400

> On Oct 30, 2014:4:17 PM, at 4:17 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Thu, Oct 30, 2014 at 12:16 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> wrote:
> Andy,
> 
>  
> 
> http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-model-00.txt <http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-model-00.txt>
>  
> 
> A simple “Cloud Policer” application can sit completely upon the model.  The algorithm might be:
> 
>  
> 
> controller-configured data collection.  Any controller can collect some subtrees
> from each device and use the data somehow. 

	The point of mount isn’t for the controller’s convenience per se; its for the app that wants to get at those stats. The app only needs to talk to a single controller.

> Just use NETCONF or
> especially if every controller is going to replicate data from every server in

	It complicates it for the controller but has the advantage of simplifying it for potentially many, many more applications that rely on the controller’s abstraction of the universe.

	—Tom

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 30 Oct 2014 20:48:27 +0000

From: Thomas D. Nadeau, October 30, 2014 4:31 PM

On Oct 30, 2014:4:17 PM, at 4:17 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Oct 30, 2014 at 12:16 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Andy,

(4) Go back to step (2)

<Eric>  Agree.   It is *possible* to do some of this with existing Netconf.  But it gets ugly.  Application developers lose the following benefits:

Application Simplification

• Major code size reduction → data access only to local Datastore

• Caching and polling becomes hidden infrastructure

Application Robustness

• Distributed YANG objects available to applications without needing to acquire the data themselves

• Can run between Network Elements, where some controllers already reside

Application Performance

• On-change & Periodic object Pub/Sub with transparent caching

• Scaling benefits: ability to cascade updates across multiple tiers of Mount

Misconfiguration Types Eliminated

• Authoritative copy in Federation transparently used

• Mount & monitor the actual state of the network (apps don’t just get one-time “ACK”).
In other words, we are trying to make life easier for Application Developers.  Especially developers of applications which span federations of network devices.

Eric

Just use NETCONF or

          —Tom

Eric

Andy

Eric

Eric Voit
Principal Engineer - CSG

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Oct 2014 14:22:55 -0700

Hi,

I guess you are not really understanding my point.
I am concerned on the complexity pushed on the devices to somehow
be configured to find each controller, register some data subtrees
to mount, and then push data to each controller.

I don't see that it saves work as much as moves it from a relatively small
number of controllers to a large number of servers.  Are operators going
to configure the devices or are the controllers going to configure themselves
in each server? Seems too complicated to me.

I think the polling can be optimized (If-Match, If-Modified-Since, etc.).
This approach (already in RESTCONF, but really only for config=true)
could be applied to operational state as well.

There needs to be a minimum update interval or the controllers can get overrun
with pushed data.  IMO the controllers should be polling for changes at
the rate they want data.

If the operational state changes in someway that is interesting to the operator,
then the traditional approach of defining and sending a notification
event works fine.

Andy

On Thu, Oct 30, 2014 at 1:48 PM, Eric Voit (evoit) <[email-masked]> wrote:
> Effectively we are showing the config of domain and device upon one graph.
> And the device config is varying over time based on Peer Mounted RFC 7223
> YANG interface statistics.
>
>
>
>           The point of mount isn’t for the controller’s convenience per se;
> its for the app that wants to get at those stats. The app only needs to talk
> to a single controller.
>
>
>
> <Eric>  Agree.   It is *possible* to do some of this with existing Netconf.
> But it gets ugly.  Application developers lose the following benefits:
>
>
>
> In other words, we are trying to make life easier for Application
> Developers.  Especially developers of applications which span federations of
> network devices.
>
>
>
> Eric
>
>
>
> Just use NETCONF or
>
>           It complicates it for the controller but has the advantage of
> simplifying it for potentially many, many more applications that rely on the
> controller’s abstraction of the universe.
>
>
>
>           —Tom
>
>
>
>
>
>
>
>
>
>
>
>
>
> Eric
>
>
>
>
>
> Andy
>
>
>
>
>
>
>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 31 Oct 2014 00:17:25 +0000

Hi Andy,

controllers / mount clients have the option to subscribe to updates in any way they deem fit.  In fact, on-demand will usually be the default.  Polling optimizations along the lines that you suggest (if-modified-since) make sense as well, although presumably adding complexity to the server implementation as well.  

For pushing data, it is definitely conceivable to add a throttle mechanism that the client can use.  The simplest mechanism of course is to dimension the minimum interval between updates as needed.  

To add to the Eric's earlier point, the issue is not that you could not achieve the same application going to the different devices directly.  The issue is that in that case you push the complexity to the application developer of having to deal with the complexity of dealing with each device individually.  Not every system may support mount points, just like not every system may support any other YANG module.  But why limit those that are able to support it from doing so, in particular as there are clearly applications and deployment scenarios where this is needed and makes sense.    

--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, October 30, 2014 2:23 PM
To: Eric Voit (evoit)
Cc: [email-masked]
Subject: Re: [netmod] YANG model containing both device and domain config (was RE: New revision of YANG mount draft)

Hi,

I guess you are not really understanding my point.
I am concerned on the complexity pushed on the devices to somehow be configured to find each controller, register some data subtrees to mount, and then push data to each controller.

I don't see that it saves work as much as moves it from a relatively small number of controllers to a large number of servers.  Are operators going to configure the devices or are the controllers going to configure themselves in each server? Seems too complicated to me.

I think the polling can be optimized (If-Match, If-Modified-Since, etc.).
This approach (already in RESTCONF, but really only for config=true) could be applied to operational state as well.

There needs to be a minimum update interval or the controllers can get overrun with pushed data.  IMO the controllers should be polling for changes at the rate they want data.

If the operational state changes in someway that is interesting to the operator, then the traditional approach of defining and sending a notification event works fine.

Andy

On Thu, Oct 30, 2014 at 1:48 PM, Eric Voit (evoit) <[email-masked]> wrote:
> (3) Policed Bandwidth rate each device = (current traffic to the 
> device / current federation traffic) * Operator established Federation 
> Max rate
>
>
>
> (4) Go back to step (2)
>
>
>
> If we set the federation bandwidth to 100MB/s, and then vary the 
> offered to two devices, the result looks like this.
>
>
>
>
> And the device config is varying over time based on Peer Mounted RFC 
> 7223 YANG interface statistics.
>
>
>
>           The point of mount isn’t for the controller’s convenience 
> per se; its for the app that wants to get at those stats. The app only 
> needs to talk to a single controller.
>
>
>
> Developers.  Especially developers of applications which span 
> federations of network devices.
>
>
>
> Eric
>
>
>
> Just use NETCONF or
>
>           It complicates it for the controller but has the advantage 
> of simplifying it for potentially many, many more applications that 
> rely on the controller’s abstraction of the universe.
>
>
>
>           —Tom
>
>
>
>
>
>
>
>
>
>
>
>
>
> Eric
>
>
>
>
>
> Andy
>
>
>
>
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Oct 2014 17:41:51 -0700

On Thu, Oct 30, 2014 at 5:17 PM, Alexander Clemm (alex) <[email-masked]> wrote:
> Hi Andy,
>
> controllers / mount clients have the option to subscribe to updates in any way they deem fit.

Does this mean the servers have to implement several ways to do the same
thing, so the client can choose?

I think we disagree on where the system complexity belongs.

 In fact, on-demand will usually be the default.  Polling
optimizations along the lines that you suggest (if-modified-since)
make sense as well, although presumably adding complexity to the
server implementation as well.
> To add to the Eric's earlier point, the issue is not that you could not achieve the same application going to the different devices directly.  The issue is that in that case you push the complexity…

The application developer still needs to understand YANG data to do aggregation
and other useful tasks.  Blind data replication is not very important,
compared to all the
other stuff a controller could be doing.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 31 Oct 2014 03:29:44 +0000

> From: Andy Bierman, October 30, 2014 8:42 PM

> On Thu, Oct 30, 2014 at 5:17 PM, Alexander Clemm (alex) <[email-masked]<mailto:[email-masked]>>

> wrote:

> > controllers / mount clients have the option to subscribe to updates in any way

> they deem fit.

> I think we disagree on where the system complexity belongs.

We are removing complexity from the application developer (see my eight bullets from earlier today).  We are allowing layered abstractions (as shown via draft-tripathy).  Both are worthy goals.   If you want to leave such complexity exposed, nobody is saying you cannot do that.

>  In fact, on-demand will usually be the default.  Polling optimizations along the

> lines that you suggest (if-modified-since) make sense as well, although

> presumably adding complexity to the server implementation as well.

> > For pushing data, it is definitely conceivable to add a throttle mechanism that

> the client can use.  The simplest mechanism of course is to dimension the

> minimum interval between updates as needed.

> > To add to the Eric's earlier point, the issue is not that you could not achieve the

> same application going to the different devices directly.  The issue is that in that

> case you push the complexity to the application developer of having to deal with

> the complexity of dealing with each device individually.  Not every system may

> support mount points, just like not every system may support any other YANG

> module.  But why limit those that are able to support it from doing so, in

> particular as there are clearly applications and deployment scenarios where this

> is needed and makes sense.

> and other useful tasks.  Blind data replication is not very important, compared to

> all the other stuff a controller could be doing.

The OpenDaylight controller has already implemented<http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount-point/> Mount as one of its most essential basic functions.  If it wasn't important, it wouldn't have been done.

The question is not whether Yang Mount is going to happen.  It is whether the IETF wants to be involved.

Eric

> > From: netmod [mailto:[email-masked]] On Behalf Of Andy

> > Bierman

> > Cc: [email-masked]<mailto:[email-masked]>

> > Subject: Re: [netmod] YANG model containing both device and domain

> > config (was RE: New revision of YANG mount draft)

> > I am concerned on the complexity pushed on the devices to somehow be

> configured to find each controller, register some data subtrees to mount, and

> then push data to each controller.

> number of controllers to a large number of servers.  Are operators going to

> configure the devices or are the controllers going to configure themselves in

> each server? Seems too complicated to me.

> > This approach (already in RESTCONF, but really only for config=true) could be

> applied to operational state as well.

> > There needs to be a minimum update interval or the controllers can get

> overrun with pushed data.  IMO the controllers should be polling for changes at

> then the traditional approach of defining and sending a notification event works

> fine.

> > On Thu, Oct 30, 2014 at 1:48 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

> >> On Oct 30, 2014:4:17 PM, at 4:17 PM, Andy Bierman

> >> <[email-masked]<mailto:[email-masked]>>

> >> wrote:

> >> Two weeks ago I promised a useful YANG model which exposes both

> >> device and domain config.  The model is here:

> >> http://www.ietf.org/internet-drafts/draft-tripathy-cloud-sla-yang-mod

> >> e

> >> l-00.txt

> >> A simple “Cloud Policer” application can sit completely upon the

> >> model.  The algorithm might be:

> >> (1) The Operator enters a maximum data rate across a federation

> >> (Cloud) of devices

> >> device / current federation traffic) * Operator established

> >> Federation Max rate

> >> controller-configured data collection.  Any controller can collect

> >> some subtrees

> >> per se; its for the app that wants to get at those stats. The app

> >> only needs to talk to a single controller.

> >> • Distributed YANG objects available to applications without needing

> >> to acquire the data themselves

> >> • Can run between Network Elements, where some controllers already

> >> reside

> >> • Scaling benefits: ability to cascade updates across multiple tiers

> >> of Mount

> >> • Mount & monitor the actual state of the network (apps don’t just

> >> get one-time “ACK”).

> >> RESTCONF as-is.  It really complicates the architecture to use mount

> >> points,

> >> especially if every controller is going to replicate data from every

> >> server in

> >> I do not agree that the "collection of device models" is a very

> >> interesting solution

> >> for network management at the network level.  We have dabbled with

> >> "network-wide"

> >> configuration a couple times, only to drop the issue.  IMO the models

> >> at this level

> >> describe the network, not the devices.  There is some glue that tells

> >> the controller what devices are

> >> available, and how to talk to them, but the goal is to handle the

> >> device level details

> >> <Eric> We have a YANG model for Cloud Policer and DDoS Thresholding

> which

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 31 Oct 2014 07:51:32 +0100 (CET)

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> The OpenDaylight controller has already
> implemented<http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount-point/>
> Mount as one of its most essential basic functions.  If it wasn't important, it
> wouldn't have been done.
> 
> 
> 

A clarification question: are we talking about read-only mounting or
read-write?

As I have written before, I believe the mechanism proposed doesn't
really work for read-write access.

/martin

---

From: Qin Wu <[email-masked]>
Date: Fri, 31 Oct 2014 07:00:25 +0000

Yes, I have same question.
by reading draft-tripathy-cloud-sla-yang-model-00, It seems to me it only supports read object from remote datastore, but doesn't support write object back into remote datastore.

Regards!
-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Martin Bjorklund
发送时间: 2014年10月31日 14:52
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [netmod] YANG model containing both device and domain config

Hi,

"Eric Voit (evoit)" <[email-masked]> wrote:
> implemented<http://sdntutorials.com/how-to-access-data-in-md-sal-from-
> mount-point/> Mount as one of its most essential basic functions.  If 
> it wasn't important, it wouldn't have been done.
> 
> 
> 

A clarification question: are we talking about read-only mounting or read-write?

As I have written before, I believe the mechanism proposed doesn't really work for read-write access.

/martin

---

From: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Fri, 31 Oct 2014 07:07:18 +0000

Hi,
This mount is only for read. Not for write.
Br,
Ambika

Sent from my Windows Phone
________________________________
From: Qin Wu<mailto:[email-masked]>
Sent: ‎31-‎10-‎2014 12:30
To: Martin Bjorklund<mailto:[email-masked]>; Eric Voit (evoit)<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] YANG model containing both device and domain config

Regards!
-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Martin Bjorklund
发送时间: 2014年10月31日 14:52
收件人: [email-masked]
抄送: [email-masked]
主题: Re: [netmod] YANG model containing both device and domain config

Hi,

/martin

---

From: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Fri, 31 Oct 2014 09:53:50 +0000

Hi,

Adding more info how mount works:

Mount brings One authoritative copy of an object across a Network. It is read only to the data store to get a snapshot of the mounted data store based on mount policies defied in another IETF draft “peer-mount-requirements<http://tools.ietf.org/html/draft-voit-netmod-peer-mount-requirements-01>”

Mount is not a mechanism to configure a device or write to remote data store.  For that existing interfaces are already there.

If devices want to get some configuration data from a namespace of the controller data store, then applications running in the device can mount it from the controller datastore.
For example, for the policer yang model defined in draft draft-tripathy-cloud-sla-yang-model-00, applications running in device which is responsible of policing data for the domain in the device, can mount the “container policing-policies” to get new police values when there is a change in policy rate by cloud application.

Br,
Ambika

From: netmod [mailto:[email-masked]] On Behalf Of Ambika Prasad Tripathy (ambtripa)
Sent: Friday, October 31, 2014 12:37 PM
To: Qin Wu; Martin Bjorklund; Eric Voit (evoit)
Cc: [email-masked]
Subject: Re: [netmod] YANG model containing both device and domain config

Hi,

Regards!
-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Martin Bjorklund
发送时间: 2014年10月31日 14:52
收件人: [email-masked]<mailto:[email-masked]>
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [netmod] YANG model containing both device and domain config

Hi,

> implemented<http://sdntutorials.com/how-to-access-data-in-md-sal-from-
<http://sdntutorials.com/how-to-access-data-in-md-sal-from-%0b>> mount-point/> Mount as one of its most essential basic functions.  If

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Oct 2014 11:10:47 +0100

> Mount is not a mechanism to configure a device or write to remote data store.  For that existing interfaces are already there.

Well, there are also existing interfaces to read config and state
data. ;-)

> For example, for the policer yang model defined in draft draft-tripathy-cloud-sla-yang-model-00, applications running in device which is responsible of policing data for the domain in the device, c…

This use case I find actually more interesting but then I am not sure
I understand how this works or whether a plain mount is the way to do
this. If a device mounts some policy information, does this mean the
device commits to follow the policy information, that is to change the
operational state according to the policy? If so, how are conflicts
resolved? What is the lifetime of the injected config state? Is it
ephemeral? Is it bound to the mount? How does this relate to I2RS?
They intend to push configuration while you seem to let the device
pull some configuration from a controller. Will both internally be
treated the same way?

I believe it is worth looking into the use case where a device wants
to pull configuration from a 'controller' instead of having the
'controller' to push the configuration. Whether mount is the right
solution for this, I can't tell at this point in time.

/js (speaking as contributor)

-- 
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: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Fri, 31 Oct 2014 10:33:48 +0000

Hi ,

Yes. There are other mechanism to pull the data from device when required by controller based application, but mount is more than that. The existing pulling mechanism is just one part of what mount describes are on-demand mount policy. The existing pulling mechanism is not providing eventually consistency across the network which is need by the Domain policer application descried in draft. For that mount is a better way.

When application mount's any object to remote data store, it is up to the application how to use the objects. Mount is not enforcing to use those objects by the application nor it not overriding any policy of the application which is mounting. The application who own the authoritative copy of object, they should decide on how to use it.

Br,
Ambika

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, October 31, 2014 3:41 PM
To: Ambika Prasad Tripathy (ambtripa)
Cc: Qin Wu; Martin Bjorklund; Eric Voit (evoit); [email-masked]
Subject: Re: [netmod] YANG model containing both device and domain config

> Mount is not a mechanism to configure a device or write to remote data store.  For that existing interfaces are already there.

Well, there are also existing interfaces to read config and state data. ;-)

> For example, for the policer yang model defined in draft draft-tripathy-cloud-sla-yang-model-00, applications running in device which is responsible of policing data for the domain in the device, c…

This use case I find actually more interesting but then I am not sure I understand how this works or whether a plain mount is the way to do this. If a device mounts some policy information, does this mean the device commits to follow the policy information, that is to change the operational state according to the policy? If so, how are conflicts resolved? What is the lifetime of the injected config state? Is it ephemeral? Is it bound to the mount? How does this relate to I2RS?
They intend to push configuration while you seem to let the device pull some configuration from a controller. Will both internally be treated the same way?

I believe it is worth looking into the use case where a device wants to pull configuration from a 'controller' instead of having the 'controller' to push the configuration. Whether mount is the right solution for this, I can't tell at this point in time.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Oct 2014 13:09:30 +0100

Hi,

I think we need to separate the discussion clearly between:

a) a controller mounting read-only data from a set of NC servers

b) a NC server mounting data from a set of controllers

For me, these are very different things. I can't parse your answer
because I do not know when you talk about a) and when about b) and
because of that I do not know what 'application' is or why eventual
consistency is important.

/js

---

From: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Fri, 31 Oct 2014 12:50:50 +0000

Hi,

To clear you first NetConf server is not a mount client. Mount client has the capability to mount to a Mount Server. 

<js>
</js>

Mount client present in controller mounting read-only data from a set of mount server. Mount server is interacting with local datastore. If NetConf server has the functionally of Mount Server then the statement is right.

<js>
b) a NC server mounting data from a set of controllers.
</js>

If NetConf server has mount client functionality, it can mount from a set of controller. But ideally, the mount client should mount data to a mount server, in this case, the mount server should be a part of controller. 

NetConf can be used as a transport between mount client and mount server and it is implementation dependent. 

Br,
Ambika

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, October 31, 2014 5:40 PM
To: Ambika Prasad Tripathy (ambtripa)
Cc: Qin Wu; Martin Bjorklund; Eric Voit (evoit); [email-masked]
Subject: Re: [netmod] YANG model containing both device and domain config

Hi,

For me, these are very different things. I can't parse your answer because I do not know when you talk about a) and when about b) and because of that I do not know what 'application' is or why eventual consistency is important.

/js

On Fri, Oct 31, 2014 at 10:33:48AM +0000, Ambika Prasad Tripathy (ambtripa) wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> config

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 31 Oct 2014 09:37:28 -0400

Speaking as chair,

	Is it worth separating out r-o and r-w behavior to help move the conversation forward?

	--Tom

> On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
>

---

From: Sander Mertens <[email-masked]>
Date: Fri, 31 Oct 2014 09:55:08 -0400

Hi,

Please note that it is at the very least not technically unfeasible to have
both read-only and read-write behavior in the proposed architecture. As an
example, any implementation of OMG-DDS allows for this behavior.

The semantics can be questionable in a case where there is one clear owner
of the data, with perhaps the notable exception of multiple redundant
servers. For the latter usecase (deployed) patterns already exist that
effectively handle these scenarios.

Cheers,
Sander

On 31 October 2014 09:37, Thomas D. Nadeau <[email-masked]> wrote:

> >> implemented<
> http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount-point/>
> >> The question is not whether Yang Mount is going to happen.  It is
> whether the
> >> IETF wants to be involved.
> >

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 31 Oct 2014 10:02:42 -0400

That is part of why I am asking if it makes sense to separate things. In the first case, the read-only method does fit in the current architecture and might be easier to progress at the moment. The other part might need to be in “Yang 2.0”.

	—Tom

> On Oct 31, 2014:9:55 AM, at 9:55 AM, Sander Mertens <[email-masked]> wrote:
> 
> Hi,
> 
> Please note that it is at the very least not technically unfeasible to have both read-only and read-write behavior in the proposed architecture. As an example, any implementation of OMG-DDS allows for this behavior.
> 
> The semantics can be questionable in a case where there is one clear owner of the data, with perhaps the notable exception of multiple redundant servers. For the latter usecase (deployed) patterns already exist that effectively handle these scenarios.
> 
> Cheers,
> Sander
> 
> On 31 October 2014 09:37, Thomas D. Nadeau <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Speaking as chair,
> 
> > On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi,
> >
> > "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]>> wrote:
> >> implemented<http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount-point/ <http://sdntutorials.com/how-to-access-data-in-md-sal-from-mount-point/>>
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> >
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 31 Oct 2014 07:56:02 -0700

Hi,

Maybe you can explain to me (because the authors can't) why
we need mechanisms for devices to replicate their data on
a controller?  Why problem does this solve?

Why is the device initiating the mount?  How is the
controller-specific config managed in each device and
why is this easier/better than just configuring the controller
to replicate data?

I am much more concerned about resources and complexity in the devices
than in the controllers.  Why put complex code in 1000 boxes when
it can go in just 10? Why configure 1000 boxes when you can
just configure just 10?

What happens when 1000 devices are pushing
operational state changes too fast? How much device and network
overhead is acceptable?  Polling has its drawbacks but flooding
the collector isn't one of them.  It seems like a burst of operational
updates would correlate with bursts of network activity,
making congestion even worse.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 31 Oct 2014 16:05:59 +0100

Hi,

I am getting a bit more confused - this has nothing to do with NETCONF
or RESTCONF anymore? When you say 'datastore', does it mean the same
thing that I think a 'datastore' is? What are the semantics of the
interaction between your mount client and mount server? All
implementation dependent and thus non-interoperable? IETF standards
are about interoperability.

When you write "But ideally, the mount client should mount data to a
mount server, in this case, the mount server should be a part of
controller", you seem to imply that ideally there is some other
protocol involved. What is this other protocol and what are the
semantics? Does your implementation only work with NC servers that
have an associated Mount Client?

Does any of the documents clarify all this? Any cool simple figures or
highlevel summaries or terminology definitions I should look at?

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 31 Oct 2014 17:44:51 +0000

I am fine with splitting read and write.  The one caveat here is that we will eventually explore High Availability clusters where a federation of Mount Servers provide the authoritative data.  But any solutions can still be a separate technology draft.

As Sander notes below, such HA clustering is running in DDS.  Based on his experience with this code, he wrote the High Availability portion of the requirements draft (Section 5.7).  So we can lean on him as to how it might be done ;-).

Eric

From: Thomas D. Nadeau, October 31, 2014 10:03 AM

          —Tom

On Oct 31, 2014:9:55 AM, at 9:55 AM, Sander Mertens <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers,
Sander

On 31 October 2014 09:37, Thomas D. Nadeau <[email-masked]<mailto:[email-masked]>> wrote:

        Speaking as chair,

        --Tom

> On Oct 31, 2014:2:51 AM, at 2:51 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>

---

From: Sander Mertens <[email-masked]>
Date: Fri, 31 Oct 2014 15:46:05 -0400

On 31 October 2014 13:44, Eric Voit (evoit) <[email-masked]> wrote:

>  I am fine with splitting read and write.  The one caveat here is that we
> will eventually explore High Availability clusters where a federation of
> Mount Servers provide the authoritative data.  But any solutions can still
> be a separate technology draft.
>

I agree. To facilitate the discussion we can reason about one "logical"
server, while in reality many "physical" servers may exist.

>
>
> As Sander notes below, such HA clustering is running in DDS.  Based on his
> experience with this code, he wrote the High Availability portion of the
> requirements draft (Section 5.7).  So we can lean on him as to how it might
> be done ;-).
>
>
>

Indeed :-) We have deployed systems (in particular, an air-traffic control
management system) where we showed that (eventual) consistency can be
achieved in a partitioned system with high requirements on availability
(AP).

It should be noted that the complexity involved in achieving high
availability was abstracted from the application code by the (DDS)
infrastructure. Configuration of the system was also relatively
straightforward since most of the system could be auto-discovered.

>  Eric
>
>
>
> *From:* Thomas D. Nadeau, October 31, 2014 10:03 AM
>
>             That is part of why I am asking if it makes sense to separate
> things. In the first case, the read-only method does fit in the current
> architecture and might be easier to progress at the moment. The other part
> might need to be in “Yang 2.0”.
>
>
>
>           —Tom
>
>
>
>
>
> Please note that it is at the very least not technically unfeasible to
> have both read-only and read-write behavior in the proposed architecture.
> As an example, any implementation of OMG-DDS allows for this behavior.
>
>
>