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 protected]]
Sent: Friday, August 28, 2015 2:33 PM
To: Lou Berger <[email protected]>
Cc: Alexander Clemm (alex) <[email protected]>; [email protected]
Subject: Re: [netmod] logical systems model
On Fri, Aug 28, 2015 at 1:31 PM, Lou Berger
<[email protected]<mailto:[email protected]>> wrote:
On August 28, 2015 3:53:33 PM Andy Bierman
<[email protected]<mailto:[email protected]>> wrote:
> On Fri, Aug 28, 2015 at 11:31 AM, Alexander Clemm (alex)
> <[email protected]<mailto:[email protected]>>
> wrote:
>
>>
>>
>> -----Original Message-----
>> From: netmod
>> [mailto:[email protected]<mailto:[email protected]>] On Behalf
>> Of Ladislav Lhotka
>> Sent: Friday, August 28, 2015 4:31 AM
>> To: Martin Bjorklund <[email protected]<mailto:[email protected]>>;
>> [email protected]<mailto:[email protected]>
>> Cc: [email protected]<mailto:[email protected]>
>> 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".
>>
>>
>
> 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.)
>
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.
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,
Lou
>
Andy
> Andy
>
>
>
> ----------
> _______________________________________________
> netmod mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
