On August 28, 2015 5:33:41 PM Andy Bierman <[email protected]> wrote:
> 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? > Sure, this is what logical-network-element and device view is all about and the example is actually in the slides from the last ietf that I pointed to a couple of weeks ago. > Do you mean an example of what the controller looks like? No, the server/device. > 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. > It's the control of this mapping that is part of the question. .. BTW this "physical " system may itself be a virtual device (e.g., VM w/ NFV) . .. > 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. Okay, so our logical-network-element is basically your virtual-server.root Think this is an interesting approach that is worth looking at to address the logical-network-element (virtual router/chassis/fabric/<vendor-specific-name>) problem. I like that it can go n-levels deep as it is basically recursive. The challenge will be dealing with mapping for every top level module that will need it, e.g., hardware, QoS. The only major restriction / change from what we are proposing is that we can allow multiple LNEs to manage one system. I'm suspect loosing this would be a big deal. I'll discuss with the DT. > > 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. Sure, but local mounting case does. Lou > > 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
