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

From: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Sat, 1 Nov 2014 15:36:59 +0000

Hi Andy,

To NOTE here, mount technology is not a replication engine to replicate complete data store on a controller. It is a selective subtree replication engine based on mount definition received from mount clients. Why any application will mount complete data store? I don’t see any requirement to replicate the data store of a device to a controller. 

To understand why we need mount, the complete problem domain addressed in the requirement draft. http://tools.ietf.org/html/draft-voit-netmod-peer-mount-requirements-01 and mount extension draft http://tools.ietf.org/html/draft-clemm-netmod-mount-02. 

There is no hard rule that device SHOULD mount data from controllers. Based on application requirement selective object mount is a better way. 

If devices mounting (mount client) to a subtree from remote device/controller (mount server), then the data replication will be triggered by the mount server to all mount clients based on mount policies. It bring application simplicity by decoupling the application logic from data fetch infra.

If there is a requirement of pushing data to 10 devices and there are 1000 devices present in the network, then those 10 devices should mount for the data.

About the scale requirement of handing 1000s of devices for a mount point, (I think can be a scenario with controller), and one controller is not capable of handing it, then multi player architecture can be placed to handle it.  

Br,
Ambika

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

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

On Fri, Oct 31, 2014 at 5:09 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 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
>
> On Fri, Oct 31, 2014 at 10:33:48AM +0000, Ambika Prasad Tripathy (ambtripa) wrote:
>> 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
>>
>> On Fri, Oct 31, 2014 at 09:53:50AM +0000, Ambika Prasad Tripathy (ambtripa) wrote:
>> > 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.
>> >
>>
>> Well, there are also existing interfaces to read config and state 
>> data. ;-)
>>
>> > 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.
>> >
>>
>> 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/>
>
> --
> 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/>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Sat, 1 Nov 2014 15:46:12 +0000

Hi,

Please take a look on below drafts for the relation between mount client and mount server with datastores.

1.	http://tools.ietf.org/html/draft-clemm-netmod-mount-02
2.	http://tools.ietf.org/html/draft-voit-netmod-peer-mount-requirements-01

The current NetConf / RestConf is not suitable to use as a transport between mount client and mount server. To use NC/RC as a transport, a new draft describes the capability requirements for NC.

3.	http://tools.ietf.org/html/draft-netmod-clemm-datastore-push-00

Br,
Ambika

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, October 31, 2014 8:36 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,

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

On Fri, Oct 31, 2014 at 12:50:50PM +0000, Ambika Prasad Tripathy (ambtripa) wrote:
> Hi,
> 
> To clear you first NetConf server is not a mount client. Mount client has the capability to mount to a Mount Server. 
> 
> <js>
> a) a controller mounting read-only data from a set of NC servers </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
> 
> Sent: Friday, October 31, 2014 5:40 PM
> 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: Andy Bierman <[email-masked]>
Date: Sat, 1 Nov 2014 09:16:52 -0700

> To NOTE here, mount technology is not a replication engine to replicate complete data store on a controller. It is a selective subtree replication engine based on mount definition received from mou…

I understand it is for replicating subtrees from a datastore, and it
is up to the
config whether that is all subtrees or not. Replicating operational data is
quite expensive.  I noticed the Cloud SLA draft seems to replicate
interface counters from the devices.  I suppose large routers have the
horsepower
to pump out their IF stats constantly, but why not just use IPFIX for that?

Why bother with all this extra "mount" semantics?  How are the devices supposed
to know which controllers are present and exactly what data they are
supposed to push to each controller?  Why not just configure each controller?

> To understand why we need mount, the complete problem domain addressed in the requirement draft. http://tools.ietf.org/html/draft-voit-netmod-peer-mount-requirements-01 and mount extension draft ht…

I will try to find out there why the devices are configuring the
applications instead
of the normal mode.

> There is no hard rule that device SHOULD mount data from controllers. Based on application requirement selective object mount is a better way.

So the devices implement lots of ways to do the same thing?
IMO the servers should be as simple as possible to keep costs down.
Flexibility in the controller means extra complexity in the devices.

> About the scale requirement of handing 1000s of devices for a mount point, (I think can be a scenario with controller), and one controller is not capable of handing it, then multi player architectu…

So the new protocol that devices would implement to push
their operational data would not have congestion control?
That's required by the IETF.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Sat, 1 Nov 2014 19:56:16 +0000

> From: Andy Bierman, November 01, 2014 12:17 PM
> 
> > To NOTE here, mount technology is not a replication engine to replicate
> complete data store on a controller. It is a selective subtree replication engine
> based on mount definition received from mount clients. Why any application will
> mount complete data store? I don’t see any requirement to replicate the data
> store of a device to a controller.
> >
> 
> 
> I understand it is for replicating subtrees from a datastore, and it is up to the
> config whether that is all subtrees or not. Replicating operational data is quite
> expensive.  I noticed the Cloud SLA draft seems to replicate interface counters
> from the devices.  I suppose large routers have the horsepower to pump out
> their IF stats constantly, but why not just use IPFIX for that?
> 
> Why bother with all this extra "mount" semantics?

Application simplicity.  

>  How are the devices supposed to know which controllers are present  and 
> exactly what data they are supposed to push to each controller?  

Peer Mount is a peer-to-peer technology.   This is not just about controllers.   There are many mechanisms which allow peers find out about each other.

> Why not just configure each controller?

Many reasons.  Two include:

(1) Misconfiguration is the biggest source of outages.  Peer Mount explicitly identifies an authoritative source.  This eliminates a large class of errors and enables automatic convergence when things get out of synch.

(2) YANG Pub/Sub is missing.   

> > To understand why we need mount, the complete problem domain addressed
> in the requirement draft. http://tools.ietf.org/html/draft-voit-netmod-peer-
> mount-requirements-01 and mount extension draft
> http://tools.ietf.org/html/draft-clemm-netmod-mount-02.
> >
> 
> I will try to find out there why the devices are configuring the applications
> instead of the normal mode.
> 
> > There is no hard rule that device SHOULD mount data from controllers. Based
> on application requirement selective object mount is a better way.
> >
> 

Network Elements already interface with multiple controllers.  SDN just adds more.  These controllers will sometimes provide conflicting guidance.

For example, what happens if a security controller says "deny", and then an orchestration controller says "allow"?   Today the security controller would not know that a hole has been opened up.   However if the security controller has mounted the Network Element's config, it would see the change immediately and be able to react.
 
> > If devices mounting (mount client) to a subtree from remote device/controller
> (mount server), then the data replication will be triggered by the mount server to
> all mount clients based on mount policies. It bring application simplicity by
> decoupling the application logic from data fetch infra.
> >
> > If there is a requirement of pushing data to 10 devices and there are 1000
> devices present in the network, then those 10 devices should mount for the
> data.
> >
> > About the scale requirement of handing 1000s of devices for a mount point, (I
> think can be a scenario with controller), and one controller is not capable of
> handing it, then multi player architecture can be placed to handle it.
> 
> So the new protocol that devices would implement to push their operational
> data would not have congestion control?

Congestion control is orthogonal to Ambika's point.

Think of it this way:   An application wants to set blackhole traffic to a specific IP address across the whole network.  (Perhaps this is a destination server for a hacker's BotNet info.)  Either the application can set and *attempt* to maintain accurate drop ACL on thousands  of devices.  Or each device can subscribe to a single place where the application places the info.  

The second way is less error prone.  The second way enables multiple controllers to make assertions overlapping sets of devices.  Each device then has the option to assess if it is in the middle of inconsistency/conflict.

Eric

> > To: Juergen Schoenwaelder; Ambika Prasad Tripathy (ambtripa); Qin Wu;
> > Martin Bjorklund; Eric Voit (evoit); [email-masked]
> > 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
> >
> > On Fri, Oct 31, 2014 at 5:09 AM, Juergen Schoenwaelder
> <[email-masked]> wrote:
> >> 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
> >>>
> >>> > 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.
> >>> >
> >>>
> >>> 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: Qin Wu <[email-masked]>
Date: Mon, 3 Nov 2014 03:24:35 +0000

-----邮件原件-----
发件人: Eric Voit (evoit) [mailto:[email-masked]] 
发送时间: 2014年11月2日 3:56
收件人: Andy Bierman; Ambika Prasad Tripathy (ambtripa)
抄送: Juergen Schoenwaelder; Qin Wu; Martin Bjorklund; [email-masked]
主题: RE: [netmod] YANG model containing both device and domain config

> complete data store on a controller. It is a selective subtree 
> replication engine based on mount definition received from mount 
> clients. Why any application will mount complete data store? I don’t 
> see any requirement to replicate the data store of a device to a controller.
> >
> 
> 
> is up to the config whether that is all subtrees or not. Replicating 
> operational data is quite expensive.  I noticed the Cloud SLA draft 
> seems to replicate interface counters from the devices.  I suppose 
> large routers have the horsepower to pump out their IF stats constantly, but why not just use IPFIX for that?
> 

Application simplicity.  

>  How are the devices supposed to know which controllers are present  
> and exactly what data they are supposed to push to each controller?

[Qin]: Eric, It looks you and Andy are talking about difference cases.
The case Andy is talking about is: The controller as mount client is mounting the data from a set of NC server.
The case you are talking about is a NC server/device is mounting data from the controller or you are probably talking about both case,
But it is very confusing to mix two cases together.

I think when the NC server is mounting data from the controller, it might be easy to discover the controller or know which data node in the remote datastore to fetch by using sub/pub you guys proposed.
But when the controller is mounting data from a set of NC servers, what discovery mechanism are you using? why not use the existing interface and existing mechanism? Why not grab the whole data in all device managed by the controller? It seems complicate to rely on manual configuration or pub/sub mechanism to search a subset of interested data nodes in the remote datastore of all the NC servers? 

If you are proposing incremental update, why not ask application subscriber to each NC server/device directly? Why complicate controller to cache updated data retrieved from each remote datastore in all the NC severs?

---

From: Qin Wu <[email-masked]>
Date: Mon, 3 Nov 2014 03:35:43 +0000

It looks both mount policy and subscription policy are maintained by the mount client.
How mount policy is related to subscription policy? When mount policy is provided?

Regards!
-Qin
-----邮件原件-----
发件人: Ambika Prasad Tripathy (ambtripa) [mailto:[email-masked]] 
发送时间: 2014年11月1日 23:37
收件人: Andy Bierman; Juergen Schoenwaelder; Qin Wu; Martin Bjorklund; Eric Voit (evoit); [email-masked]
主题: RE: [netmod] YANG model containing both device and domain config

Hi Andy,

Br,
Ambika

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

Hi,

Andy

---

From: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Mon, 3 Nov 2014 06:59:33 +0000

Hi,

Mount policy = subscription policy. 

User can configure mount policy for one mount point or globally for all mount points to mount client. 

Br,
Ambika

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: Monday, November 03, 2014 9:06 AM
To: Ambika Prasad Tripathy (ambtripa); Andy Bierman; Juergen Schoenwaelder; Martin Bjorklund; Eric Voit (evoit); [email-masked]
Subject: RE: [netmod] YANG model containing both device and domain config

Regards!
-Qin
-----邮件原件-----
发件人: Ambika Prasad Tripathy (ambtripa) [mailto:[email-masked]]
发送时间: 2014年11月1日 23:37
收件人: Andy Bierman; Juergen Schoenwaelder; Qin Wu; Martin Bjorklund; Eric Voit (evoit); [email-masked]
主题: RE: [netmod] YANG model containing both device and domain config

Hi Andy,

Br,
Ambika

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

Hi,

Andy

---

From: "Prabhakara Yellai (pyellai)" <[email-masked]>
Date: Mon, 3 Nov 2014 08:31:00 +0000

Hi Andy,
> I suppose large routers have the horsepower to pump out their IF stats constantly, but why not just use IPFIX for that?

Netflow Stats, which IPFIX is for, are one part, though probably considerable part, of the operational data that the NEs produce. Peer-Mount is generic covering any operational data and not just netflow stats. Moreover, Peer-Mount helps devices synchronize the operational data collection for push which is required for domain level view of data like in the Domain Policer application.

> How are the devices supposed to know which controllers are present and exactly what data they are supposed to push to each controller?  Why not just configure each controller?

Devices don't need to know the controllers for pushing operational data. It is the controller that discovers the device and mounts one or more subtrees/paths for getting the operational data. Controllers are supposed to have a mechanism to discover the network inventory anyway. 

Prabhakara

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Saturday, November 01, 2014 9:47 PM
To: Ambika Prasad Tripathy (ambtripa)
Cc: [email-masked]
Subject: Re: [netmod] YANG model containing both device and domain config

> To NOTE here, mount technology is not a replication engine to replicate complete data store on a controller. It is a selective subtree replication engine based on mount definition received from mou…

I understand it is for replicating subtrees from a datastore, and it is up to the config whether that is all subtrees or not. Replicating operational data is quite expensive.  I noticed the Cloud SLA draft seems to replicate interface counters from the devices.  I suppose large routers have the horsepower to pump out their IF stats constantly, but why not just use IPFIX for that?

Why bother with all this extra "mount" semantics?  How are the devices supposed to know which controllers are present and exactly what data they are supposed to push to each controller?  Why not just configure each controller?

> To understand why we need mount, the complete problem domain addressed in the requirement draft. http://tools.ietf.org/html/draft-voit-netmod-peer-mount-requirements-01 and mount extension draft ht…

I will try to find out there why the devices are configuring the applications instead of the normal mode.

> About the scale requirement of handing 1000s of devices for a mount point, (I think can be a scenario with controller), and one controller is not capable of handing it, then multi player architectu…

So the new protocol that devices would implement to push their operational data would not have congestion control?
That's required by the IETF.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 3 Nov 2014 16:37:14 +0000

> From: Qin Wu, November 02, 2014 10:25 PM
> 发件人: Eric Voit,> 发送时间: 2014年11月2日 3:56
> Peer Mount is a peer-to-peer technology.   This is not just about controllers.
> There are many mechanisms which allow peers find out about each other.
> 
> The case you are talking about is a NC server/device is mounting data from the
> controller or you are probably talking about both case

Both

> But it is very confusing to mix two cases together.

From an NMS designer's point of view, I understand the confusion.  But from a Routing protocol designers point of view, bi-directional is a given.  Beyond that, many routing protocols speed convergence by having authoritative nodes source an intersecting mesh of multipoint announcements.  Minimizing convergence time is at the heart of IP networking's global success.

With SDN, IP networks will need to converge when policies asserted to different abstractions located upon different devices intersect.  Supporting this is a core objective of Peer Mount.
 
> I think when the NC server is mounting data from the controller, it might be easy
> to discover the controller or know which data node in the remote datastore to
> fetch by using sub/pub you guys proposed.
> But when the controller is mounting data from a set of NC servers, what
> discovery mechanism are you using? why not use the existing interface and
> existing mechanism?

I totally agree on this reuse. There is plenty of work in OpenDaylight and the IETF aimed at topology and device discovery.  (This must be zero touch.)  Once the object exists in your datastore, you will likely know the device type and supported capabilities.  And with this you will know which YANG objects it exposes.

>  Why not grab the whole data in all device managed by the
> controller? 

This is not viable for some types of quickly changing data.  This is why routing protocols are peer-to-peer and not centrally managed.

> It seems complicate to rely on manual configuration or pub/sub
> mechanism to search a subset of interested data nodes in the remote datastore
> of all the NC servers?

I agree this cannot be manual.   The pub/sub itself will be driven automatically.  This is a core capability of OpenDaylight which Network Elements can also leverage in certain cases.
 
> If you are proposing incremental update, why not ask application subscriber to
> each NC server/device directly? Why complicate controller to cache updated
> data retrieved from each remote datastore in all the NC severs?

Performance time for some applications demands local caching.  In addition, 1:N and even two tiered distribution of Peer Mount updates will reduce scaling requirements for the Authoritative data source.

Eric

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 3 Nov 2014 20:48:16 +0000

Just one more comment re: "why not just use IPFIX": 

It is certainly a possible option to use IPFIX export to export data in bulk.  The transport and protocol should be separable from the data representation for that pupose.  However, even if you use IPFIX, you still need to bring the data into the YANG context, manage the subscriptions, specify the policy for pushing, etc.  These things are addressed in the proposal.  

--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Prabhakara Yellai (pyellai)
Sent: Monday, November 03, 2014 12:31 AM
To: Andy Bierman; Ambika Prasad Tripathy (ambtripa)
Cc: [email-masked]
Subject: Re: [netmod] YANG model containing both device and domain config

Hi Andy,

Prabhakara

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Saturday, November 01, 2014 9:47 PM
To: Ambika Prasad Tripathy (ambtripa)
Cc: [email-masked]
Subject: Re: [netmod] YANG model containing both device and domain config

Andy

---

From: Qin Wu <[email-masked]>
Date: Wed, 5 Nov 2014 08:25:19 +0000

> mechanism to search a subset of interested data nodes in the remote 
> datastore of all the NC servers?

[Qin]: I am a little bit concerned about the pub/sub being driven automatically. It seems you imply NC server's subscriptions to remote object updates in the controller can further
trigger this controller to subscribe to the remote object updates in all the NC servers? How does this controller know which NC server has subtrees or data nodes the controller is interested before sub/push?
Or you assume the controller poll for all the NC servers for discovery?

> If you are proposing incremental update, why not ask application 
> subscriber to each NC server/device directly? Why complicate 
> controller to cache updated data retrieved from each remote datastore in all the NC severs?

[Qin]: Again, I have concern about two tiered distribution of Peer Mount, how does the NC server knows which controller can provide its interested data before subscription? How does the controller knows Which NC server can provide its interested data before subscription. Blind subscription seems time wasting or not efficient.

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 6 Nov 2014 13:56:09 +0000

> From: Qin Wu, November 05, 2014 3:25 AM
> 
> I agree this cannot be manual.   The pub/sub itself will be driven automatically.
> This is a core capability of OpenDaylight which Network Elements can also
> leverage in certain cases.
> 
> [Qin]: I am a little bit concerned about the pub/sub being driven automatically. It
> seems you imply NC server's subscriptions to remote object updates in the
> controller can further trigger this controller to subscribe to the remote object
> updates in all the NC servers? How does this controller know which NC server
> has subtrees or data nodes the controller is interested before sub/push?

OpenDaylight has over 100 YANG models 
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Model_Reference  
only a small subset of these are RFCs or IETF drafts.  Topology and Inventory models are included in this expanding set.

Controllers must constantly monitor the network via a large set of protocols attached to these models to have a meaningful view of current network state.   Auto-discovery of everything is essential for any controller to operate affordably.  This is independent of any Pub/Sub.

As the controller's topology and inventory get auto-populated, Applications may use this information to glean what type targeted subscriptions are viable.  As you suggest, indiscriminant subscriptions are unaffordable.
 
> Performance time for some applications demands local caching.  In addition, 1:N
> and even two tiered distribution of Peer Mount updates will reduce scaling
> requirements for the Authoritative data source.
> 
> [Qin]: Again, I have concern about two tiered distribution of Peer Mount, how
> does the NC server knows which controller can provide its interested data
> before subscription? How does the controller knows Which NC server can
> provide its interested data before subscription. Blind subscription seems time
> wasting or not efficient.

Agree that blind subscriptions are totally unaffordable.  OpenDaylight has not instituted many controls yet that stop applications from making dumb design choices.

As for two tiered distribution, this is implemented by many vendors -- although often it is often hidden under the covers.  For example, distributed line cards will often be secondary recipients of config information passed to a large router.  Another good example is DNS which has a multi-tier implementation to enable high scalability.

I don't need multi-tier for the applications I am building.  But I don't want to preclude this option for those who might find it useful.

Eric

---

From: Sander Mertens <[email-masked]>
Date: Fri, 21 Nov 2014 15:16:15 -0500

Eric let me know that some concerns were voiced around whether the peer
mount architecture would or would not be scalable.

Peer mount could be an excellent front end for a highly distributed,
eventually consistent object store, such as the one that we are selling.
Many customers <http://www.prismtech.com/about-us/our-clients> in different
industries <http://www.prismtech.com/vortex/industry-solutions> have
trusted their business critical processes with us.

We support systems that scale anywhere between a handful and millions of
devices (on commodity hardware) while realizing high throughput (100K - 1M
messages/sec) and latencies as low as 40 microseconds on a LAN.

I just published this presentation that outlines a number of common
pitfalls we have encountered with customers that are trying to scale up
their system, and how we address them:

http://www.slideshare.net/SanderMertens1/5-reasons-why-you-will-fail-to-scale-your-io-t-system
<http://www.slideshare.net/SanderMertens1/5-reasons-why-you-will-fail-to-scale-your-io-t-system>

On 6 November 2014 08:56, Eric Voit (evoit) <[email-masked]> wrote:

> only a small subset of these are RFCs or IETF drafts.  Topology and
> Inventory models are included in this expanding set.
>
> Controllers must constantly monitor the network via a large set of
> protocols attached to these models to have a meaningful view of current
> network state.   Auto-discovery of everything is essential for any
> controller to operate affordably.  This is independent of any Pub/Sub.
>
> As the controller's topology and inventory get auto-populated,
> Applications may use this information to glean what type targeted
> subscriptions are viable.  As you suggest, indiscriminant subscriptions are
> unaffordable.
>
> > > controller to cache updated data retrieved from each remote datastore
> in all
> > the NC severs?
> >
> Agree that blind subscriptions are totally unaffordable.  OpenDaylight has
> not instituted many controls yet that stop applications from making dumb
> design choices.
>
> As for two tiered distribution, this is implemented by many vendors --
> although often it is often hidden under the covers.  For example,
> distributed line cards will often be secondary recipients of config
> information passed to a large router.  Another good example is DNS which
> has a multi-tier implementation to enable high scalability.
>
> I don't need multi-tier for the applications I am building.  But I don't
> want to preclude this option for those who might find it useful.
>
> Eric
>
> > Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 21 Nov 2014 23:12:08 +0000

Thanks Sander.  Beyond PrismTech, there are multiple other commercial and open source implementations of DDS that support distributed object synchronization and eventual consistency.  To see more, go to:
http://portals.omg.org/dds/category/web-links/vendors
and click to find details for each of the various companies.

Hopefully this existence proof satisfies the two WG questions of:

·        are there use cases for a ‘Peer Mount’ type technology

·        can implementations scale

Eric

From: Sander Mertens, November 21, 2014 3:16 PM

Eric let me know that some concerns were voiced around whether the peer mount architecture would or would not be scalable.

Peer mount could be an excellent front end for a highly distributed, eventually consistent object store, such as the one that we are selling. Many customers<http://www.prismtech.com/about-us/our-clients> in different industries<http://www.prismtech.com/vortex/industry-solutions> have trusted their business critical processes with us.

We support systems that scale anywhere between a handful and millions of devices (on commodity hardware) while realizing high throughput (100K - 1M messages/sec) and latencies as low as 40 microseconds on a LAN.

I just published this presentation that outlines a number of common pitfalls we have encountered with customers that are trying to scale up their system, and how we address them:

http://www.slideshare.net/SanderMertens1/5-reasons-why-you-will-fail-to-scale-your-io-t-system <http://www.slideshare.net/SanderMertens1/5-reasons-why-you-will-fail-to-scale-your-io-t-system>

Eric

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