Hi Simon,
On Tue, 19 Jun 2007, Simon Leinen wrote:
<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.
That's the Quagga model too, at present.
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>
That sounds good too.
I don't have a preference myself, but I know we lack any easy way to do
the latter.
<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>
Reducing error (several classes of) is a major motivation for cleaning
this up.
<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>
No, it's very interesting. I've actually been trying to dig up
non-proprietary router-config schema to look at, this will be very
useful.
<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 />
I doubt time allows for a complete NETCONF implementation, however
whatever is done will bear NETCONF in mind so far as possible. (A goal
here is to make it easier to implement user-interaction tools/agents,
like possibly NETCONF, /outside/ of system-critical daemons).
I'm mulling over the direction to go with design at the moment, will let
you know when I know more ;).
regards,
--
Paul Jakma,
Solaris Networking Sun Microsystems, Scotland
http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150
_______________________________________________
networking-discuss mailing list
[email protected]
