Subject: [netmod] logical systems model

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2015 15:30:04 -0700

Hi,

I started a new subject line because the way logical vs. physical systems
are managed is a separate issue from the others.

   +--rw device
      +--rw logical-network-elements
         +--rw logical-network-element* [network-element-id]
            +--rw network-element-id                  uint8
            +--rw network-element-name?               string
            +--rw default-networking-instance-name?   string
            +--rw system-management
            |  +--rw device-view?             boolean
            |  +--rw syslog
            |  +--rw dns
            |  +--rw ntp
            |  +--rw statistics-collection
            |  +--rw ssh
            |  +--rw tacacs
            |  +--rw snmp
            |  +--rw netconf

I do not know of any systems where the logical view
is managed with an array entry like in this proposal.
Usually the protocol (or CLI command) picks one logical context
and the PDU is for that one logical system.  Each logical system
is self-contained so that the data models are written for
a single system.

Putting the multiplexing in the data model
adds a lot of extra complexity and protocol overhead for
systems that do not have virtual servers.

When it comes to converting this tree to CLI (since this
is a common practice) the "interfaces" command will become
"devices interfaces", "system" becomes "device system", etc.
I don't know of any CLIs that work this way.

The "nacm enable false" command will become

device logical-network-elements logical-network-element 1 \
system-management netconf nacm enable false

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Aug 2015 08:41:27 +0200 (CEST)

> systems that do not have virtual servers.

+1

I also believe that it is too limiting.  Some systems might do it this
way, but then there are others that have the concept of "virtual
system" that works differently.  For example, the virtual system might
give you your very own sandbox not just for the data model but also
for the underlying config data store.  There are essentially separate
instances of a NETCONF server running (or other protocol).

> system-management netconf nacm enable false

And this would be a weird place for NACM.  Would there be another NACM
for logical-network-element 2?  They would share the same root, so are
rules somehow merged?

Ditto for the snmp container btw.

/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 28 Aug 2015 11:19:49 +0000

Martin, Andy, 

>instances of a NETCONF server running (or other protocol).

Well, I guess you are recommending going down the same path as SNMP where
each vendor supported multiple virtual routers and instances differently.
IMO, this is undesirable.

Acee 

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Aug 2015 13:30:56 +0200

> instances of a NETCONF server running (or other protocol).

Whilst most commercial systems might currently work this way, I can
easily imagine use cases where a single agent manages multiple virtual
devices. An example that comes to my mind is a network simulation using
tools like mininet.

In general, for light-weight virtualisation methods such as Linux
containers, managing each virtual instance separately would mean a
significant overhead.

> for logical-network-element 2?  They would share the same root, so are

NACM, as well as all other modules we have, is based on the assumption
of a single managed device.

I think it is a typical trend that what once was a single instance
becomes an array. If we did ietf-routing 20 years ago, there would
probably be no routing-instance list.

So I think it is a real problem that we can't migrate from a container
to a list and reuse the container's data model. Groupings might help
somewhat but they are still not fully reusable, if, for example, they
contain absolute references.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Aug 2015 07:08:05 -0700

> IMO, this is undesirable.
I did not say that.
IMO NETCONF and RESTCONF could be extended to support identification
of virtual servers.  I would put the functionality in the protocol where it
belongs.
If it is the data model then it is inflexible and all virtualization
(standard or not)
is stuck with this design forever (e.g. uint8 == max 256 virtual server
limit forever).

Systems that do not have virtual servers should not be indexed as if they
do.
The localized cost is way too high, and as Martin pointed out, real systems
do not work this way.

Acee

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 28 Aug 2015 18:31:36 +0000

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Friday, August 28, 2015 4:31 AM
To: Martin Bjorklund <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] logical systems model

.....
<snip>

NACM, as well as all other modules we have, is based on the assumption of a single managed device.

I think it is a typical trend that what once was a single instance becomes an array. If we did ietf-routing 20 years ago, there would probably be no routing-instance list.

So I think it is a real problem that we can't migrate from a container to a list and reuse the container's data model. Groupings might help somewhat but they are still not fully reusable, if, for example, they contain absolute references.

Lada
</snip>

One comment, if you forgive the pitch, but this problem / use case is by the way exactly one of the reasons for mounting, which allows you to introduce and impose an additional structure on top of an existing structure, and "insert" the existing structure into it.  Augmentations etc can only add below the hierarchy, there is no way we can put a new container or list or whatever on top of an existing structure (without replicating the existing structure in a duplicate model), but peer-mount lets you do that.  One use case used in Open Daylight involves organizing/ inserting device-level information into a network inventory, which is basically imposed "on top".

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Aug 2015 12:53:01 -0700

On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) <[email-masked]>
wrote:

> I think it is a typical trend that what once was a single instance becomes
> an array. If we did ietf-routing 20 years ago, there would probably be no
> routing-instance list.
>
> So I think it is a real problem that we can't migrate from a container to
> a list and reuse the container's data model. Groupings might help somewhat
> but they are still not fully reusable, if, for example, they contain
> absolute references.
>
> Lada
> </snip>
>
> One comment, if you forgive the pitch, but this problem / use case is by
> the way exactly one of the reasons for mounting, which allows you to
> introduce and impose an additional structure on top of an existing
> structure, and "insert" the existing structure into it.  Augmentations etc
> can only add below the hierarchy, there is no way we can put a new
> container or list or whatever on top of an existing structure (without
> replicating the existing structure in a duplicate model), but peer-mount
> lets you do that.  One use case used in Open Daylight involves organizing/
> inserting device-level information into a network inventory, which is
> basically imposed "on top".
>
>

I thing YANG Mount would be the best way to solve this problem.
It provides a standard way to do "chroot" and it is flexible.
The mechanics of a "datastore within a datastore" are the
same and independent of the source of the data (local,
remote, virtual, etc.)

Andy

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Aug 2015 16:31:49 -0400

> same and independent of the source of the data (local,

So I think an example of how you see this working would helpful.

Can one of you give an example of how this word work for a device (which 
may be physical or virtual) that allocates done resources, say interfaces 
to one logical entity (router, system, etc) and other resources to a second 
entity? And of course I want to manage all with yang and the first and 
second (sub) entity must be completely independent and ignorant of each other.

Thanks,
Lou
> ----------

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Aug 2015 14:33:14 -0700

On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger <[email-masked]> wrote:

> > On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) <[email-masked]
> >
> > wrote:
> >
> >>
> >>
> becomes
> to

Is there an example of this in your draft?

Do you mean an example of what the controller looks like?
Maybe the analogy to chroot is not  universally understood.

The logical system knows only about itself:

    /interfaces
    /system

The / node is represented by <config> or <data> or <filter> in the protocol.

   <get-config>
       <source><running/></source>
       <filter>
         <interfaces />
         <system />
      </filter>
   </getconfig>

Each logical system can have its own "eth0" interface or whatever.
They are mapped to real interfaces in the physical system.

All operations on the logical system are validated against its own
virtual datastore.  YANG validation does not work on individual array
slices -- it only applies to an entire datastore.

On the physical server there needs to be a data model to manage the
logical servers (as Martin suggested).

 <config>             <--- root on PHY server
   <interfaces  />   <--------------- contains the real interfaces,
including eth23
   <virtual-servers>
      <virtual-server>
         <name>vs1</name>
         <itf-map>
             <real-itf>eth23</real-itf>
             <vir-itf>eth0</vir-itf>
         <itf-map>
         <more-virtual-server-params ... />
         <root>                   <----------- YANG mount point (virtual
server root)
            <interfaces>
               <interface>
                  <name>eth0</name>
                    ...
               </interface>
            </interfaces>
            <system ... />
         </root>
       </virtual-server>
    </virtual-servers>
  </config>

On the physical system, the virtual roots are within list entries,
not at the top of the tree.  The physical server data and/or any
of the logical servers can be accessed at once.

There is no extra indexing cost.  The same data model (e.g ietf-interfaces)
can be used in physical and virtual server.  YANG Mount provides a lot
more than simply identifying /virtual-servers/virtual-server/root
as the start of an embedded datastore.  As Alex said, not all of it
needs to be standardized at once.

Th "virtual-servers" node is not under each <root> because only
the physical server loads and supports that module.

Thanks,

Andy

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 28 Aug 2015 22:16:45 +0000

Hi Lou,

Andy basically already provided the answer, but just to add to your question: yes, there is an example in the draft (appendix A).

RFC 7223 provides a YANG model for interfaces.  It defines a hierarchy that includes the following:
      +--ro interfaces-state
         +--ro interface* [name]
            +--ro name               string
            +--ro type               identityref
            +--ro admin-status       enumeration
            +--ro oper-status        enumeration
            +--ro last-change?       yang:date-and-time

The example refers to a controller (e.g. ODL) and the model that it exposes to its applications.  (This is also what Robert was referring to earlier.)  This model is supposed to include a network inventory, which includes a list of the various devices/systems/nodes controlled by the controller, and shall include for each of those devices information regarding its interfaces.  In other words, the controller wants to impose an additional level (or two) on top of the hierarchy of the individual devices, namely something of the sort

   +-- rw network-elements

       +-- rw network-element [element-id]

And then have visibility of the interfaces below the network devices.

In this case, you could define put an “interface-stats” mountpoint below network element, and point it to interfaces-state, to result in the following

   +-- rw network-elements

       +-- rw network-element [element-id]
          +--M interfaces-state
              +--ro interface* [name]
                 +--ro name               string
                 +--ro type               identityref
                 +--ro admin-status       enumeration
                 +--ro oper-status        enumeration
                 +--ro last-change?       yang:date-and-time

--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Friday, August 28, 2015 2:33 PM
To: Lou Berger <[email-masked]>
Cc: Alexander Clemm (alex) <[email-masked]>; [email-masked]
Subject: Re: [netmod] logical systems model

On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:

On August 28, 2015 3:53:33 PM Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

> On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex) <[email-masked]<mailto:[email-masked]>>
> wrote:
>
>>
>>
>> From: netmod [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ladislav Lhotka
>> To: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>> Cc: [email-masked]<mailto:[email-masked]>

Can one of you give an example of how this word work for a device (which may be physical or virtual) that allocates done resources, say interfaces to one logical entity (router, system, etc) and other resources to a second entity? And of course I want to manage all with yang and the first and second (sub) entity must be completely independent and ignorant of each other.

    /interfaces
    /system

   <get-config>

 <config>             <--- root on PHY server
   <interfaces  />   <--------------- contains the real interfaces, including eth23
   <virtual-servers>
      <virtual-server>
         <name>vs1</name>
         <itf-map>
             <real-itf>eth23</real-itf>
             <vir-itf>eth0</vir-itf>
         <itf-map>
         <more-virtual-server-params ... />
         <root>                   <----------- YANG mount point (virtual server root)
            <interfaces>
               <interface>
                  <name>eth0</name>
                    ...
               </interface>
            </interfaces>
            <system ... />
         </root>
       </virtual-server>
    </virtual-servers>
  </config>

Thanks,
Lou

Andy

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