[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
message to nanog
- To: netconf <netconf@ops.ietf.org>
- Subject: message to nanog
- From: Eliot Lear <lear@cisco.com>
- Date: Mon, 17 Nov 2003 10:59:42 -0800
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031030
At the plenary, we agreed that I would draft a message to NANOG to ask
for feedback on features such as notifications & channels. Here is my
first cut at such a message. Let me propose that if we don't get enough
responses, we actually go to NANOG and do a presentation.
Subject: YOUR opinions needed for Network Configuration Protocols
Reply-to: netconf@ops.ietf.org
Dear NANOG folk,
The NETCONF working group of the IETF is currently developing a
collection of protocol specifications for the configuration of network
elements. This work originated from a roadshow that many of us went on
to learn what operators of different types want in such a protocol. Now
we would like to checkpoint with you on some of the contents of those
specifications.
The protocol itself is split into two parts: an abstract set of
functions, and a binding to specific protocols, including SSH, BEEP, and
SOAP over HTTP(s). Each protocol has its pluses and minuses.
As envisioned, the base protocol supports an option for notifications.
The idea is that a manager would be notified of configuration-related
events, such as a card insertion or removal, and act appropriately to
configure the element. The envisioned format of notifications is either
reliable syslog from RFC 3195 or something similar. Because
notifications are asynchronous, one writes code that implements a
dispatch mechanism that discriminates on the type of event.
Notifications would be an option that not all managers would have to
implement.
The working group is attempting to determine whether notifications
should remain as part of the base specification. Here are the choices
facing the group:
Option A. Leave them in as currently specified, and require all
protocol mappings to support them.
Option B. Allow them to be asynchronous, but don't use RFC 3195, and
require all mappings to support them.
Option C. Remove them entirely from the specification and let vendors
implement RFC 3195 or other notification mechanisms as they see fit (for
instance, existing syslog).
Do you have an opinion on which of these options you would like?
Related, the NETCONF base protocol currently makes use of the notion of
channels. Channels are a basic concept in the BEEP protocol, and they
exist in SSH as well. However, use of multiple channels in SSH is not
supported in common SSH applications. They are completely absent in
HTTP, and so the notion of a session would have to be introduced in the
mapping.
Channels provide a number of benefits. First, they divorce the idea of
who is the session initiator and who is the device manager. This means
that either the network element or the manager could initiate a TCP
connection. This is useful when NATs and firewalls exist between a
device and the manager. Channels are also necessary to implement a way
to determine progress of a configuration operation.
The working group has three choices:
Option A. Keep channels in the base document and require each mapping
to support them.
Option B. Make channels optional.
Option C. Remove channels from the base protocol and allow their use
in the protocol bindings.
Which option do you prefer?
If you would like to read the entire set of documents, you will find
them by going to the NETCONF working group charter page:
http://www.ietf.org/html.charters/netconf-charter.html
Eliot
--
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/>