[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: action RPC I-D



Randy Presuhn wrote:
Hi -

From: "Andy Bierman" <ietf@andybierman.com>
To: "Randy Presuhn" <randy_presuhn@mindspring.com>
Cc: "'Netconf (E-mail)'" <netconf@ops.ietf.org>
Sent: Wednesday, November 01, 2006 8:44 AM
Subject: Re: action RPC I-D
...
If one knows a system's initial configuration, and has a sequence
of successful edit-config operations, is it possible to compute
the final configuration state (in order to support, for example, disaster recovery) without knowing the internals of the system
being configured?
Replay on the same box with the same conditions should produce
the same results.  Replay across arbitrary boxes from different
vendors?  It depends on the RPCs and the data models.

That's the question I'm asking.  Let me break it into some simpler
questions:

    1) if one successfully plays the same sequence of commands
        into two different boxes with the same starting configuration
        (not asking about whether the vendors are different, just whether
the boxes' configurations are identical) can one assume that the resulting configurations will be the same?

    2) is the result (in terms of how the system's configuration will change)
        of a successfully completed RPC deterministic?

    3) is the result (in terms of the changes to a system's configuration)
        of a successfully completed RPC predictable?

If the answer is "no" to any of these questions, then I think we're in
for a tough time explaining how this belongs in "configuration management",
and need to face up to what this protocol really is.


Seems like the quality of the RPC or data model definition
and documentation would determine how predictable the result
would be on any given system.  No different than SNMP here.
A bad MIB design does not prove that SNMP is broken either.

IMO, the RPC model allows complex high-level procedures to
be isolated and easily defined.  The SNMP "data-centric" approach
is to define a bunch of MIB tables which depend on each other,
and require possibly undocumented PDU sequences to set up
related rows in those tables, and then set a master RowStatus
object to 'active' to kick the whole thing off.  Often the PDU
sequences required (or permitted) by an agent vary greatly
across implementations.

The RPC approach allows the high-level operation to be modeled
directly and efficiently.


Randy


Andy

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>