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

Re: problems with 'ignore-error' <error-option>

Martin Bjorklund wrote:

Steve Berl <sberl@cisco.com> wrote:

The original intent of the option was to have behavior similar to Cisco IOS
doing "copy tftp://foo/blah running-config". In this case the configuration
is a list of lines, each represents an atomic configuration change
operation. If one line generates an error we can continue on and execute the
remaining lines, ignoring the error. The idea is that commands that don't
make sense can be ignored, but the ones that do make sense can be applied.

This proves to be a convenient behavior when an existing configuration runs
on a different device than it was originally created for, or when a device
has the software upgraded and some older commands are no longer supported,
or if the line cards in a device have changed so that some interfaces that
were there are now missing.

One of the data models that we are supporting in the Cisco implementation of
netconf is a list of command lines and this same behavior can be maintained
with the ignore-error option.

So, to better define the behavior in the netconf spec we need to be clear
about the errors that we are choosing to ignore. I think that these are the
errors that occur in the processing (not the parsing) of the <config>
element in an <edit-config>.


Aha!  This makes a lot of sense.  The feature to reload a
configuration which may contain old obsolete config parameters is very
convenient.  We have been talking about how to implement this within
netconf... The text should be updated though - both for stop-on-error
and ignore-error.

However, I think it would make more sense to have this option on
<copy-config> which is the command to use if you want to reload an old
config e.g. from a url.


I don't want to start adding features to operations
that didn't already have them.

I just want to clarify the error-option in edit-config.


I've mentioned this one before.  If the agent supports
rollback-on-error, I think that it should be up to the agent to use
that strategy instead of stop-on-error, which the text says is
default.  In which case would a manager actually prefer stop-on-error
before rollback-on-error?


The manager should use rollback-on-error if that's what they want.
They default is only applied when the parameter is missing.
I don't think it's ever a good idea to rely on defaults.
We already decided not to have conditional default values
based on various capabilities.  I think we should stick with that decision.



Further, the text says that a "negative" response is generated.  I
assume that it should be "partial-operation".  This should also be
stated, since although an rpc-error was returned, the target
configuration has actaully changed.  A manager must be able to detect
this case unambiguously.


It's hard to say what the error responses should be in any arbitrary case.
The data model must make it clear (good luck!).

I agree with you that a partial operation needs to be identified
if some but not all of the config element content is applied.


If a full config contains a single now obsolete parameter, the reply
might contain all good elements as <ok-element>, and the single
obsolete one as <err-element>.  Suppose the request was

   <config>
     <top xmlns="...">
       <servers>
         <server>
           <id>1</id>
           <descr>some text</descr>
           <name>www</name>
         </server>
       </servers>
       <interfaces>
         <interface>
           <name>eth0</name>
           <id>2</id>
         <interface>
       </interfaces>
     </top>
   </config>

Now, suppose the interface/name has been changed to ifName, and that
servers/descr has been removed in the current data model.  The
error-info of the partial-operation could be:

   <error-info>
     <ok-element>id</ok-element>
     <bad-element>descr</bad-element>
     <ok-element>name</ok-element>
     <bad-element>name</bad-element>
     <ok-element>id</ok-element>
   </error-info>

or worse:

   <error-info>
     <bad-element>descr</bad-element>
     <bad-element>name</bad-element>
   </error-info>

Imagine what it would look like if the config was big.

If the order of the elements are known to be in the same order as in
the incoming config, and all always present, it might be possible to
figure out what happened, but it's certainly not easy.

It's probably too late to change this now, but maybe the contents of
the error-info could be defined by the data model, and not the
protocol?


Not sure what problem you are describing here.
I will have to read it again later.




/martin



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/>