<p> Nice document. A few remarks: </p> <p> The router vendors mentioned (Cisco and Juniper) have different models to manipulate configurations. With Cisco, most commands in configuration mode instantly modify the "running configuration". To become stable across a reboot, you must explicitly write the running configuration to NVRAM. With Juniper, configuration changes are first made to a scratch area, and then atomically committed with an explicit "commit" command. I believe that committing also makeks the new configuration stable. I think both vendors have added additional version management features over time, so that you can revert to earlier configurations, compare two versions, etc. </p>
<p> Some vendors have an internal schema for their configuration, and from that schema they automatically generate both the "CLI" configuration parser/unparser and the XML-based NETCONF agent. I think this is useful because (1) it reduces the parsing errors that plague other vendors where the CLI parser is mostly hard-coded, and (2) it ensures that CLI configuration language and NETCONF schema are feature-compatible. </p> <p> (Note that folks from INRIA have <a href="http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fhal.inria.fr%2Finria-00000803%2Fen%2F&ei=dkp4Rq-ZI4KgnQOM8dStDg&usg=AFQjCNFCJ0QVdnCnvbbzz1pF5Na95boOQQ&sig2=jLTgC6X18bDC7e6gtn3AmQ";>implemented a NETCONF agent for Quagga's BGP router.</a> This implementation is probably not helpful for your work, since it just wraps the CLI.) </p> <p> If you decide to go down the NETCONF route, consider joining the mailing list and share your implementation experiences. You will also find quite a few helpful fellow implementors there to answer your questions. <br /> -- <br /> Simon.<br /> IETF NETCONF WG co-chair</p> This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
