Subject: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 15 Sep 2015 15:21:10 +0000

There was a recent thread on structuring YANG models so that application developers might be able to reference alternative local hierarchies/tree structures for certain objects.  This thread motivated Alex, Sander, and I to rework the YANG Mount requirements draft.  v03 is posted at:
http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/

This draft has been retitled to "Requirements for mounting of local and remote YANG subtrees".  This retitling was done because we have separated the thinking on what it takes to Mount objects from remote devices (Peer Mount) from what it takes to Mount within the same device (Alias Mount).

We would be interested in your thoughts.   

Eric

-----Original Message-----
From: Ladislav Lhotka, August 31, 2015 11:05 AM

Randy Presuhn <[email-masked]> writes:

> Hi -
>
> It is with no little amusement that I watch this thread struggling 
> with questions that were solved fairly neatly a quarter century ago in 
> GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would like 
> to offer an observation about modeling that might help.
>
> The organization of instance data in SNMP is a direct mirror of the 
> "object" definitions.  Simple at first, but quickly becoming baroque 
> as various minds of "multiplexing" are added to compensate for post 
> hoc deficiencies in the index structures.
>
> Life is such that once a resource has been modeled, it will be 
> used/re-used/embedded in systems in ways in which its designers 
> couldn't be expected to imagine.  A consequence of this is that if 
> instance naming is completely locked down when the management 
> interface for a resource is first defined (as it is in SNMP) then all 
> sorts of peculiar hacks will be needed to deal with, for example, 
> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so 
> pervasive that folks seem to overlook that there are other ways to 
> deal with this situation.
>
> What GDMO did was to use a separate "NAME BINDING" construct to 
> specify contexts in which instances might show up, allowing instances 
> to be put in places that weren't even imagined when the original class 
> definition was written.  Name bindings could be standardized, or be 
> vendor or even product-specific, allowing the simplicity or complexity 
> of a given system's instance tree to reflect the actual simplicity or 
> complexity of that system, rather than requiring all systems to be 
> structured for the worst case.

How could this be expressed in YANG terms? (I tried to figure it out myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recommendation X.722).

Thanks, Lada

>
> Yes, separating the specification of instance naming in large part 
> from class definition does have implications for how one does access 
> control, and how clients figure out how to ask a server to create 
> something, but it's not a huge deal - it's just not like VACM, and a 
> whole slew of hacky solutions and "wierd plumbing adapters" (to borrow 
> from Jeff Case) just go away.  Strangely, it makes the job of the 
> initial modeler and of the eventual user much easier.
>
> Randy
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Sep 2015 11:21:43 -0700

Hi,

I think the NETCONF WG really needs to think about the architecture
it is creating, and the role of proxy servers in network management.

When we were designing NETCONF (pre-4741) we were told by
knowledgeable operators like Randy Bush that NETCONF MUST NOT
have any Proxy-based management, because it added too much complexity.

   To date systems built upon YANG models have been missing two
   capabilities:

   1.  YANG Datastore Mount: Datastores have not been able to proxy
       objects located elsewhere on the same device, or upon a different
       device.  This puts additional burden upon applications which then
       need to find and access multiple locations and which may be on
       remote systems.

   2.  Eventual Consistency: YANG Datastore implementations have
       typically assumed ACID [1] transaction models.  There is nothing
       inherent in YANG itself which demands ACID transactional
       guarantees.  YANG models can also expose information which might
       be in the process of undergoing convergence.  Since IP networking
       has been designed with convergence in mind, this is a useful
       capability since some types of applications must participate
       where there is dynamically changing state.

The NETCONF WG should decide first "we need proxy servers" before debating
the best way to do that.

We have been told there are systems that converge very slowly (although
nobody seems
to know if that means 5 minutes of 5 hours).  All the "get-actual" type of
proposals
seem to address this issue.  Not sure how YANG Mount addresses the issue,
and how it is related to the other solution proposals.

Andy

On Tue, Sep 15, 2015 at 8:21 AM, Eric Voit (evoit) <[email-masked]> wrote:

> There was a recent thread on structuring YANG models so that application
> developers might be able to reference alternative local hierarchies/tree
> structures for certain objects.  This thread motivated Alex, Sander, and I
> to rework the YANG Mount requirements draft.  v03 is posted at:
> This draft has been retitled to "Requirements for mounting of local and
> remote YANG subtrees".  This retitling was done because we have separated
> the thinking on what it takes to Mount objects from remote devices (Peer
> Mount) from what it takes to Mount within the same device (Alias Mount).
>
> How could this be expressed in YANG terms? (I tried to figure it out
> myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT
> Recommendation X.722).
>
> Thanks, Lada
>
> >

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 17 Sep 2015 19:30:43 +0000

Thanks for your thoughts Andy.  I believe the complexities of proxy can be outweighed by the benefits of simplifying life for the application developer in two scenarios:

(1)    Alias Mount: when there are multiple or context specific exposures of the same object.
Note: I was attempting to capture some of the idea you were referring to at the end of your “Y34 - root node” post: http://www.ietf.org/mail-archive/web/netmod/current/msg13260.html    It is useful when an application developer doesn’t have to hunt down through dozens of models/trees for the few objects they care about.

(2)    Peer Mount: when applications need a local representation of objects sitting on a remote device.
Note: I know this is more controversial.  But a the Google search of "Mount" on site = opendaylight.org gives over 1000 hits relating to YANG, Netconf, and Restconf.  Some are finding it useful.

I agree that the WG needs to decide whether we want to take on some or all of this topic.

Eric

From: Andy Bierman, September 17, 2015 2:22 PM

Hi,

   capabilities:

       remote systems.

We have been told there are systems that converge very slowly (although nobody seems
to know if that means 5 minutes of 5 hours).  All the "get-actual" type of proposals
seem to address this issue.  Not sure how YANG Mount addresses the issue,
and how it is related to the other solution proposals.

Andy

On Tue, Sep 15, 2015 at 8:21 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:
There was a recent thread on structuring YANG models so that application developers might be able to reference alternative local hierarchies/tree structures for certain objects.  This thread motivated Alex, Sander, and I to rework the YANG Mount requirements draft.  v03 is posted at:
http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/

Eric

-----Original Message-----

Thanks, Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Sep 2015 12:48:06 -0700

On Thu, Sep 17, 2015 at 12:30 PM, Eric Voit (evoit) <[email-masked]> wrote:

> Thanks for your thoughts Andy.  I believe the complexities of proxy can be
> outweighed by the benefits of simplifying life for the application
> developer in two scenarios:
>
>
>
> Note: I was attempting to capture *some* of the idea you were referring
> to at the end of your “Y34 - root node” post:
> http://www.ietf.org/mail-archive/web/netmod/current/msg13260.html    It
> is useful when an application developer doesn’t have to hunt down through
> dozens of models/trees for the few objects they care about.
>
>
>
> Note: I know this is more controversial.  But a the Google search of
> "Mount" on site = opendaylight.org gives over 1000 hits relating to YANG,
> Netconf, and Restconf.  Some are finding it useful.
>
>
>

The landscape has changed a lot since the RFC 3535 timeframe,
in which the only proxy was really SNMP Proxy.

Once we start talking about standardizing the controller layer,
it isn't really proxy anymore (in the same sense we thought about it in the
90s).
I look at YANG Mount, pub/sub, etc. together as a "configurable push model".
This could be a much better design than hard-coded polling.   It is the
kind of
feature we would expect to see, moving from a proprietary controller to
a standardized controller.

Eric

Andy

>
>
> *From:* Andy Bierman, September 17, 2015 2:22 PM
>
> Hi,
>
>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Sep 2015 10:34:07 +0200

Hi Eric,

we are dealing with two rather different problems:

1. A pull-type method for combining YANG schemas as a complement to
   "augment".

2. A proxy function that mediates access to data that are located
   elsewhere.

I believe the recent thread on structuring YANG models has been about #1
while both this draft and draft-clemm-netmod-mount-03 mainly address
#2. Each problem has its share of issues to solve but the issues don't
overlap, so I believe it would be useful to keep both problems
separate.

Lada

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 22 Sep 2015 17:59:00 +0000

Hi Lada,

Thanks for your feedback.   I do think that there is value in an integrated technology solution.   OpenDaylight combines (1) and (2) usefully.  For example there are examples on the page:
http://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf
such as:
http://localhost:8080/restconf/operations/network-topology:network-topology/topology/topology-netconf/node/<nodeId>/yang-ext:mount/<operation> 
which enables a server to reference remote device info embedded within a network-topology url

Beyond that, OpenDaylight has the ability to do (1) in the form of " loopback mount".  See:
http://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:Tutorials:Netconf_Mount#Testing_against_ODL_itself_.28MD-SAL_netconf_northbound_loopback_mount.29
While this is used mostly for testing, aliasing is also viable.

Eric

-----Original Message-----
From: Ladislav Lhotka, September 21, 2015 4:34 AM

Hi Eric,

I believe the recent thread on structuring YANG models has been about #1 while both this draft and draft-clemm-netmod-mount-03 mainly address #2. Each problem has its share of issues to solve but the issues don't overlap, so I believe it would be useful to keep both problems separate.

Lada

"Eric Voit (evoit)" <[email-masked]> writes:

>> with questions that were solved fairly neatly a quarter century ago 
>> in GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would 
>> like to offer an observation about modeling that might help.
>>
>> to be put in places that weren't even imagined when the original 
>> class definition was written.  Name bindings could be standardized, 
>> or be vendor or even product-specific, allowing the simplicity or 
>> complexity of a given system's instance tree to reflect the actual 
>> simplicity or complexity of that system, rather than requiring all 
>> systems to be structured for the worst case.
>
>> whole slew of hacky solutions and "wierd plumbing adapters" (to 
>> borrow from Jeff Case) just go away.  Strangely, it makes the job of 
>> the initial modeler and of the eventual user much easier.
>>
>> Randy
>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 22 Sep 2015 18:08:57 +0000

Hi Eric, Lada, 

I agree with Eric that the mount requirements should include both use
cases. We have been discussing this mechanism as potentially providing
support for meta model components that may or not be present in a network
device. 

Thanks,
Acee

On 9/22/15, 1:59 PM, "netmod on behalf of Eric Voit (evoit)"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi Lada,
>
>Thanks for your feedback.   I do think that there is value in an
>integrated technology solution.   OpenDaylight combines (1) and (2)
>usefully.  For example there are examples on the page:
>http://localhost:8080/restconf/operations/network-topology:network-topolog
>y/topology/topology-netconf/node/<nodeId>/yang-ext:mount/<operation>
>http://wiki.opendaylight.org/view/Controller_Core_Functionality_Tutorials:
>Tutorials:Netconf_Mount#Testing_against_ODL_itself_.28MD-SAL_netconf_north
>bound_loopback_mount.29
>while both this draft and draft-clemm-netmod-mount-03 mainly address #2.
>Each problem has its share of issues to solve but the issues don't
>overlap, so I believe it would be useful to keep both problems separate.
>
>Lada
>
>> There was a recent thread on structuring YANG models so that
>>application developers might be able to reference alternative local
>>hierarchies/tree structures for certain objects.  This thread motivated
>>Alex, Sander, and I to rework the YANG Mount requirements draft.  v03 is
>>posted at:
>>remote YANG subtrees".  This retitling was done because we have
>>separated the thinking on what it takes to Mount objects from remote
>>devices (Peer Mount) from what it takes to Mount within the same device
>>(Alias Mount).
>>