Subject: Re: [netmod] New revision of YANG mount draft

From: Kent Watsen <[email-masked]>
Date: Wed, 8 Oct 2014 22:08:21 +0000

Per my action from today's virtual meeting regarding this draft, my fundamental question regards the importance of IETF standardizing this model.

Please understand that I'm fully aware of and familiar with OpenDaylight's implementation of this draft.   I think that the desire for an application/controller to stay in sync with device's via pub/sub with async notification is important.   Of course, RFC6470's netconf-config-change event provides this, albeit it's not threshold or interval based as your draft says should be possible.

But this draft isn't the YANG module that a "mount server" would advertise; this draft presents the YANG module a "mount client" would advertise.  I'm not sure what the interoperability issue is that necessitates standardizing this.

Lastly, after importance of problem, I wonder about the effectiveness of the solution.   I  while I can go along with applications/controllers "mounting" subtrees internally, I don't perceive a general desire or need to present said mounts or even mount/unmount RPCs via a northbound interface, as doing so just means the application/controller is a pass-thru to a higher-level system and not doing anything meaningful itself.

Thanks,
Kent

From: "Alexander Clemm (alex)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 7, 2014 at 2:51 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] New revision of YANG mount draft

Hi,

we just wanted to let you know that we have just posted a new revision of draft-clemm-netmod-mount:
http://datatracker.ietf.org/doc/draft-clemm-netmod-mount/
This document updates an earlier revision that we had posted about a year ago.  It also addresses
requirements and use cases in http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/

Here is the abstract:

This document introduces capabilities that allow YANG datastores to
   reference and incorporate information from remote datastores.  This
   is accomplished by extending YANG with the ability to define mount
   points that act as references to data nodes in remote datastores, and
   by providing the necessary means to manage and administer those mount
   points.  This facilitates the development of applications that need
   to access data that transcends individual network devices while
   improving network-wide object consistency.

   This document also lays the groundwork for optional extensions to
   support subscriptions to remote object updates and transparent
   caching of objects.  These options will speed application performance
   without sacrificing data consistency.

Kind regards
--- Alex

---

From: Andy Bierman <[email-masked]>
Date: Wed, 8 Oct 2014 15:25:59 -0700

On Wed, Oct 8, 2014 at 3:08 PM, Kent Watsen <[email-masked]> wrote:

>
>  Per my action from today's virtual meeting regarding this draft, my
> fundamental question regards the importance of IETF standardizing this
> model.
>
>  Please understand that I'm fully aware of and familiar with
> OpenDaylight's implementation of this draft.   I think that the desire for
> an application/controller to stay in sync with device's via pub/sub with
> async notification is important.   Of course, RFC6470's
> netconf-config-change event provides this, albeit it's not threshold or
> interval based as your draft says should be possible.
>
>  But this draft isn't the YANG module that a "mount server" would
> advertise; this draft presents the YANG module a "mount client" would
> advertise.  I'm not sure what the interoperability issue is that
> necessitates standardizing this.
>
>  Lastly, after importance of problem, I wonder about the effectiveness of
> the solution.   I  while I can go along with applications/controllers
> "mounting" subtrees internally, I don't perceive a general desire or need
> to present said mounts or even mount/unmount RPCs via a northbound
> interface, as doing so just means the application/controller is a pass-thru
> to a higher-level system and not doing anything meaningful itself.
>
>
+1

This seems like a generic master-agent/sub-agent control module, but there
is no protocol
specified to setup the system and keep it in synch.

IMO network data models should just be YANG modules that describe
multi-device behavior.
The controller can use whatever southbound protocols it needs to implement
the network
model on devices.  Simply gathering remote device subtrees into a common
container does not
seem very useful.

> Kent
Andy

>
>   From: "Alexander Clemm (alex)" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> requirements and use cases in
> http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/
>
>
>
> Here is the abstract:
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 8 Oct 2014 22:27:40 +0000

Hi Kent,

yes, this is fundamentally about the mount client.  However, the "mount client" itself is part of a server to other clients.  This is why it has a datastore, which it presents to its clients.  "Client" is merely a role; it is not the top of the "food chain", you may have cascading relationships between systems where a system is client to one system and server to another.  For these reasons, this is not merely a matter of how you build an application and about "consuming" data from remote system, but about at the same time making it accessible to other systems.  This is why we believe it matters and affects interoperability, hence is relevant for standardization.

Mountpoint management is generally not intended for clients of the datastore which includes the remote information.  It is intended for purposes of system management and administration.  In general, the mount structures will be automatically populated and bootstrapped as part of mountpoint implementation and the underlying implementation infrastructure.  They are not of concern for general applications.  However, for a complete system, it is important that these aspects are addressed, which is why they are included in the specification.

Regarding config change events, I agree those are important and can address some cases (basically when only config data is involved), but somewhat limited if we want also address operational data represented in YANG datastores.  Changes/updates to such data are not subjected to configuration change events.  To synchronize and receive updates, applications today would need to retrieve this information on demand and, for many applications, resort to polling.  There are many issues with polling known from SNMP, including lack of efficiency, lack of robustness, difficulty to synchronize polling intervals, etc.  This is why we believe that the ability to support subscriptions to data updates are important - not just for more efficient implementations of mount caching, but also beyond that once YANG-defined data is to be used for assurance and not just fulfillment-related applications.

Thanks
--- Alex

From: Kent Watsen [mailto:[email-masked]]
Sent: Wednesday, October 08, 2014 3:08 PM
To: Alexander Clemm (alex); [email-masked]
Subject: Re: [netmod] New revision of YANG mount draft

Thanks,
Kent

Hi,

Here is the abstract:

Kind regards
--- Alex

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 9 Oct 2014 18:31:17 +0000

Hi Kent,

To your thoughts on "general desire or need to present said mounts":

(1) There are successful generalized distributed datastores
The Object Management Group<http://omg.org/> has been standardizing<http://www.omg.org/spec/DDS/1.2/> a Data Distribution Service (DDS)<http://portals.omg.org/dds/>.  Products in this space have a ~$100M current (and growing) market.  A DDS vendor is considering contributing to the IETF peer mount requirements draft.   They want to add YANG support to their existing DDS products for support multi-device abstractions.  (Look for them to chime in on the Netmod list after their management gives a 'go-ahead'.)

(2) Some in Academia suggesting we overload IGP to achieve distributed policy/config convergence
A white paper which showing applications brutalizing ISIS/OSPF to achieve a specific policy goal is here<http://www.cs.princeton.edu/~jrex/papers/fibbing14.pdf>.   The paper proposes injecting fake configuration info into existing Network Elements  *in one place*.  Network consistency is achieved automatically via IGP convergence.  IMHO,  we should not be overloading routing protocols to accomplish configuration convergence for new applications.  Instead with Mount objects and intents could be explicitly coordinated.

More in line with your thoughts...

From: netmod, October 08, 2014 6:28 PM

Hi Kent,

Thanks
--- Alex

From: Kent Watsen [mailto:[email-masked]]
Sent: Wednesday, October 08, 2014 3:08 PM
To: Alexander Clemm (alex); [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] New revision of YANG mount draft

<Eric> RFC 6470 also doesn't support Pub/Sub, pre-dates YANG, and is tied to transport.  See first backup slide of deck from yesterday<http://www.voit.org/Peer-Mount-Netconf-WG-Oct2014.pdf>.

<Eric> Adding to what Alex says above...   Some aspects can be delivered with just a "mount client".  And these alone are valuable.   For "periodic" and "on-change" binding types, enhancements for the "mount server" are valid.   Looking again to DDS, proof points on what functions will be interesting can be gleaned from the "Data-Centric Publish-Subscribe "writer" as described in Section 7<http://www.omg.org/spec/DDS/1.2/PDF/> of the OMG standard.

<Eric> Beyond the industry points above, there is one other item.  If an device has access to an object, it might create a new object or validate with another (more abstracted?) one.  Anything else could then use this new info.   Therefore please don't consider Peer Mount just pass-through, but instead as a platform for local application can build their value-add.

Thanks,
Eric

Thanks,
Kent

Hi,

Here is the abstract:

Kind regards
--- Alex

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Thu, 9 Oct 2014 18:40:46 +0000

Hi Kent,

From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 8, 2014 at 3:08 PM
To: "Alexander Clemm (alex)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] New revision of YANG mount draft

The client-to-server (i.e when a controller mounts a remote netconf device), at the very minimum,  allows the controller to provide a multiplexing and virtualization function for applications that wish to talk to modeled network elements, while allowing the application to work directly with device models. An app only needs to connect to a single controller as opposed to many network elements. Moreover, an operator can define policies in the controller that allow different access for different application to different portions of a network element functionality. In effect,  the controller becomes a policy enforcement point.

Today, Yang does not allow a controller application to work directly with device yang models. A controller has to re-define device models into controller-specific models inside the controller and present the redefined models to applications. We feel that controller implementations should stay a transparent and model-independent plumbing between apps and network devices (apps that wish to talk to network devices, that is; I think we all agree that there is such a class of apps, in addition to apps that wish to access controller services only).

Thanks,
Kent

Thanks,
Jan

Hi,

Here is the abstract:

Kind regards
--- Alex

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Thu, 9 Oct 2014 21:59:31 +0000

Responding once again, hopefully with better formatted text.

From:  Kent Watsen <[email-masked]>
Date:  Wednesday, October 8, 2014 at 3:08 PM
To:  "Alexander Clemm (alex)" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [netmod] New revision of YANG mount draft

>OpenDaylight's implementation of this draft.   I think that the desire
>for an application/controller to stay in sync with device's via pub/sub
>with async notification is important.   Of course, RFC6470's
>interface, as doing so just means the application/controller is a
>pass-thru to a higher-level system and not doing anything meaningful
>itself.

The client-to-server mount (i.e when a controller mounts a remote netconf
device), at the very minimum,  allows the controller to provide a
multiplexing / virtualization function for applications that wish to talk
to modeled network elements, while allowing the applications to work
directly with device models. An app only needs to connect to a single
controller as opposed to many network elements. Moreover, an operator can
define policies in the controller that allow different access for
different applications to different portions of a network element's
functionality. In effect,  the controller becomes a policy enforcement
point.

Today, Yang does not allow a controller application to work directly with
device yang models. A controller has to re-define device models into
controller-specific models inside the controller and present the redefined
models to applications. We feel that controller implementations should
provide a transparent and model-independent plumbing between apps and
network devices (apps that wish to talk to network devices, that is; I
think we all agree that there is such a class of apps, in addition to apps
that wish to access controller services only).

Thanks,
Jan

><http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements
>/>
> 
>Here is the abstract:
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 10 Oct 2014 13:17:33 +0000

From: Andy Bierman, October 08, 2014 6:26 PM

On Wed, Oct 8, 2014 at 3:08 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

+1

This seems like a generic master-agent/sub-agent control module, but there is no protocol
specified to setup the system and keep it in synch.

<Eric>  A good mental model for the intent of what Mount is trying to accomplish is in the picture below:
If your email doesn't render the picture, see slide 7 of:
http://www.slideshare.net/SanderMertens1/vortex-introduction-public
(Note: This is not my slide, but one from Prismtech which addresses how DDS is relevant to IoT. )

Without models that span devices, YANG is applicable for the "local state" view on the left.  With models that span devices, YANG can facilitate the view on the right.   Getting to a Data-centric global dataspace requires:

*        Logic which identifies which objects are authoritative in a multi-device system

*        Logic which can assemble multi-device abstractions

*        Flexibility to support ACID and BASE convergence

No single protocol will fulfill all of those functions.  That is why the OMG standards body has defined the DDS specification<http://www.omg.org/spec/DDS/1.2/> to support the needed behavior.

IMO network data models should just be YANG modules that describe multi-device behavior.

<Eric> Yes, exactly.   The hard part is ensuring consistency of the multi-device abstraction.

The controller can use whatever southbound protocols it needs to implement the network
model on devices.  Simply gathering remote device subtrees into a common container does not
seem very useful.

<Eric> As shown on slide 5<http://www.voit.org/Peer-Mount-Netconf-WG-Oct2014.pdf>, there are network elements already managing multi-device abstractions.  With OPNFV<http://www.opnfv.org/>, distributed analytics<http://dna-wsl.cs.columbia.edu/>, and container based logic, there will be more such abstractions.  Peer Mount is a useful tool which is already shown value and being used in traditional SDN controllers.  The IETF defining a generic technology which also can be used between network elements would be very valuable.

Thanks,
Eric

Thanks,
Kent

Andy

Hi,

Here is the abstract:

Kind regards
--- Alex

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Oct 2014 23:09:34 +0200

On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote:
> models to applications. 

How is this falling out of RFC 6020?

/js

-- 
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: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 10 Oct 2014 21:21:29 +0000

What this refers to is the case of a hierarchy, where a system in a client role accesseses another system in a server role (e.g. a controller) which itself is a client to another server (e.g. a network device).  One (straightforward) approach is to ignore the fact that the server (e.g. the controller) can be a client, and simply have it incorporate its own set of YANG models to represent the other devices below it.  The downside is that this requires the controller to redefine and implement those models - they cannot be simply reused as e.g. the "scope" is different, and the server has to have a semantic "understanding" of everything in the devices underneath it. This brings about the same situation that NMS has had for decades, that integrating new devices into an operational environment is held hostage by the NMS, which first needs to support (and require corresponding development support for) all those new parameters.  In our case, we want to have the option to simply incorporate "subtrees" from the device and make them accessible to other applications by mounting them, without requiring further development (or requiring systems to "go around" the controller, which complicates development of those other system and/or introduces other issues such as synchronization).  
--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, October 10, 2014 2:10 PM
To: Jan Medved (jmedved)
Cc: Kent Watsen; Alexander Clemm (alex); [email-masked]
Subject: Re: [netmod] New revision of YANG mount draft

On Thu, Oct 09, 2014 at 09:59:31PM +0000, Jan Medved (jmedved) wrote:
> 
> Today, Yang does not allow a controller application to work directly 
> with device yang models. A controller has to re-define device models 
> into controller-specific models inside the controller and present the 
> redefined models to applications.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Oct 2014 23:53:41 +0200

I still fail to see how all this falls out of RFC 6020.

I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is
needed for what you want to do and likely even incomplete) but then
the NETMOD WG is not about protocol work but about the data modeling
language YANG and data models. In fact, my reading of the I-D is that
you do not request to change anything in YANG at all - all you propose
is to define a few extensions and a data model.

Do you agree? Or where am I mis-understanding things?

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 10 Oct 2014 23:43:38 +0000

Hi Juergen, 

I am not sure with what you mean with "this falls out of RFC 6020"?  

To your statement: "In fact, my reading of the I-D is that you do not request to change anything in YANG at all - all you propose is to define a few extensions and a data model."  Yes, I agree; your understanding is correct.  The proposal we are making addresses the requirements within the existing framework.  

Regarding the "protocol portion", we are making the case that implementation of this will be facilitated by having a push and/or pub/sub model for data subtrees.  This does not necessarily require actual protocol work (although such work could be defined) but can be addressed again within the existing framework, using a subscription configuration model, notifications etc as outlined in the draft.  

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, October 10, 2014 2:54 PM
To: Alexander Clemm (alex)
Cc: Jan Medved (jmedved); Kent Watsen; [email-masked]
Subject: Re: [netmod] New revision of YANG mount draft

I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is needed for what you want to do and likely even incomplete) but then the NETMOD WG is not about protocol work but about the data modeling language YANG and data models. In fact, my reading of the I-D is that you do not request to change anything in YANG at all - all you propose is to define a few extensions and a data model.

/js

On Fri, Oct 10, 2014 at 09:21:29PM +0000, Alexander Clemm (alex) wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> > into controller-specific models inside the controller and present 
> > the redefined models to applications.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 11 Oct 2014 12:27:06 +0200

Alex,

we seem to talk past each other, I am not sure why. You wrote something

> > > the redefined models to applications.

So I am wondering what in RFC 6020 is leading to this statement. I did
not find anything so I need your help to understand this. I am also
getting confused when you say there is no protocol work needed, things
can be done within the existing framework, but then you say there is a
need for a push and/or pub/sub model for data subtrees (which is not
there today).

It helps me if you focus on clearly explaining what the technical
details are you think should be standardized for your use case. There
is lots of text why your use case is important but what I am looking
for is a concise and clear description of the details that you think
need to be standardized.

Note that we so far have a setup in the IETF where one WG does
protocol work and another takes care of the data modeling language and
some core data models. I try to understand which pieces of concrete
work you want to do so I can understand where things should be
discussed.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 11 Oct 2014 10:30:16 -0700

> work you want to do so I can understand where things should be

Perhaps we are disagreeing on the problem to solve, so we won't agree on the
specific solutions that need to be chartered and standardized either.

I do not agree with the premise that the network-level data models need to
be
the same as the device -level data models.  A collection of data from
several
devices is just passed through to the client of the controller. This does
not
seem like network-level management to me.

The controller can use NETCONF as its southbound protocol to the devices.
It should decide what data to collect and what northbound data models to
populate.
I don't see why the devices need to be configured for this purpose.

Andy

> > To your statement: "In fact, my reading of the I-D is that you do not
> request to change anything in YANG at all - all you propose is to define a
> few extensions and a data model."  Yes, I agree; your understanding is
> correct.  The proposal we are making addresses the requirements within the
> existing framework.
> >
> > Regarding the "protocol portion", we are making the case that
> implementation of this will be facilitated by having a push and/or pub/sub
> model for data subtrees.  This does not necessarily require actual protocol
> work (although such work could be defined) but can be addressed again
> within the existing framework, using a subscription configuration model,
> notifications etc as outlined in the draft.
> >
> > --- Alex
> >
> needed for what you want to do and likely even incomplete) but then the
> NETMOD WG is not about protocol work but about the data modeling language
> YANG and data models. In fact, my reading of the I-D is that you do not
> request to change anything in YANG at all - all you propose is to define a
> few extensions and a data model.
> >
> > > What this refers to is the case of a hierarchy, where a system in a
> client role accesseses another system in a server role (e.g. a controller)
> which itself is a client to another server (e.g. a network device).  One
> (straightforward) approach is to ignore the fact that the server (e.g. the
> controller) can be a client, and simply have it incorporate its own set of
> YANG models to represent the other devices below it.  The downside is that
> this requires the controller to redefine and implement those models - they
> cannot be simply reused as e.g. the "scope" is different, and the server
> has to have a semantic "understanding" of everything in the devices
> underneath it. This brings about the same situation that NMS has had for
> decades, that integrating new devices into an operational environment is
> held hostage by the NMS, which first needs to support (and require
> corresponding development support for) all those new parameters.  In our
> case, we want to have the option to simply incorpor
>  ate "subtrees" from the device and make them accessible to other
> applications by mounting them, without requiring further development (or
> requiring systems to "go around" the controller, which complicates
> development of those other system and/or introduces other issues such as
> synchronization).
> > > --- Alex
> > >

---

From: Qin Wu <[email-masked]>
Date: Sun, 12 Oct 2014 05:22:19 +0000

-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Alexander Clemm (alex)
发送时间: 2014年10月11日 5:21
收件人: Juergen Schoenwaelder; Jan Medved (jmedved)
抄送: [email-masked]
主题: Re: [netmod] New revision of YANG mount draft

What this refers to is the case of a hierarchy, where a system in a client role accesseses another system in a server role (e.g. a controller) which itself is a client to another server (e.g. a network device).  One (straightforward) approach is to ignore the fact that the server (e.g. the controller) can be a client, and simply have it incorporate its own set of YANG models to represent the other devices below it.  The downside is that this requires the controller to redefine and implement those models - they cannot be simply reused as e.g. the "scope" is different, and the server has to have a semantic "understanding" of everything in the devices underneath it. This brings about the same situation that NMS has had for decades, that integrating new devices into an operational environment is held hostage by the NMS, which first needs to support (and require corresponding development support for) all those new parameters.  In our case, we want to have the option to simply inc!
orporate
 "subtrees" from the device and make them accessible to other applications by mounting them, without requiring further development (or requiring systems to "go around" the controller, which complicates development of those other system and/or introduces other issues such as synchronization).  

[Qin] Interesting, Is this idea about datastore data synchronization in different levels. One subset of datastore data in lower level can be nested into a datastore in higher level and inserted as mounting point. Datastore data in lower level doesn't need to be unfolded or exposed to more higher level client that is on top of the controller. Mounting point provide a reference point in the remote datastore to retrieve the data. Network topo information gathering can be a good example for such data retrieving. But it is not clear to me how this can support multi-tenancy when different tenant has different view of network topo.
In addition, where to insert data from remote datastore in the local datastore is not very clear as well. 

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Friday, October 10, 2014 2:10 PM
To: Jan Medved (jmedved)
Cc: Kent Watsen; Alexander Clemm (alex); [email-masked]
Subject: Re: [netmod] New revision of YANG mount draft

/js

---

From: Qin Wu <[email-masked]>
Date: Sun, 12 Oct 2014 05:22:37 +0000

Hi,
I think Juergen asked a good question, I am wondering how this work is related to subtree filtering expression.
I thought it is quite related.

Regards!
-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Juergen Schoenwaelder
发送时间: 2014年10月11日 18:27
收件人: Alexander Clemm (alex)
抄送: [email-masked]
主题: Re: [netmod] New revision of YANG mount draft

Alex,

we seem to talk past each other, I am not sure why. You wrote something like this:

> > > Today, Yang does not allow a controller application to work 
> > > directly with device yang models. A controller has to re-define 
> > > device models the redefined models to applications.

So I am wondering what in RFC 6020 is leading to this statement. I did not find anything so I need your help to understand this. I am also getting confused when you say there is no protocol work needed, things can be done within the existing framework, but then you say there is a need for a push and/or pub/sub model for data subtrees (which is not there today).

It helps me if you focus on clearly explaining what the technical details are you think should be standardized for your use case. There is lots of text why your use case is important but what I am looking for is a concise and clear description of the details that you think need to be standardized.

Note that we so far have a setup in the IETF where one WG does protocol work and another takes care of the data modeling language and some core data models. I try to understand which pieces of concrete work you want to do so I can understand where things should be discussed.

/js

On Fri, Oct 10, 2014 at 11:43:38PM +0000, Alexander Clemm (alex) wrote:
> > What this refers to is the case of a hierarchy, where a system in a client role accesseses another system in a server role (e.g. a controller) which itself is a client to another server (e.g. a network device).  One (straightforward) approach is to ignore the fact that the server (e.g. the controller) can be a client, and simply have it incorporate its own set of YANG models to represent the other devices below it.  The downside is that this requires the controller to redefine and implement those models - they cannot be simply reused as e.g. the "scope" is different, and the server has to have a semantic "understanding" of everything in the devices underneath it. This brings about the same situation that NMS has had for decades, that integrating new devices into an operational environment is held hostage by the NMS, which first needs to support (and require corresponding development support for) all those new parameters.  In our case, we want to have the option to simply!
 incorpor
 ate "subtrees" from the device and make them accessible to other applications by mounting them, without requiring further development (or requiring systems to "go around" the controller, which complicates development of those other system and/or introduces other issues such as synchronization).  
> > > Today, Yang does not allow a controller application to work 
> > > directly with device yang models. A controller has to re-define 
> > > device models into controller-specific models inside the 
> > > controller and present the redefined models to applications.
> >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 13 Oct 2014 16:26:55 +0000

> From: Juergen Schoenwaelder, October 10, 2014 5:54 PM
> 

If by falling out you mean 'in conflict with', then I would agree that there are not backwards compatibility issues with RFC 6020 section 6 syntax.  This was by design.  

However I believe Alex' and Jan's concerns are with Section 5.1 of RFC 6020.   This section includes statements such as:  "For a module or submodule to reference definitions in an external module, the external module MUST be imported."

Bringing in targeted nodes and subtrees need not require visibility into the full submodule where the authoritative copy of the object might reside.

> I see protocol discussion in draft-clemm-netmod-mount-02.txt (which is needed
> for what you want to do and likely even incomplete) but then the NETMOD WG
> is not about protocol work but about the data modeling language YANG and
> data models. In fact, my reading of the I-D is that you do not request to change
> anything in YANG at all - all you propose is to define a few extensions and a data
> model.

The 'on-demand' Mount does not need any protocol work.  It is the easiest, and is looking to standardize needed several syntax extensions.  This type of Mount is what is implemented in OpenDaylight today.  

Not yet fully fleshed out in draft-clemm-netmod-mount are evolving capabilities such as 'periodic' and 'on-change' Mounts.  Beyond additional syntax extensions these will need mechanisms to allow Mount Server to pass changed objects to Mount Client subscribers.

RFC 5277 doesn't meet needs from several fronts.  Most relevant to this WG is that we want don't want any protocol work to be transport specific.

Eric
 
> > client role accesseses another system in a server role (e.g. a
> > controller) which itself is a client to another server (e.g. a network
> > device).  One (straightforward) approach is to ignore the fact that
> > the server (e.g. the controller) can be a client, and simply have it
> > incorporate its own set of YANG models to represent the other devices
> > below it.  The downside is that this requires the controller to
> > redefine and implement those models - they cannot be simply reused as
> > e.g. the "scope" is different, and the server has to have a semantic
> > "understanding" of everything in the devices underneath it. This
> > brings about the same situation that NMS has had for decades, that
> > integrating new devices into an operational environment is held
> > hostage by the NMS, which first needs to support (and require
> > corresponding development support for) all those new parameters.  In
> > our case, we want to have the option to simply incorporat
>  e "subtrees" from the device and make them accessible to other applications by
> mounting them, without requiring further development (or requiring systems to
> "go around" the controller, which complicates development of those other
> system and/or introduces other issues such as synchronization).
> > --- Alex
> >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Oct 2014 21:22:48 +0200

> Bringing in targeted nodes and subtrees need not require visibility into the full submodule where the authoritative copy of the object might reside.

There is anyxml in YANG 1.0 and there is a proposal for anydata in
YANG 1.1.

> The 'on-demand' Mount does not need any protocol work.  It is the easiest, and is looking to standardize needed several syntax extensions.  This type of Mount is what is implemented in OpenDaylight…

I am not sure. Can I run all NETCONF protocol operations transparently
across these mount points? I doubt it.  

What you introduce is a "partitioning" of a datastore that does not
architecturally exist so far. Does this lead to a new type of
datastore or can I partition any datastore? How does this partitioning
interact with ephemeral datastores discussed in I2RS? I believe there
are serious _architectural_ questions that need to be discussed and
depending on how they are resolved, there may be more or less protocol
work needed.

What triggered this discussions were statements of the form "YANG does
not allow to do X" which I think is not correct since YANG really is
not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is
responsible for the underlying architecture. RFC 6244 was produced by
NETMOD but then it describes more the framework and not the underlying
architectural model (what Randy Presuhn I think calls the meta
model). Perhaps we need to work on an architecture at some point in
time, pretty much like we needed to define an architecture for SNMP at
some point in time. The work on JSON encoding and the mount proposal
clearly indicates that certain architectural assumptions are implicit
and that leads to discussions that are difficult to close until we
agree on an architecture.

Who said history does not repeat?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Oct 2014 12:49:48 -0700

On Mon, Oct 13, 2014 at 12:22 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > If by falling out you mean 'in conflict with', then I would agree that
> there are not backwards compatibility issues with RFC 6020 section 6
> syntax.  This was by design.
> >
> > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC
> 6020.   This section includes statements such as:  "For a module or
> submodule to reference definitions in an external module, the external
> module MUST be imported."
> >
> > Bringing in targeted nodes and subtrees need not require visibility into
> the full submodule where the authoritative copy of the object might reside.
> >
>
> needed
> > The 'on-demand' Mount does not need any protocol work.  It is the
> easiest, and is looking to standardize needed several syntax extensions.
> This type of Mount is what is implemented in OpenDaylight today.
> >
>
This was my concern from the start.  I think the mounted data is now
read-only
so YANG datastore validation does not apply.

I do not want to partition the datastore.  This would require a big change
to
many documents (including YANG).  I can see that there might be some
data models where it would be useful to collect the info from all the
servers
into one container within the controller NBI, but this is more of a proxy
service
than a mid-level manager service.  I would expect the controller to provide
its own northbound data models, that did aggregation, topN reporting, etc.

The controller can use NETCONF as-is for the PULL model.
Whether NETCONF notifications are sufficient or the desired solution
to support a PUSH model is a valid issue -- but a general issue for
controllers,
not specific to the 'mount' draft.

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 13 Oct 2014 23:09:22 +0000

> From: Juergen Schoenwaelder, October 13, 2014 3:23 PM
> 
> > If by falling out you mean 'in conflict with', then I would agree that there are
> not backwards compatibility issues with RFC 6020 section 6 syntax.  This was by
> design.
> >
> > However I believe Alex' and Jan's concerns are with Section 5.1 of RFC 6020.
> This section includes statements such as:  "For a module or submodule to
> reference definitions in an external module, the external module MUST be
> imported."
> >
> > Bringing in targeted nodes and subtrees need not require visibility into the full
> submodule where the authoritative copy of the object might reside.
> >
> 
> There is anyxml in YANG 1.0 and there is a proposal for anydata in YANG 1.1.
>
 > > > I see protocol discussion in draft-clemm-netmod-mount-02.txt (which
> > > is needed for what you want to do and likely even incomplete) but
> > > then the NETMOD WG is not about protocol work but about the data
> > > modeling language YANG and data models. In fact, my reading of the
> > > I-D is that you do not request to change anything in YANG at all -
> > > all you propose is to define a few extensions and a data model.
> >
> > The 'on-demand' Mount does not need any protocol work.  It is the easiest,
> and is looking to standardize needed several syntax extensions.  This type of
> Mount is what is implemented in OpenDaylight today.
> >
> 
> I am not sure. Can I run all NETCONF protocol operations transparently across
> these mount points? I doubt it.

For the use cases in the requirements document, the applications/use cases are for the "read only" type of Mount.  (I.e., I am not looking for the full set of NETCONF protocol operations.  I would rather have write operations go through existing/embedded data consistency protections.)

> architecturally exist so far. Does this lead to a new type of datastore or can I
> partition any datastore? How does this partitioning interact with ephemeral
> datastores discussed in I2RS? I believe there are serious _architectural_
> questions that need to be discussed and depending on how they are resolved,
> there may be more or less protocol work needed.

Rather than partitioning, I actually see that this is more of a merging of datastores across devices.  The reality is that there are multiple datastore instances across the network, and some of us are trying to break down the physical barriers which keep them separate -- at least from the point of view of some types of applications.   (These types of applications are those which desire to view various sets of network elements as a cloud.)

In any case, these are exactly the types of dialogs the drafts are trying to kick-start.  Today's 'Mount' implementations built in Open Source forums will be much poorer if they lack the types of due-diligence the IETF can drive here.

> What triggered this discussions were statements of the form "YANG does not
> allow to do X" which I think is not correct since YANG really is not the issue. The
> mount work is extending/modifying/$(your-verb-here)
> responsible for the underlying architecture. RFC 6244 was produced by NETMOD
> but then it describes more the framework and not the underlying architectural
> model (what Randy Presuhn I think calls the meta model). Perhaps we need to
> work on an architecture at some point in time, pretty much like we needed to
> define an architecture for SNMP at some point in time. The work on JSON
> encoding and the mount proposal clearly indicates that certain architectural
> assumptions are implicit and that leads to discussions that are difficult to close
> until we agree on an architecture.

This is completely reasonable to me.  RFC6244 page 14 asserts a device boundary which has been surpassed by reality.  YANG already is being applied for more than this.   

In the future I expect YANG models and syntax which to provide for multi-device abstractions.  And we shouldn't be limited to just NETCONF transport.  

I recognize that the IETF hasn't partitioned the problem in quite this way before.  As you point out, this is a discussion beyond just this WG.  Based on what is happening in the industry, we don't have endless cycles to solve this problem.  I will add Benoit to this thread as the problem is one which is relevant to multiple WGs and charters -- and perhaps to new charters.

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 13 Oct 2014 23:37:22 +0000

From: Andy Bierman, October 13, 2014 3:50 PM
<snip>

This was my concern from the start.  I think the mounted data is now read-only
so YANG datastore validation does not apply.

<Eric> Yes, read-only meets the needs of the use cases in the requirements draft.  For now hopefully existing validation mechanisms can handle feedback towards the authoritative owner of an object.

I do not want to partition the datastore.  This would require a big change to
many documents (including YANG).  I can see that there might be some
data models where it would be useful to collect the info from all the servers
into one container within the controller NBI, but this is more of a proxy service
than a mid-level manager service.  I would expect the controller to provide
its own northbound data models, that did aggregation, topN reporting, etc.

<Eric> There are many defacto multi-device controllers embedded within existing network protocols (VRRP, ICCP, etc.).  These controllers have overlapping domains of interest.  These controllers are perceived as 'real-time'.  They should not be seen as proxy as they create their own info based on the underlying device abstractions/state.   YANG syntax is an excellent way to talk with these network embedded controllers.

The controller can use NETCONF as-is for the PULL model.
Whether NETCONF notifications are sufficient or the desired solution
to support a PUSH model is a valid issue -- but a general issue for controllers,
not specific to the 'mount' draft.

<Eric>

*        Network elements will need to push their operational data to many subscribers. Some implementations already use YANG syntax here.  Netconf notifications have been demonstrated as insufficient for these applications.

*        Push of object changes from network elements is the only way to get fast enough response time into application subscribers which exist off-box.

*        There will be many controllers.  There already are.  We will not shrink back to just one.

*        We need transports other than NETCONF.  Faster performance from multicast Read-only object distribution is a good example of why NETCONF might not be the only answer.

Eric

/js

Andy

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

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 14 Oct 2014 00:52:14 +0000

Hi Juergen,
(several threads to respond to; Eric already provided responses to a lot of the items, here just a few summary items from my perspective)

Re: what technical details we think should be standardized:

- The first aspect is the YANG extension that allows users to define mountpoints (to logically incorporate subtrees from a remote datastore under a data node).  This can be done as part of a YANG module, i.e. is data model related.  

- The second aspect is a YANG data model that allows to monitor and manage a "mount topology".  This addresses the system management aspects of this concept, generally not of concern to the applications that want to simply access the datastore, but required for a "complete" solution.  Again, this can be done as part of a YANG module, i.e. is data model related.  

- The third aspect concerns the ability to subscribe to updates to a YANG datatree, and "push" those updates.  This is more general than mount itself and should presumably be separated into a separate draft.  Subscriptions can be represented as a configurable data model.  Likewise, push can occur through notifications, definable as part of a data model related.  So, that one too is data model related.  (It is conceivable to also introduce different transports here, which would be discussion for a transport forum; however, our intent was to address these within the existing framework.)  

Re: overall architecture, you are bringing up an interesting point that probably needs visiting.  RFC 6244, in section 3.1, clearly depicts the boundary of the server as one device.  It also suggests that the datastore does not reach beyond the device boundaries (datastore is actually not depicted, but config database and "system software components" - presumably for the config data).  This is why we believe the mount capability is needed - to allow the datastore to reach beyond those boundaries.  If this involves extending the architecture, then so be it.  Worth mentioning along the same lines, since RFC 6244 assumes that YANG will be always used in conjunction with Netconf: Really, we would like to consider Netconf just one particular transport / set of services that can operate on / interact with a datastore, geared towards configuration and fulfillment-related use cases.  That should not rule out the possibility to apply other transports and services - such as RESTconf (the possibility for which is not considered in the RFC), and going forward possibly other transports/ interfaces, that for example focus on pushing datastore information and operational data for applications which today might use SNMP.  

Regarding making this transparent for all Netconf operations:  The important aspect and primary focus of the use case lies in providing an ability to retrieve remote information.  The motivation behind all this is not to provid "ACID" style management transactions across the network - in fact, we believe that for many applications a "BASE" style of management is preferrable and more appropriate, in which transactional guarantees, ability to rollback,etc, are not provided as long as state becomes eventually consistent. This is also reflected in the companion requirements spec.  We do not want to be bogged down in the aspects that would be required to make ACID work.  While we believe that "simple" configuration (not including transactions spanning multiple items) is achievable, we are happy to "scale down" the mount concept accordingly and leave transactionality or even configuration as a whole out of scope.  

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); [email-masked]
Subject: Re: [netmod] New revision of YANG mount draft

> The 'on-demand' Mount does not need any protocol work.  It is the easiest, and is looking to standardize needed several syntax extensions.  This type of Mount is what is implemented in OpenDaylight…

I am not sure. Can I run all NETCONF protocol operations transparently across these mount points? I doubt it.  

What you introduce is a "partitioning" of a datastore that does not architecturally exist so far. Does this lead to a new type of datastore or can I partition any datastore? How does this partitioning interact with ephemeral datastores discussed in I2RS? I believe there are serious _architectural_ questions that need to be discussed and depending on how they are resolved, there may be more or less protocol work needed.

What triggered this discussions were statements of the form "YANG does not allow to do X" which I think is not correct since YANG really is not the issue. The mount work is extending/modifying/$(your-verb-here)
the _architecture_ of NETCONF and YANG. It is not clear which WG is responsible for the underlying architecture. RFC 6244 was produced by NETMOD but then it describes more the framework and not the underlying architectural model (what Randy Presuhn I think calls the meta model). Perhaps we need to work on an architecture at some point in time, pretty much like we needed to define an architecture for SNMP at some point in time. The work on JSON encoding and the mount proposal clearly indicates that certain architectural assumptions are implicit and that leads to discussions that are difficult to close until we agree on an architecture.

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 14 Oct 2014 00:58:15 +0000

Hi Qin,

...

[Qin] Interesting, Is this idea about datastore data synchronization in different levels. One subset of datastore data in lower level can be nested into a datastore in higher level and inserted as mounting point. Datastore data in lower level doesn't need to be unfolded or exposed to more higher level client that is on top of the controller. Mounting point provide a reference point in the remote datastore to retrieve the data. Network topo information gathering can be a good example for such data retrieving. 

<ALEX>  Exactly </ALEX>

[Qin]
But it is not clear to me how this can support multi-tenancy when different tenant has different view of network topo.
In addition, where to insert data from remote datastore in the local datastore is not very clear as well. 

<ALEX> Where to insert data is specified by a YANG module, implemented by the client, which specifies the mount point i.e. data nodes in the datastore structure where to "insert" the remote data.  
Multi-tenancy is not specifically addressed here, although it constitutes a valid use case (perhaps something to spell out in the requirement draft).  You can have different client systems, each in turn with their own datastore, and each implementing different YANG models with different mount points, which therefore mount different information from a server (or incorporate them in differen ways into their own respective datastore structure).  </ALEX>

--- Alex

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 14 Oct 2014 08:39:50 -0400

[netmod Chair hat off]

> architecturally exist so far.

	That depends on what you define as architecture. This is implemented, and in production now in a number of commercial products. For full disclosure this is implemented in one of my products, and works quite well. If that doesn't count as "running code" from the IETF mantra, I don't know what is.  We should use those implementations to guide our lack of architecture rather than saying we should hold the phone until such time as the Yang gods can construct an architectural blueprint. Its exactly that sort of thing that has pushed people away from the IETF.

> Does this lead to a new type of

	It does seem to do this, and we should discuss for sure. We should also figure out a way to embrace these new ways of using Yang and Netconf variants.  We should not push them away just because they were unforeseen by originators of Yang/Netconf.  

> agree on an architecture.

	These are new use cases that people clearly want - they're implemented in numerous places now and in many places, in code that you and I can download and review (and run) right now. So rather than debate which WG they go into, we should figure out how to move things forward and embrace them or they will be "standardized" elsewhere. I will note that the original mount draft and restconf drafts are over a year old now. What have we been waiting for?

	I vote that we let Benoit worry about which WG these go into, but ask that he find one soon.

	--Tom

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 14 Oct 2014 14:46:21 +0200 (CEST)

"Thomas D. Nadeau" <[email-masked]> wrote:
> 	That depends on what you define as architecture. This is implemented,
> 	and in production now in a number of commercial products. For full
> 	disclosure this is implemented in one of my products, and works quite
> 	well.

Are you saying that your code uses the mount mechansim as described in
this draft?  If so, does your product implement read-write mount as
described in the draft?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 14 Oct 2014 15:28:07 +0200 (CEST)

Hi,

"Alexander Clemm (alex)" <[email-masked]> wrote:
> - The first aspect is the YANG extension that allows users to define
> mountpoints (to logically incorporate subtrees from a remote
> datastore under a data node).  This can be done as part of a YANG
> module, i.e. is data model related.   

I would generalize this one even more: a mechanism that allows users
to logically incorporate subtrees from a module under a data node.

I.e., what I think might be needed and would be useful to standardize
is a mechansim to extended the *schema*.  Note the difference; you
talk about extending datastores (which I find problematic) and I talk
about extending the schema.

FWIW, we are using something like this in our controller application
NCS.

> - The second aspect is a YANG data model that allows to monitor and
> manage a "mount topology".  This addresses the system management
> aspects of this concept, generally not of concern to the
> applications that want to simply access the datastore, but
> required for a "complete" solution.  Again, this can be done as
> part of a YANG module, i.e. is data model related. 

With the more general schema extension mechansim I described above, I
would say that the second aspect of your proposal is a mechanism to
implement these schema extensions by the concept of "mounting"
(including a data model to monitor and manage this).

This part seems to be pretty complex in all but the read-only use
case.

> - The third aspect concerns the ability to subscribe to updates to a
> YANG datatree, and "push" those updates.  This is more general than
> mount itself and should presumably be separated into a separate
> draft.  Subscriptions can be represented as a configurable data
> model.  Likewise, push can occur through notifications, definable as
> part of a data model related.  So, that one too is data model
> related.  (It is conceivable to also introduce different transports
> here, which would be discussion for a transport forum; however, our
> intent was to address these within the existing framework.)

Ok, but the draft doesn't actually propose a concrete mechansim.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Oct 2014 08:40:27 -0700

On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) <[email-masked]>
wrote:

> Hi Juergen,
> (several threads to respond to; Eric already provided responses to a lot
> of the items, here just a few summary items from my perspective)
>
> mountpoints (to logically incorporate subtrees from a remote datastore
> under a data node).  This can be done as part of a YANG module, i.e. is
> data model related.
>
> - The second aspect is a YANG data model that allows to monitor and manage
> a "mount topology".  This addresses the system management aspects of this
> concept, generally not of concern to the applications that want to simply
> access the datastore, but required for a "complete" solution.  Again, this
> can be done as part of a YANG module, i.e. is data model related.
>
> - The third aspect concerns the ability to subscribe to updates to a YANG
> datatree, and "push" those updates.  This is more general than mount itself
> and should presumably be separated into a separate draft.  Subscriptions
> can be represented as a configurable data model.  Likewise, push can occur
> through notifications, definable as part of a data model related.  So, that
> one too is data model related.  (It is conceivable to also introduce
> different transports here, which would be discussion for a transport forum;
> however, our intent was to address these within the existing framework.)
>
> Re: overall architecture, you are bringing up an interesting point that
> probably needs visiting.  RFC 6244, in section 3.1, clearly depicts the
> boundary of the server as one device.

This is intentional and IMO the proper architecture for a NETCONF datastore.
The datastore is intended to represent one device, whether that device is a
giant
network controller or a tiny access point.

I don't agree that replication of subtrees from other servers is the proper
architecture for
a network-wide datastore.  It doesn't matter for monitoring, but for
editing the subtrees
are all part of 1 configuration datastore, not isolated replicated
subtrees.

> It also suggests that the datastore does not reach beyond the device
> boundaries (datastore is actually not depicted, but config database and
> "system software components" - presumably for the config data).  This is
> why we believe the mount capability is needed - to allow the datastore to
> reach beyond those boundaries.  If this involves extending the
> architecture, then so be it.  Worth mentioning along the same lines, since
> RFC 6244 assumes that YANG will be always used in conjunction with Netconf:
> Really, we would like to consider Netconf just one particular transport /
> set of services that can operate on / interact with a datastore, geared
> towards configuration and fulfillment-related use cases.  That should not
> rule out the possibility to apply other transports and services - such as
> RESTconf (the possi
>  bility for which is not considered in the RFC), and going forward
> possibly other transports/ interfaces, that for example focus on pushing
> datastore information and operational data for applications which today
> might use SNMP.
>
> Regarding making this transparent for all Netconf operations:  The
> important aspect and primary focus of the use case lies in providing an
> ability to retrieve remote information.  The motivation behind all this is
> not to provid "ACID" style management transactions across the network - in
> fact, we believe that for many applications a "BASE" style of management is
> preferrable and more appropriate, in which transactional guarantees,
> ability to rollback,etc, are not provided as long as state becomes
> eventually consistent. This is also reflected in the companion requirements
> spec.  We do not want to be bogged down in the aspects that would be
> required to make ACID work.  While we believe that "simple" configuration
> (not including transactions spanning multiple items) is achievable, we are
> happy to "scale down" the mount concept accordingly and leave
> transactionality or even configuration as a whole out of scope.
>
>
I don't see what is stopping you from implementing your controller.
If you wrap the remote config in anyxml, then all the YANG validation
problems go away.  The controller can send NETCONF requests to the remote
devices
on behalf of the northbound client.   This seems like just an
implementation detail
for the controller, not a standards issue.

The request to have the devices push all their operational data to the
controller
is a different matter.  That has a huge operational impact, and something
that
NETCONF is not designed for.  I suggest using IPFIX for that.

Andy

> architecturally exist so far. Does this lead to a new type of datastore or
> can I partition any datastore? How does this partitioning interact with
> ephemeral datastores discussed in I2RS? I believe there are serious
> _architectural_ questions that need to be discussed and depending on how
> they are resolved, there may be more or less protocol work needed.
>
> allow to do X" which I think is not correct since YANG really is not the
> issue. The mount work is extending/modifying/$(your-verb-here)
> architectural model (what Randy Presuhn I think calls the meta model).
> Perhaps we need to work on an architecture at some point in time, pretty
> much like we needed to define an architecture for SNMP at some point in
> time. The work on JSON encoding and the mount proposal clearly indicates
> that certain architectural assumptions are implicit and that leads to
> discussions that are difficult to close until we agree on an architecture.
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Oct 2014 19:43:37 +0000

This conversation is going full-circle, so I'll go back to my original point - that I don't understand the importance for IETF standardization and question the effectiveness of the solution.

EMS systems managing devices using NETCONF/YANG have been around for a few years.  It is pretty common for them to 1) provide a mechanism to get the YANG module used by a device and 2) a low-level API to get/set device-specific config (as modeled by its YANG) - all with clear separation of which system "owns" which data.    This draft proposes to fulfill the same need, but in a way that is unique to a Controller/EMS that itself presents a YANG-defined NETCONF/RESTCONF model.   Under those circumstances, I can almost understand the line of thinking that led to "mounting" idea (why not, right?), but is this really how a higher-level OSS/BSS would want it presented.  Why wouldn't the higher-level system use NETCONF to the device directly?  - what semantics does "mounting" bring above and beyond a direct connection to the device (approval-workflow or network-wide transactional-updates?)

To Tom's point, it's not enough that some products implement an idea for there to be a need to add it to a WG charter.  I'd rather see pressing interoperability considerations driving that.

All that said, I do support the idea of enhancing NETCONF notifications, if RFC6470's netconf-config-change event isn't sufficient.  If there is a deficiency there, then all NETCONF clients (not "mount clients") would benefit.

Thanks,
Kent

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 14, 2014 at 11:40 AM
To: "Alexander Clemm (alex)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] New revision of YANG mount draft

On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Juergen,
(several threads to respond to; Eric already provided responses to a lot of the items, here just a few summary items from my perspective)

Re: overall architecture, you are bringing up an interesting point that probably needs visiting.  RFC 6244, in section 3.1, clearly depicts the boundary of the server as one device.

This is intentional and IMO the proper architecture for a NETCONF datastore.
The datastore is intended to represent one device, whether that device is a giant
network controller or a tiny access point.

I don't agree that replication of subtrees from other servers is the proper architecture for
a network-wide datastore.  It doesn't matter for monitoring, but for editing the subtrees
are all part of 1 configuration datastore, not isolated replicated subtrees.

It also suggests that the datastore does not reach beyond the device boundaries (datastore is actually not depicted, but config database and "system software components" - presumably for the config data).  This is why we believe the mount capability is needed - to allow the datastore to reach beyond those boundaries.  If this involves extending the architecture, then so be it.  Worth mentioning along the same lines, since RFC 6244 assumes that YANG will be always used in conjunction with Netconf: Really, we would like to consider Netconf just one particular transport / set of services that can operate on / interact with a datastore, geared towards configuration and fulfillment-related use cases.  That should not rule out the possibility to apply other transports and services - such as RESTconf (the possi
 bility for which is not considered in the RFC), and going forward possibly other transports/ interfaces, that for example focus on pushing datastore information and operational data for applications which today might use SNMP.

I don't see what is stopping you from implementing your controller.
If you wrap the remote config in anyxml, then all the YANG validation
problems go away.  The controller can send NETCONF requests to the remote devices
on behalf of the northbound client.   This seems like just an implementation detail
for the controller, not a standards issue.

The request to have the devices push all their operational data to the controller
is a different matter.  That has a huge operational impact, and something that
NETCONF is not designed for.  I suggest using IPFIX for that.

--- Alex

Andy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] New revision of YANG mount draft

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 14 Oct 2014 20:22:22 +0000

Hi Martin

...

[Martin] I would generalize this one even more: a mechanism that allows users to logically incorporate subtrees from a module under a data node.

I.e., what I think might be needed and would be useful to standardize is a mechansim to extended the *schema*.  Note the difference; you talk about extending datastores (which I find problematic) and I talk about extending the schema.

<ALEX> Yes, they are different.  I can see potentially the need for both.   I am not sure why extending the datastore itself would be problematic.  I assume with "extending" you mean having the scope extend beyond the boundary of the device". 
</ALEX>

FWIW, we are using something like this in our controller application NCS.

> aspects of this concept, generally not of concern to the applications 
> that want to simply access the datastore, but required for a 
> "complete" solution.  Again, this can be done as part of a YANG 

With the more general schema extension mechansim I described above, I would say that the second aspect of your proposal is a mechanism to implement these schema extensions by the concept of "mounting"
(including a data model to monitor and manage this).

This part seems to be pretty complex in all but the read-only use case.

<ALEX> For the solution to be complete, this seems to be required because at the end of the day, we have "mount topology" which a system administrator may want to have visibility into.  That said, I certainly agree with your implied sentiment that in general an implementation will and should bootstrap this topology on its own, instead of requiring administrator intervention.  
</ALEX>

> mount itself and should presumably be separated into a separate draft.  
> Subscriptions can be represented as a configurable data model.  
> Likewise, push can occur through notifications, definable as part of a 
> data model related.  So, that one too is data model related.  (It is 
> conceivable to also introduce different transports here, which would 
> be discussion for a transport forum; however, our intent was to 
> address these within the existing framework.)

<ALEX> True, at this point it just has the requirements for that; we were planning for the next draft to have a proposal, although I think this should better be separated out as this is more general
</ALEX>
Thanks,
--- Alex

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 14 Oct 2014 20:49:18 +0000

Hi Andy,

...

<ALEX> Yes, the current architecture has a NETCONF datastore clearly delimited within the boundaries of a device.  This makes for a simple architecture, continuing what we have grown used to e.g. with SNMP, but also a bit limited.  For one, if you have to deal with a network with many devices, it means that each of these devices exist purely in isolation; interdependencies between devices have to be dealt with at a different layer.  Also, with SDN, NFV etc, boundaries between devices become increasingly "blurry" and matter less than they have in the past; IMHO it would be good if the architecture would reflect that by not necessarily tieing itself to physical device boundaries which may be increasingly constraining.  Thirdly, the fact that the architecture ties the datastore to Netconf is a problem as well; we see with RESTconf alternative transports to emerge, and the fact that a datastore can contain operational data as well and given Netconf is not an ideal match for service assurance applications may mean that it will be good to be able to support additional transports/services in the future.  Either that, or keep Netconf and YANG to a "niche" set of applications limited to device configuration - but I for one think that the opportunity is greater than that. For that reason, I would like to see the architecture be able to allow to accommodate straightforward extensions like the one proposed.
</ALEX>

<ALEX>
As discussed earlier on the thread, the primary use cases revolve around information retrieval more than the ability to configure stuff, so we are happy to limit the proposal to just that aspect.  For retrieval, we want however to do a bit better than anyxml, for analogous reasons for which YANG was defined (which includes support for non-configuration data, not just simply addressed through anyxml either).
</ALEX

<ALEX>
IPFIX is one option, although what we had in mind was more in line with the Netconf/YANG framework itself.  Either way, agree it is a separate matter which needs to be addressed separately.
</ALEX>

Thanks

--- Alex

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 14 Oct 2014 22:19:33 +0000

Hi Kent,

There are multiple reasons why current NETCONF based solutions don't hit all the requirements discussed during the thread.  Below is a short incomplete list...

(1) New Service types require systems built upon Eventually Consistency. If we want to distribute read-only data fast, we might choose transports other than NETCONF.  We might choose protocols which aren't connection oriented.  We might even choose to use Multicast distribution.  (Imagine hundreds of VMs reacting to dynamic global config being delivered from a single definitive source.)  Such alternative transports can remove the burden from the single central system processing knowing and maintaining connections with each of the devices.

(2) There is nothing specific to YANG syntax which makes it only applicable to EMS.   Or specific to point-to-point connection oriented delivery.  The syntax is useful (and used) elsewhere.

(3) Once we establish that Netconf is not optimal for all transport options, using a common (YANG) syntax across multiple transports is demonstrably valuable.  This allows transport optimizations to be abstracted away from logical information model design.

(4) There are already multiple types of controllers in the network.  Each use their own specific protocol to exchange config and status.  Why ignore that there are already multi-device abstractions in the network?  Why ignore that treating aggregates only by device boundary units can and will drive errors into a system?    Configuring each device individually is error prone for some abstractions.

(5) Providing visibility into a peer's persistent and running config data can be very useful.

(6) Many of these new services can reside within network elements just as easily as within controllers.  Why would we create unnecessary technology barriers based on historic roles?

(7) There is huge investment in multiple places on this type of technology (e.g., OpenDaylight Mount, DDS).  Why fight against trends proving successful already?   The IETF should incorporate these capabilities where advantageous.

IMHO it is in the IETF interests to support fulfill these requirements.  If we don't ownership will go elsewhere.  There are already implementations driven by the list of imperatives above.

Eric

From: netmod [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Tuesday, October 14, 2014 3:44 PM
To: Andy Bierman; Alexander Clemm (alex)
Cc: [email-masked]
Subject: Re: [netmod] New revision of YANG mount draft

Thanks,
Kent

--- Alex

Andy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] New revision of YANG mount draft

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Oct 2014 15:47:30 -0700

On Tue, Oct 14, 2014 at 3:19 PM, Eric Voit (evoit) <[email-masked]> wrote:

>  Hi Kent,
>
>
>
> There are multiple reasons why current NETCONF based solutions don't hit
> all the requirements discussed during the thread.  Below is a short
> incomplete list...
>
>
>
> (1) New Service types require systems built upon Eventually Consistency.
> If we want to distribute read-only data fast, we might choose transports
> other than NETCONF.  We might choose protocols which aren't connection
> oriented.  We might even choose to use Multicast distribution.  (Imagine
> hundreds of VMs reacting to dynamic global config being delivered from a
> single definitive source.)  Such alternative transports can remove the
> burden from the single central system processing knowing and maintaining
> connections with each of the devices.
>
>
>
> (2) There is nothing specific to YANG syntax which makes it only
> applicable to EMS.   Or specific to point-to-point connection oriented
> delivery.  The syntax is useful (and used) elsewhere.
>
>
>
> (3) Once we establish that Netconf is not optimal for all transport
> options, using a common (YANG) syntax across multiple transports is
> demonstrably valuable.  This allows transport optimizations to be
> abstracted away from logical information model design.
>
>
>
> (4) There are already multiple types of controllers in the network.  Each
> use their own specific protocol to exchange config and status.  Why ignore
> that there are already multi-device abstractions in the network?  Why
> ignore that treating aggregates only by device boundary units can and will
> drive errors into a system?    Configuring each device individually is
> error prone for some abstractions.
>
>
I don't see what (1) - (4) have to do with replicating subtrees from
multiple devices into a controller.
New transports for NETCONF can be defined, if there is enough interest.
It's OK if other protocols use YANG.  NETCONF does not have to solve every
problem.

> (5) Providing visibility into a peer's persistent and running config data

There are protocol-specific modules for that.
Topology is a good example of what I mean by collection of devices vs.
network-view.
An EMS could collect the neighbor tables from all the devices and replicate
them for
its northbound clients.  Or it could resolve the device data into one
network-wide view,
dealing with duplicates, mobility, etc.

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.

>
> (6) Many of these new services can reside within network elements just as
> easily as within controllers.  Why would we create unnecessary technology
> barriers based on historic roles?
>
>
>
> (7) There is huge investment in multiple places on this type of technology
> (e.g., OpenDaylight Mount, DDS).  Why fight against trends proving
> successful already?   The IETF should incorporate these capabilities where
> advantageous.
>
>
>
> IMHO it is in the IETF interests to support fulfill these requirements.
> If we don't ownership will go elsewhere.  There are already implementations
> driven by the list of imperatives above.
>
>
>
> Eric
>

Andy

>
>
> *From:* netmod [mailto:[email-masked]] *On Behalf Of *Kent Watsen
> *Sent:* Tuesday, October 14, 2014 3:44 PM
> *To:* Andy Bierman; Alexander Clemm (alex)
> *Cc:* [email-masked]
> *Subject:* Re: [netmod] New revision of YANG mount draft
>
>
>
>
>
> This conversation is going full-circle, so I'll go back to my original
> point - that I don't understand the importance for IETF standardization and
> question the effectiveness of the solution.
>
>
>
> EMS systems managing devices using NETCONF/YANG have been around for a few
> years.  It is pretty common for them to 1) provide a mechanism to get the
> YANG module used by a device and 2) a low-level API to get/set
> device-specific config (as modeled by its YANG) - all with clear separation
> of which system "owns" which data.    This draft proposes to fulfill the
> same need, but in a way that is unique to a Controller/EMS that itself
> presents a YANG-defined NETCONF/RESTCONF model.   Under those
> circumstances, I can almost understand the line of thinking that led to
> "mounting" idea (why not, right?), but is this really how a higher-level
> OSS/BSS would want it presented.  Why wouldn't the higher-level system use
> NETCONF to the device directly?  - what semantics does "mounting" bring
> above and beyond a direct connection to the device (approval-workflow or
> network-wide transactional-updates?)
>
>
>
> To Tom's point, it's not enough that some products implement an idea for
> there to be a need to add it to a WG charter.  I'd rather see pressing
> interoperability considerations driving that.
>
>
>
> All that said, I do support the idea of enhancing NETCONF notifications,
> if RFC6470's netconf-config-change event isn't sufficient.  If there is a
> deficiency there, then all NETCONF clients (not "mount clients") would
> benefit.
>
>
>
> Thanks,
>
> Kent
>
>
>
>
>
> *From: *Andy Bierman <[email-masked]>
> *Date: *Tuesday, October 14, 2014 at 11:40 AM
> *To: *"Alexander Clemm (alex)" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [netmod] New revision of YANG mount draft
>
>
>
>
>
>
>

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Wed, 15 Oct 2014 00:01:57 +0000

From:  Andy Bierman <[email-masked]>
Date:  Saturday, October 11, 2014 at 10:30 AM
To:  Juergen Schoenwaelder <[email-masked]>,
"Alexander Clemm (alex)" <[email-masked]>, Jan Medved <[email-masked]>,
Kent Watsen <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [netmod] New revision of YANG mount draft

>
>
>On Sat, Oct 11, 2014 at 3:27 AM, Juergen Schoenwaelder
><[email-masked]> wrote:
>
>Alex,
>
>I do not agree with the premise that the network-level data models need
>to be

Nobody is saying that the requirement is network-level management. There
simply is a class of controller SDN apps that need to read/write data from
devices. These apps can be a part of the controller (controller plugins )
or remote, in which case they use the controller REST APIs.

>The controller can use NETCONF as its southbound protocol to the devices.

True. But the controller can also use NETCONF as the northbound protocol.
Or RESTCONF, for that matter.

>It should decide what data to collect and what northbound data models to

Why should the controller be limited to a use case where it has different
southbound and northbound models? The controller infrastructure should be
a generic transparent plumbing that connects model providers with model
consumers. Model consumers can be controller apps (we can call them
extensions, plugins, ...) or external apps. Model providers are devices or
controller apps or even external apps.

Your use case where the controller has different northbound and southbound
models could be (and in ODL would be) implemented by a set of plugins that
are loaded into the controller. A plugin that understands a particular
device model from a particular vendor (which is designed/compiled against
that device model) can populate a northbound data model. Different vendors
can provide plugins for their devices. A particular controller
distribution is assembled from different vendors¹ plugins at integration
time; if desired, a controller user should be able to load a vendor¹s new
plugin into the controller at a later point when a new device is
introduced into the network. The controller does not know a priori what
models will be loaded into it during its lifetime (or in a particular
controller config). Therefore, the controller needs a mechanism to extend
the controller¹s schemas (Martin's re-statement of the problem is IMO
spot-on).

>I don't see why the devices need to be configured for this purpose.

That would be a very limited (and limiting) view of SDN. I also disagree
that the controller decides what data to collect and what northbound data
models to populate. For both case, it¹s the controller apps (and I count
the controller plugins as apps) that decide what data they want want to
collect from the network and what devices and how they want to program.

Thanks,
Jan

>>request to change anything in YANG at all - all you propose is to define
>>a few extensions and a data model."  Yes, I agree; your understanding is
>>correct.  The proposal we are making addresses
> the requirements within the existing framework.
>>
>>implementation of this will be facilitated by having a push and/or
>>pub/sub model for data subtrees.  This does not necessarily require
>>actual protocol work (although such work could be defined)
> but can be addressed again within the existing framework, using a
>subscription configuration model, notifications etc as outlined in the
>draft.
>>
>> --- Alex
>>
>>NETMOD WG is not about protocol work but about the data modeling
>>language YANG and data models. In fact, my reading
> of the I-D is that you do not request to change anything in YANG at all
>- all you propose is to define a few extensions and a data model.
>>
>>device).  One (straightforward) approach is to ignore
> the fact that the server (e.g. the controller) can be a client, and
>simply have it incorporate its own set of YANG models to represent the
>other devices below it.  The downside is that this requires the
>controller to redefine and implement those models - they
>decades, that integrating new devices into
> an operational environment is held hostage by the NMS, which first needs
>to support (and require corresponding development support for) all those
>new parameters.  In our case, we want to have the option to simply
>incorpor
>development of those other system and/or introduces
> other issues such as synchronization).
>> > --- Alex
>> >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 15 Oct 2014 00:50:21 +0000

From: Andy Bierman, October 14, 2014 6:47 PM

On Tue, Oct 14, 2014 at 3:19 PM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kent,

I don't see what (1) - (4) have to do with replicating subtrees from multiple devices into a controller.

<Eric> This is a many-to-many configuration problem (not just a many devices to one controller problem).

Example 1: what if a central application wants to a  push and maintain a global policy concurrently across devices.  If hundred/thousands of VMs have mounted that central policy, all devices get fast updates as well as knowing which copy is authoritative.      Yes, this could be done with custom code.  Yes we could take managed objects and have application logic determine where to push them.  But why would you want to require this where it is unnecessary?

Example 2: Why not let the remote device datastores decide what central information they need to track?  With VMs and new edge compute power we should expect that remote devices will host a dynamic set of applications.  These applications could dynamically adjust their local object needs in ways a central controller could never hope to support.

Example 3: What if the remote device needs an object very rarely?  Remote mounting provides a way to get the info only when necessary.  And when you do on-demand mount, you know the info is current.

New transports for NETCONF can be defined, if there is enough interest.
It's OK if other protocols use YANG.  NETCONF does not have to solve every problem.

<Eric> Excellent

<Eric> Some protocol-specific modules exist,  many do not.   For example there is no way for peer devices to know the Ethernet OAM timer of a neighbor, or its Ethernet frame size.  If would be great for a device to be able to access (Mount) such peer config information.  Local applets could then take multi-box troubleshooting steps off of a human.

Topology is a good example of what I mean by collection of devices vs. network-view.
An EMS could collect the neighbor tables from all the devices and replicate them for
its northbound clients.  Or it could resolve the device data into one network-wide view,
dealing with duplicates, mobility, etc.

<Eric> One EMS will not solve all needs.   Topology is a function of protocol.   A spanning tree topology, an OSPF topology, a BGP topology all could touch the same device.  But they are unlikely to care about an identical set of devices.  Nevertheless, they all might care to subscribe/mount the state of particular line card (e.g., in case of failure).    Since controllers do traffic engineering, such speed is often critical.

It is often network convergence timers which unify connectivity across topologies today.

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

Andy

From: netmod [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kent Watsen
Sent: Tuesday, October 14, 2014 3:44 PM
To: Andy Bierman; Alexander Clemm (alex)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] New revision of YANG mount draft

Thanks,
Kent

--- Alex

Andy

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, October 13, 2014 12:23 PM
To: Eric Voit (evoit)
Cc: Alexander Clemm (alex); [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] New revision of YANG mount draft

/js

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 15 Oct 2014 10:49:18 -0400

On Oct 14, 2014:6:19 PM, at 6:19 PM, Eric Voit (evoit) <[email-masked]> wrote:

> Hi Kent,
>  
> There are multiple reasons why current NETCONF based solutions don’t hit all the requirements discussed during the thread.  Below is a short incomplete list…
>  
> (1) New Service types require systems built upon Eventually Consistency. If we want to distribute read-only data fast, we might choose transports other than NETCONF.  We might choose protocols which aren’t connection oriented.  We might even choose to use Multicast distribution.  (Imagine hundreds of VMs reacting to dynamic global config being delivered from a single definitive source.)  Such alternative transports can remove the burden from the single central system processing knowing and maintaining connections with each of the devices.
>  
> (5) Providing visibility into a peer’s persistent and running config data can be very useful.
>  
	
	[NETMOD Chair hat on]

	It might help to breakup the list above into the three areas someone suggested the other day (maybe Kent?):

	yang extension, yang data model, update subscription

> IMHO it is in the IETF interests to support fulfill these requirements.  If we don’t ownership will go elsewhere.  There are already implementations driven by the list of imperatives above.

	I have discussed whether or not this fits into this WG or another yesterday with Benoit. He agreed this goes somewhere at the IETF, but specifically 
where is up for debate. He has taken the action to chime in with a direction ASAP.

	--Tom

> To: "Alexander Clemm (alex)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> On Mon, Oct 13, 2014 at 5:52 PM, Alexander Clemm (alex) <[email-masked]> wrote:
> Hi Juergen,

---

From: Qin Wu <[email-masked]>
Date: Thu, 16 Oct 2014 06:44:27 +0000

Hi, Alex:
-----邮件原件-----
发件人: Alexander Clemm (alex) [mailto:[email-masked]] 
发送时间: 2014年10月14日 8:58
收件人: Qin Wu; Juergen Schoenwaelder; Jan Medved (jmedved)
抄送: [email-masked]
主题: RE: [netmod] New revision of YANG mount draft

Hi Qin,

...

<ALEX>  Exactly </ALEX>

[Qin]

[Qin]: Have you considered retrieving point in the remote datastore if you only retrieve a subset of the datastore data?

[Qin]: The use case you give seems an good example, but I am not sure it is achievable, without abstraction and aggregation of data retrieved from remote datastore, without filtering mechanism, I doubt multi-tenancy can be well supported.

--- Alex

---

From: Qin Wu <[email-masked]>
Date: Thu, 16 Oct 2014 08:13:15 +0000

Hi,
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Alexander Clemm (alex)
发送时间: 2014年10月14日 8:52
收件人: Juergen Schoenwaelder; Eric Voit (evoit)
抄送: [email-masked]
主题: Re: [netmod] New revision of YANG mount draft

Hi Juergen,

[Qin]: My interpretation to first two aspects are one is to define data model, the other is to manipulate data model. So yes they are both data model related.

[Qin]: Before support subscribing, have you considered how to discover remote datastore or remote node, or you assume this happens to be preconfigured.

---

From: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Thu, 16 Oct 2014 08:24:11 +0000

Hi Qin,

<Snap>

</Snap>

Discovery is different aspect from mount itself. There are different discovery protocols to identify network nodes or/and capabilities all together. 

Mount draft defines the "target" extension to identify the server in which datastore resides in section 5.1

"   o  The second extension, "target", serves as a substatement
      underneath a mountpoint statement.  It takes an argument that
      identifies the target system.  The argument is a reference to a
      data node that contains the information that is needed to identify
      and address a remote server, such as an IP address, a host name,
      or a URI [RFC3986]."

Br,
Ambika

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, October 16, 2014 1:43 PM
To: Alexander Clemm (alex); Juergen Schoenwaelder; Eric Voit (evoit)
Cc: [email-masked]
Subject: Re: [netmod] New revision of YANG mount draft

Hi,
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Alexander Clemm (alex)
发送时间: 2014年10月14日 8:52
收件人: Juergen Schoenwaelder; Eric Voit (evoit)
抄送: [email-masked]
主题: Re: [netmod] New revision of YANG mount draft

Hi Juergen,

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Oct 2014 08:27:20 -0700

On Tue, Oct 14, 2014 at 12:43 PM, Kent Watsen <[email-masked]> wrote:

>  EMS systems managing devices using NETCONF/YANG have been around for a
> few years.  It is pretty common for them to 1) provide a mechanism to get
> the YANG module used by a device and 2) a low-level API to get/set

Before debating the best way to re-architect NETCONF, it would help me to
understand
why the high level system doesn't just read the devices directly. What
problems does
this solve?  Is the controller like a cache, to offload monitoring overhead
from the devices?
Since the high-level system is using NETCONF either way, getting
the same data models either way, aware of the underlying devices either way,
it is not clear to me why the controller is needed for this purpose.

Andy

>> manage a "mount topology".  This addresses the system management aspects of
>> this concept, generally not of concern to the applications that want to
>> simply access the datastore, but required for a "complete" solution.
>> Again, this can be done as part of a YANG module, i.e. is data model
>> related.
>>
>> > Bringing in targeted nodes and subtrees need not require visibility
>> into the full submodule where the authoritative copy of the object might
>> reside.
>> >
>>
>> not allow to do X" which I think is not correct since YANG really is not
>> the issue. The mount work is extending/modifying/$(your-verb-here)