Thanks Dave for the well-thought through post.
I think the 'restriction' on Netconf for configuration has always been
an artificial one, but it has served us well. One of the big problems we
ran into with SNMP was we kept picking off the easier problem of
monitoring and never giving configuration enough focus. By limiting the
focusing primarily on configuration for Netconf 1.0, we have ended up
with a great technical solution that is seeing some good market uptake.
I think actual implementations of Netconf are not limiting themselves to
just configuration. The CLI never did. For deployments, the high cost of
having to integrate information from different sources gets weighed
against the cost of having to replace legacy systems. Sometimes it wins.
Sometimes it doesn't. For the most part, all this can be done using the
existing framework. The gaps that people run into when trying to do this
are, I believe, the same ones they run into while trying to use Netconf
for configuration - access control, data model and notifications.
Another gap might be 'operational' commands such as rebooting and
maintenance, but the universal requirements there are not yet clear to
me.
I've personally been working both the data modeling and the notification
issue. I'd work access control, but other then a sense that I'd like
something simpler then we've seen in the past, I have no idea what we
would need. They are all important, both for configuration-only
implementations and configuration-plus ones. I've focused more on the
notification work lately because I was getting a lot of pushback on the
data model work from certain people, but I'm willing to put time on that
topic again. I think though, that for people looking to be able to pick
up third-party Netconf stacks, there are some big advantages to being
able to standardize on any extended protocol operations sooner rather
then later.
As far as whether if we said from day one that netconf would do more
than configuration and things would have been designed differently, I
don't now if that is the case. As far as being forced to solve problems
at some point in the future related to performance management if we
don't somehow engineer/re-engineer the protocol so it can't be used for
things like that, I don't think that would be helpful. At that day in
the future the community can decide whether it wants to spend time on
that particular problem. Plus, unless at that point in the future we
learned that they were not also using Netconf for configuration, this
would be a sign of success.
So, in summary, I think the current notification work absolutely is
necessary for configuration management. I don't see the value of
precluding its use for other functions and I believe for the other
functions all we need to do is provide the ability to specify the
correct event class. I'm also willing to work on the other gaps.
Sharon
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of David Harrington
Sent: Tuesday, March 28, 2006 1:26 PM
To: 'Netconf (E-mail)'
Subject: Why are we doing netconf?
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.
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.
David Harrington
FutureWei Technologies, a Huawei company
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net
-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
(Dan)
Sent: Monday, March 27, 2006 5:20 AM
To: Andy Bierman
Cc: Netconf (E-mail)
Subject: RE: Interim attendance survey
[...] I am aware that this good shape is
apparent, and there is little agreement on the problem space, and
too
little review of the draft that includes a proposed solution even to
determine the level of agreement. I would encourage the WG to focus
on
discussing the problem space (why are we doing notifications?) and
the
draft and other options for solutions more intensively on the
list. Let
us see in the next couple of weeks if we can reach more convergence
on
the 'why' and 'how' questions.
If we do have contributions about the scope and reviews of
the draft and
solutions on the list we have a chance to better converge and reach
agreement. If the level of apathy stays the same, I am not sure that
a
partially attended interim meeting would help.
--
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/>