Andy Bierman <a...@yumaworks.com> 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). > 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? Ditto for the snmp container btw. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
