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

[Martin Bjorklund <mbj@tail-f.com>]

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'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?


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.

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?



/martin

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