[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: same value operation attributes restriction
At 03:45 PM 3/26/2004, Gilbert Gagnon wrote:
>Hello,
>
>-----Original Message-----
>From: Andy Bierman [<mailto:abierman@cisco.com>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).
The netconf WG needs to specify the meta-data that
the data model language must support.
>
>
>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.
I disagree that the vast majority will be one at a time.
IMO, it would be a mistake to prohibit this capability.
>
>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.
Reread the draft -- there is no as-if-simultaneous in netconf.
Operations within a PDU are serialized. It depends on the
payload and the implementation as to how many distinct internal
operations are needed to affect the desired changes.
That's why we have stop-on-error and ignore-error options.
>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.
I disagree. Customers have asked for the
ability to submit a group of config changes and
perform all of them or none of them. Complex atomic
operations would be ideal, but rollback-on-error is
good enough.
If we restrict netconf payloads to single, simple operations,
it will be impossible to deliver this feature to customers
using netconf.
> Thanks
Andy
>
> 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>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/>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/>