I agree that <special-set> RPCs are needed to help reduce complexity
of SET functionality.
I also think we need to understand how to standardize <set> and <get>
functionality for interoperability across vendors.
-- data versus functions --
I have commented in the past about the comparison of NM approaches to
programming languages.
SNMP uses the peek/poke approach of an assembly language, a 2nd
generation programming language.
The CLI is the equivalent of a 3rd generation language, such as
Fortran, Cobol, C, or Pascal. It is function-oriented. This is much
more "natural" for a human being to use, as it is task oriented. An
important feature of later functional languages is the concept of
variable scope. Functions may touch any data anywhere in the
application space, and this can cause bugs when one function's code
modifies a variable that another function expects to remain constant
(or at least not to change in a "volatile" manner). To constrain the
side-effects of modifying variables, langauges like C introduced the
concepts of function-scope (local variables) and file scope
(structures only modifiable by functions in the same file that defines
the structures).
Object-oriented, the fourth generation of langauges, takes it a step
further by having data that is specific to an object that is only
modifiable by the fucntions (methods) of the object. In this way, the
data definition is unknown except internally. Objects in an O-O
environment also are derivable from base classes, promoting
hierarchical reuse.
I stopped following the evolution of programming languages at fourth
generation, but I think the fifth generation is the use of remote
procedure calls and the existence of "objects" callable across the
network. This requires the ability to build components that are
largely self-sufficient and have a "public" interface to manipulate
its private data (an extension of the data hiding from 3rdgen scope
and 4thgen "data hiding").
Why am I suddenly giving lessons in programming langauges? Because we
need to decide where on the continuum netconf should fit, and much of
that decision will have to do with the incompatibility of standard
data models and global functions such as the <get-config> RPC, and the
concepts of data hiding.
-- iteration and an object-oriented hierarchy --
I have programmed in C++ for years, working on a NMS application that
used object-oriented design for modeling the network. Each device
model had public methods and hidden data. One of the toughest problems
we ran into was "searching the network" for specific data, because it
required having a search routine for every object, and a search
routine that iterated through every object in the hierarchy.
Of course, we could derive objects from a base class that has a search
method that could iterately call the search method for all derived
classes. Derivation is hard to work with, and an object hierarchy is
hard to get right in a manner that works for multiple "world-views";
how one models the hierarchy depends a lot on what you are trying to
achieve.
To do <get-config>, we will probably need to define a <get-config> RPC
for every object you plan to use to modularize the hierarchy (I assume
a capability might represent the definition of an object), and we will
a consistent varbind format to report the object's data, and roll the
data up into a complete picture of the configuration. And ideally, the
"varbind" format will not place any restrictions on
implementation-specific decisions of data modeling within the
"object".
Assuming the "objects" will exist in some type of hierarchy, it will
probably be necessary to define a mechanism for "rolling up" the data
through the hierarchy. For instance, calling the <get-config> for a
chassis might cause the chassis code to iterate through <get-config>
for each blade in the chassis, and combine these subordinate configs
with the chassis's own config information. And because you don't want
each blade's <get-config> trgggered by the chassis AND by a direct
iterative <get-config>, we will need to make some provision for
recognizing when a complete subtree has been queried by the
<get-config> command. Mayeb Xpath already solves this iteration
problem.
-- sets versus gets --
<special-set> RPCs are needed to help reduce complexity of SET
functionality. But what about <special-get> RPCs?
I suggest we consider a system that uses only <special-set> functions
for SET functionality, and uses both global <get-*> and <special-get>
RPCs.
<special-sets> can make the functionality addressable in a
standardized manner, make modification of data "gumballs" predictable,
and make the details implementation-specific to a large degree
(support data hiding and proprietary schema pieces). I expect we will
want to standardize portions of a <set> data model into a standard
schema, and allow this to be supplemented with vendor-specific
parameters in one or more supplemental schemas.
The <get-*> and <special-get> operations should have a standard
reporting format to improve interoperability, and to promote the
development of standard data models for monitoring and cross-vendor
comparison capabiltities. Failure to impose some standards on the
format of the returned values leads to the problem faced today by
operators trying to use expect scripts to parse through inconsistent
and constantly changing proprietary CLI data models. XML will help,
but will fall short if each vendor uses different schemas for the same
functionality.
One area this WG has not discussed is how to do access control. This
has been pushed off as data-model-dependent. But if the interface to
functinoality will be functions rather than peek/poke, then access
control should probably be applied to each function, not to the
underlying gumballs of data that might get modified.
It is possible that two types of access control will be required -
read access might be best modeled as data-hierarchy-centric, while
write access might be best modeled as function-centric. Of course, if
we bundle data and functions into objects, and the hierarchy is at the
object level, then access control could be object-centric, and we
would avoid the overkill of per-variable access control.
P.s. it might be worthwhile looking at the <*-config> commands as
being an object as well, and the <get-config> and <edit-config>
commands are methods specific to managing the functionality of a
"running config" object.
David Harrington
dharrington@huawei.com dbharrington@comcast.net
ietfdbh@comcast.net
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
On Behalf Of Andy Bierman
Sent: Tuesday, September 12, 2006 11:19 AM
To: Netconf (E-mail); Netconf Data Model Discussion
Subject: Why Phil is right about <special-set> vs. <edit-config>
Hi,
First, I am not going to say we need to stop using <edit-config>.
I just going to point out a critical SNMP problem the XMLCONF design
team really wanted to fix -- but didn't.
The root problem in NE management today is the relative expense
and difficulty in adding new agent functionality into NE devices.
SNMP Set failed for 3 reasons:
1) Casting high-level procedures as a "100 bits of peek/poke data"
is an Unnatural Act that never had a chance of succeeding.
2) One generic "edit" PDU that can contain an arbitrary mix
of arbitrarily incomplete high-level operations (i.e. varbinds),
dispensed like gumballs, across an arbitrary number of Set PDUs.
3) In accordance with the Postel Principle, the agent needs to code
for complex (legal) Set PDUs the manager should never ever use.
NETCONF has better error reporting then SNMP, but the complexity
of implementing <edit-config> in an optimal manner is non-trivial.
In contrast, none of the arbitrary mix-and-match "Gumball API" problems
exist with <special-set> RPCs. The agent automation complexity is
dramatically lower than for <edit-config>. Agent callback chains
can handle hard problems like resource reservation and rollback
much easier as well.
The <special-set> approach is much better for managers,
because an "object-oriented API" can easily be mapped to
services or classes, and the set of methods defined for them.
The "fly in the ointment" is the startup config file
(e.g., show running config). This data-centric view
of the configuration state is heavily used, and not going
away any time soon. The trick is finding the right mix
of heuristics, mappings, and special RPCs, so both views
of the NE device can be easily supported.
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/>
--
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/>