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

[Andy Bierman <ietf@andybierman.com>]

Steve Berl 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.
>   

Are you talking about simple XML-ifies CLI?

  <config>
     <cli>blah-blah</cli>
     <cli>blah-blah</cli>
  </config>

This is a trivial case.
Real XML data models are not so easy to implement for this feature.

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

I understand the intent of the feature.
I don't think it is specified in a manner that will
allow developers to create interoperable implementations.



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

I think you mean the application of config changes.
If a config change passes all tests then apply it,
otherwise go on to the next config change.

I think that's what you mean.
Just because an operation parses doesn't mean resources like locks
are free, or access control rules are met.

> There's probably a better way to say that.
>   

The problem with this feature is that netconf is not a  CLI.
There is no concept in netconf that the XML payload within
an <edit-config> operation is serialized into an integral number
of "lines".  "When an error occurs, continue to the next line"
does not mean anything in XML.

Support of this feature requires a lot of custom work,
and prevents widely available validation tools from being
used (because they validate an entire sub-tree or nothing).

You can't even say  "on error continue at the next sibling node"
because that isn't always true.  All you can say is "it is an
implementation-specific matter if and where processing
of the <config> sub-tree will continue after an error is
encountered."

IMO, this means "no interoperability whatsoever".


> -steve
>   

Andy

> On 2/2/06 8:50 AM, "Andy Bierman" <ietf@andybierman.com> wrote:
>
>   
> > Hi,
> >
> > We have heard from one implementer that says they cannot
> > support the ignore-error <error-option> in the <edit-config> operation.
> > Now one more.
> >
> > Here is the total documentation on the ignore-error option:
> >
> >          ignore-error: Continue to process configuration data on error;
> >             error is recorded and negative response is generated if any
> >             errors occur.
> >
> > 1) How many operators want this option?
> >
> > 2) How many vendors are supporting this option?
> >
> > 3) What does this option really mean?
> >
> >    - ignore malformed XML?
> >      Most tools won't do that.  This is not only dangerous,
> >      it isn't very easy to do.
> >
> >    - ignore missing parameters?  What happens if the <config>
> >      parameter is missing?
> >
> >    - ignore extra parameters?
> >
> >    - use RPC parameters that don't pass the schema validation tests?
> >
> >    - ignore access control violations?
> >
> >    - ignore lock access violations?
> >
> >    - ignore unsupported portions of the config parameter sub-tree?
> >
> >    - use parameters that fail the referential integrity tests?
> >
> >    - continue to install child nodes of a parent node with errors?
> >      (How?)
> >
> >
> > IMO, this mandatory feature of the NETCONF protocol is poorly defined,
> > hard or impossible to implement, and has no chance of interoperability.
> > It needs to be fixed or removed from the protocol.
> >
> > 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/>