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

Re: Why are we doing netconf?

David Harrington wrote:

Hi,

I would like a better understasnding of why we are doing
notifications. I am struck by what appears to me to be two very
different drivers for netconf, and the "why are we doing
notifications?" question relates to these different motivations.

I have suggested that the O&M and Security communities should work at
establishing a strategic vision about converging aspects of the
various NM protocols and NM security solutions. If this is a path
worth taking, it should be a deliberate decision to do so because
there are some real problems associated with a convergence approach.

For this reason, I would like to understand what we are trying to
achieve with netconf and the current proposal for notifications, to
determine if the goals are compatible.

If the purpose of netconf is to provide a machine-friendly,
standardized protocol to eliminate the need for screen scraping CLI
expect scripts, I am not convinced we need notifications in the
netconf protocol. I think the netconf WG has done a reasonably good
job of standardizing the operations, but to achieve the goals, we also
need to improve the parseability of the data that now needs to be
screen scraped. The parseability of the data contained in the
responses coming back must be addressed. If vendors simply take their
existing screens of data and surround them with <cli></cli> tags, then
I think we've failed to eliminate the screen-scraping problem, and
other problems identified by operators at the IAB NM workshop:

   -  Some command line interfaces lack a common data model.  It is
very
      well possible that the same command on different devices, even
      from the same vendor, behaves differently.

   -  The command line interface is primarily targeted to humans which
      can adapt to minor syntax and format changes easily.  Using
      command line interfaces as a programmatic interface is
troublesome
      because of parsing complexities.

   -  Command line interfaces often lack proper version control for
the
      syntax and the semantics.  It is therefore time consuming and
      error prone to maintain programs or scripts that interface with
      different versions of a command line interface.

   -  Since command line interfaces are proprietary, they can not be
      used efficiently to automate processes in an environment with a
      heterogenous set of devices.

   -  The access control facilities, if present at all, are often
ad-hoc
      and sometimes insufficient.

Netconf does not seem to resolve these operational disadvantages of
the CLI, and notifications aren't even mentioned as a problem to be
solved.



Why not?
Because there are no standard data models yet?
The RFCs haven't even been published, so it's a bit early
to declare standard data modeling dead.


I am thrilled that so many implementations are under way
for a not-yet-published, no-port-assigned-yet protocol.
I want these implementations to continue, get deployed,
and then start with the enhancements.

The <cli> data model you mention is a natural evolutionary
step in the replacement of screen-scraping.  It provides
a way to get the protocol and error handling in place,
without giving up functionality.

This is the "wide and shallow" vs. "narrow and deep"
data model debate.  The reason every replacement
for the CLI that has been attempted has failed is
that they all attempt to deploy 1 or 2 "perfect" data models,
but most operators are not willing to use the CLI for
10000 commands and the fancy GUI for 20 more.

Although <cli> as a data model provides no depth whatsoever,
it provides 100% coverage of the CLI, plus structured error
codes, and maybe more.  Once this is in place, you can
start adding deep models for specific applications you
need to support.




If the purpose of netconf is to standardzie existing practice, and
existing practice is defined as screen scraping CLI expect scripts
plus syslog notifications, then I question whether we need to include
syslog notifications in netconf; syslog works well in its special
niche, and really doesn't need to be added to netconf.

The Syslog (-security) WG has been working to standardize the message
header format. The syslog community has not reached consensus on the
need to standard message content, except to add a structured data
component. The WG had difficulty even reaching agreement on
standardizing their message header format beyond starting the message
with <PRI>. I do not believe that netconf would be more successful at
standardizing syslog content than the syslog community, so I do not
believe that standardizing syslog message content should be a
justification for adding notifications to netconf, without a long
discussion about the feasibility of accomplishing this goal. I think
the standardization of syslog belongs in a (O&M) syslog WG, not the
netconf WG (and not the syslog security WG).

If the purpose of netconf is to assimilate the functionality of older
protocols like syslog and SNMP - to integrate them into a collective
netconf structure, and to eventually replace the old protocols with a
new general purpose management protocol minus the known problems, then
netconf has a higher bar to meet in its design requirements than have
been acknowledged. SNMPv3 is complex because it needed to deal with
security issues and troubleshooting requirements and other things;
syslog does not have a standard content format because there are a
wide number of vendors protecting their space, and the demand for
backwards compatibility to all or most existing header formats has
prevented progress in the syslog (security) WG. Faced with
requirements comparable to those faced by the older protocols during
their design, I expect netconf would fail to assimilate them properly.
Therefore, if the purpose of netconf is to be a general purpose NM
protocol, we need to have a serious discussion about the requirements
that must be met to achieve successful assimilation.

I find the existing proposal has plans to assimilate other protocols -
"The purpose of this [syslog-to-netconf] mapping is to provide an
unambiguous mapping to enable consistent multi-protocol
implementations as well as to enable future migration." and to attempt
to standardize that which the syslog community has failed to
standardize - "The intent is to promote the use of the NETCONF
interface and not to simply provide a wrapper and additional delivery
mechanism for syslog messages.  NETCONF events are intended to be well
defined and structured, therefore providing an advantage over the
unstructured and often times arbitrarily defined syslog messages (i.e.
the message field)."

I am a strong supporter of judicious reuse of NM and security
solutions across NM interfaces, but I believe apparent convergence
opportunities need to be discussed and for  each convergence we need
to consider the requirements met by each protocol and whether a
converged solution continues to meet those requirements or
deliberately does not meet some requirements.

I am bothered by the fact that netconf, a configuration protocol, is
being redesigned in the current proposal to carry syslog messages that
may have nothing to do with configuration, and it is expected that
even more stuff, also possibly not related to configuration, will be
carried in a new event message format. Operators at the IAB Network
Management Workshop apparently did not find syslog sufficiently broken
to request that a new event messaging capability be designed, so I
have concerns that the current proposal includes a brand-new
notification solution.

If netconf will become the new general purpose mgmt protocol for the
IETF, we should do this deliberately, not as a side-effect of adding a
notification operation to netconf.



I agree with these last 2 paragraphs a lot.
It occurred to me when I saw an event type
for "performance metrics" notifications that
we might not all be on the same page wrt/
what netconf notifications are needed for.

I know that throughout design meetings from Day One,
only 3 notification types related to configuration came up:

  - config-change: some part of the <running> configuration changed
  - device-change: some part of the managed device changed
    (e.g., card swap)
  - direct usage of RFC 3195 (syslog over beep)

I also think that if the content of syslog is to
be standardized, that the syslog WG should do it, not netconf.
I was comfortable with throwing a beep channel for syslog
into netconf, but not standardizing an XML-based replacement
for syslog content.  I am going to ask the ADs
to "move it or lose it" wrt/ syslog content in netconf.

Since our charter says we are doing network configuration,
not a syslog replacement or an snmp replacement, I would
rather work on that.  That's what I thought I was signing
up for as co-Chair in fact.

There are lots of unsolved problems in the NM world.
If we run off trying to solve everybody else's problems,
who is going to actually work on network configuration?






David Harrington
FutureWei Technologies, a Huawei company
dharrington@huawei.com dbharrington@comcast.net 
ietfdbh@comcast.net


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