Martin Bjorklund <[email protected]> writes: > Andy Bierman <[email protected]> wrote: >> 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. > > +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).
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. > > >> 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 > > 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? 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 > > Ditto for the snmp container btw. > > > /martin > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
