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