Hello,
-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: Friday, March 26, 2004 4:48 PM
To: Gagnon, Gilbert [CAR:NM10:EXCH]
Cc: Waters, Glenn [CAR:IO47:EXCH]; j.schoenwaelder@iu-bremen.de; netconf@ops.ietf.org
Subject: RE: same value operation attributes restriction
At 03:52 PM 3/25/2004, Gilbert Gagnon wrote:
I think you are missing some of the points I am trying to make.
GG: I was not addressing your comments in specific but the discussions in general.
1) Data model designers do not get to define their own set
of operations. They specify exactly how the standard
set of 5 operations applies to their data model. Big difference.
GG: Good, As I questioned, NetConf will therefore define (in only in parts or at
the meta level) the structure of the data-model. I was getting the impression
from the overall tone of the discussions that some people did not want
NetConf to control that. Without specification, there will be little
interoperability (and the more at the meta level the more complex it will be).
2) Application programmers are not forced to use multiple
operation attributes within a single edit-config PDU.
GG: But if the vast majority of use will be to use one operation at a time
(I'm not saying it will, I'm just raising the possibility) then
we're making things more complex than they ought to be.
3) It is quite easy to come up with use cases for using different
operation attribute values within the edit-config PDU,
especially if the rollback-on-error error-option is used.
GG: I agree that the multiple operations model is a forced working around
a rollback-on-error model (i.e. If each "PDU" maps to a single transaction,
you have no choice but to make that transaction do all that needs to be done).
If the device does not have that semantic, I doubt I would use that.
4) For devices that allow writes to the running config, the
operation sequence matters because the running config is
not an abstract datastore. Network behavior is affected
immediately, so N sequential edit-config PDUs does
not necessarily yield the exact same results as 1 edit-config
PDU that combines the changes embodied in N operations.
GG: No arguments. I was never advocating that this model was bad. Only that if it
is to be supported, NetConf should define how it is encoded (or one should
figure out how it should be encoded though I'm affraid this latter option
is somewhat too fancy).
5) The application code is less complicated if multiple operation
attribute values are permitted:
GG: The complexity shift in your example is brought by the specific
case of the transaction-per-PDU model. The resolution of the complexity is
not in the NetConf encoding, it is in the device's handling of the
transaction model. If the device does not support rollback-on-error
nor multi-PDU transactions, then the user must figure out the undo whatever
the encoding (though it's probably harder to know what to undo in the
mixed-operation model as it is not clear up to where the encoded data-structure
was processed without analyzing the rpc-error blocks -- which might not be
as simple as it seems). In anycase, my argument about the
complexity was not about the model but about the encoding. It was not about
how the commands are sent but how the commands are encoded.
I never argued against the mixed-operation model but only that NetConf
must define how it is to be encoded if it is going to be supported.
I'm just saying that I believe an operation-dominant encoding is simpler to use
mechanically than one that sprinkles operations all over a data-structure.
action data...
action data...
is more straight forward than
data
data (action)
data
data (action)
data
data (action)...
If one has to adopt a data-dominant encoding, I bet they will prefer to
just re-encode the whole component in one shot rather than try encode
a data structure that contains both new data (the added and set stuff) and
old data (the stuff to be deleted) [that's the traditional FTP model].
The transaction-per-PDU model could be supported in a operation-dominant
encoding simply by listing the individual operations to be performed
within one PDU (e.g. edit-config as a list of add/delete/set elements with
the target data structure as sub-element to each).
Functionaly, this is the same as the data-dominant encoding
in the sense that it produces the same results but it is much simpler to produce
mechanically. In that sense, If NetConf is going to specify how the
operations are encoded, I sure hope is will be with an action-dominant model.
Thanks
A) 3 operations in 1 PDU, using operation attribute:
M = create_msg(target=running, error-option=rollback-on-error,
<config>
<foo operation="create"> .... </foo>
<goo operation="replace"> .... </goo>
<boo operation="modify"> .... </boo>
</config);
err = send_rpc(M, IP-host-X);
if (err != NO_ERR)
cleanup and exit;
B) 1 operation in each of 3 PDUs, using explicit message type
for each of the operation types:
M1 = create_msg(op=create, target=running,
error-option=rollback-on-error,
<config>
<foo> .... </foo>
</config);
err = send_rpc(M1, IP-host-X);
if (err != NO_ERR)
cleanup and exit;
M2 = create_msg(op=replace, target=running,
error-option=rollback-on-error,
<config>
<goo> .... </goo>
</config);
err = send_rpc(M2, IP-host-X);
if (err != NO_ERR) {
first, figure out how to manually undo M1;
this probably requires that the state of <foo> before M1
must be saved;
create_msg(undo-M1, ...)
err = send_rpc(undo-M1, ...)
cleanup and exit;
}
M3 = create_msg(op=modify, target=running,
error-option=rollback-on-error,
<config>
<boo> .... </boo>
</config);
err = send_rpc(M3, IP-host-X);
if (err != NO_ERR) {
first, figure out how to manually undo M1;
this probably requires that the state of <foo> before M1
must be saved;
create_msg(undo-M1, ...)
err = send_rpc(undo-M1, ...)
if (err != NO_ERR)
you're hosed; figure out how to recover
then, figure out how to manually undo M2;
this probably requires that the state of <goo> before M2
must be saved;
create_msg(undo-M2, ...)
err = send_rpc(undo-M2, ...)
if (err != NO_ERR)
you're hosed; figure out how to recover
cleanup and exit;
}
I don't understand how approach B could ever be considered easier to use, easier to understand, or less disruptive to the network behavior than approach A.
Note that approach A is not the same as compound operations because all the parameters are shared and therefore must be the same, and only the edit-config PDU is allowed to appear in the RPC. Compound operations could have different parameter values or even different operations (e.g., lock, get-config, validate) within the same RPC.
Andy
>Hello,
>
>Just a few remote comments on where this discussions seems to be
>going...
>It seems that NetConf is sliping into something less than was originally
>intended (as much as I could deduce the intent from the RFC).
>If we defer every operation decision to the "data model"
>(the payload of the NetConf messages) then what is the value of NetConf then?
>Doesn't it just become yet another "generic" RPC protocol? What benefits would
>it then offer over other RPC/envelope techniques like SOAP?...
>It seems to me that one of the benefit of NetConf was to define a common framework for
>device management. This does not mean that there would be only one operational
>model for it. I can readily imagine that the protocol could define both
>a merge type of model (where a component structure is merged with the
>device's configuration) and an action-oriented model (where separate messages
>are used to perform specific actions on the model like add, set and delete).
>One solution does not fit all.
>
>On the other hand, letting the individual
>device data-model decide both on the structure of the data and the
>operations
>on it seems to make the protocol impotent... Applications will have to be created for
>each device type separately. I can see how one can data-drive the manipulation
>of the data-structures (schemas). I'm not as clear on how one data-drives the
>processing of the data (semantics). There has to be something recognizable
>(standardized) in the model to look for (i.e. this is how "adding" is encoded,
>this is how "changing" is encoded, ...). If the operations are relegated
>to the data-model, I'm convinced NetConf will have to define guidelines for that
>model...
>
>I'm also quite worried about thinking of the XML structures in too
>theoretic a
>way. Yes, I can imagine how one would have and edit-config operation with
>operation markers embedded in it to say what gets added, changed and deleted.
>On the other hand I dont see well how that can be used pratically...
>It's not an obvious thing to construct at all... I expect the vast majority
>of use will be to have separate messages to delete, set, and add stuff.
>In that case, encoding the editing operation in the data-structure itself
>(though workable) looks quite goofy... (in fact the actual naming of components
>as full hierarchical embedded XML elements is also not that "optimal"...).
>Alternatively (as has been raised earlier) if the preference is to
>extract the component structure (show-config), modify it, and dump it all
>back to the device to replace the existing one, then you don't really need
>fancy operation markup... on the other hand, what you then have
>is just another form of FTP... (and I have my worries about long
>payloads in the SSH transport...).
>
>So, in conclusion since I'm sure I was too confusing above, I think
>that
>1) NetConf would be better to define the operational aspects of the configuration
> (adding, setting, deleting, loading, ...),
>2) I would prefer those operations would be encoded in the NetConf message itself,
> not inside the data-structures,
>3) If they are inside the data-structure, then I think NetConf must define
> the way they are presented (which probably implies that NetConf would have
> to define the structure of that data-model...).
>
>Without this, I expect NetConf will be little else than an RPC protocol
>with
>fancy XML payloads that help little with management inter-working. Not necessarily
>useless but not what I thought the intent was.
>
>Thanks
>
>P.S. I worded things in terms of the editing operations (add, set,
>delete) but
>I think they also apply in many ways to the show operations (configuration
>vs operational).
>
>-----Original Message-----
>From: Andy Bierman
>[<mailto:abierman@cisco.com>mailto:abierman@cisco.com]
>Sent: Thursday, March 25, 2004 10:43 AM
>To: Waters, Glenn [CAR:IO47:EXCH]
>Cc: j.schoenwaelder@iu-bremen.de; netconf@ops.ietf.org
>Subject: RE: same value operation attributes restriction
>
>At 07:14 AM 3/25/2004, Glenn Waters wrote:
>
>>> I want to have some chance at multi-vendor interoperability. If we
>>> don't specify how the protocol allows a configuration database to be
>>> manipulated, then developers won't know what to code. We have a set
>>> of operations (create, modify, merge, replace, delete) with well
>>> understood semantics. I don't see how this is a CLR.
>>
>>I agree that we need to specify the type of update.
>>
>>I understand create and delete.
>>
>>I don't understand the difference between replace, modify, and merge.
>>
>>Is replace just a delete following by a create? If so why not
>>eliminate
>>it.
>
>Because it's one operation, not two.
>This is better because it can make some tasks easier to code for the
>application developer.
>
>Modify will fail if the indicated data does not already exist. This is
>useful for access control and to enforce stricter programming practices
>than merge or replace.
>
>>I think we need the equivalent of the SQL "update" which I guess is
>>modify or merge but I don't understand the difference between those
>>two. Also, to use existing industry terminology why not use the
>>keyword "update".
>
>Update is very generic. Counters get updated too.
>I don't care very much about terminology, other than
>a strong desire to avoid ratholing over it.
>
>>Regards, /gww
>
>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/>http://ops.ietf.org/lists/netconf/
>>