On Fri, Aug 28, 2015 at 4:19 AM, Acee Lindem (acee) <[email protected]> wrote:
> Martin, Andy, > > On 8/28/15, 2:41 AM, "netmod on behalf of Martin Bjorklund" > <[email protected] on behalf of [email protected]> wrote: > > >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). > > Well, I guess you are recommending going down the same path as SNMP where > each vendor supported multiple virtual routers and instances differently. > IMO, this is undesirable. > > I did not say that. IMO NETCONF and RESTCONF could be extended to support identification of virtual servers. I would put the functionality in the protocol where it belongs. If it is the data model then it is inflexible and all virtualization (standard or not) is stuck with this design forever (e.g. uint8 == max 256 virtual server limit forever). Systems that do not have virtual servers should not be indexed as if they do. The localized cost is way too high, and as Martin pointed out, real systems do not work this way. Acee > Andy > > > > > > > > >> 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 > >[email protected] > >https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
