Last Modified: 2003-10-28
Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanims or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses.
The Netconf Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics:
- Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications
The Netconf protocol will use XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. XML also supports hierarchical data structures.
The Netconf protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the Netconf protocol, such as:
- identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines
It should be possible to transport the Netconf protocol using several different protocols. The group will select at least one suitable transport mechanism, and define a mapping for the selected protocol(s).
The initial work will be restricted to the following items:
- Netconf Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements.
- Netconf over
The working group will take the XMLCONF Configuration Protocol
The NETCONF WG met for two two-hour sessions in Minneapolis. Monday November 10, 2003 : 1530 - 1730 The agenda was accepted as proposed. Eliot Lear presented draft-ietf-netconf-beep-00.txt. This mapping
used to be part of the base NETCONF draft
(draft-ietf-netconf-proto-00.txt), but has been separated out into its
own document. Advantages of BEEP as a substrate for NETCONF include: Possible objections to BEEP: Left to do: Andy Bierman: There's too strong an assumption that reliable
syslog (RFC3195) is the only way to do notifications. Suggests to add
a note that new notification syntaxes can be added in the future.
Pending proposal from Weijing Margaret Wasserman presented draft-ietf-netconf-ssh-00.txt.
Several things have changed since last meeting. There is now support
for notifications, sent on same connection. Advantages Framing Issues: Should we add multi-channel support at all? Connections could be bound together with a session ID, but there
is some concern over complexity and security Is BEEP vs. SSH visible to operators? Andy Bierman: How does the high-level NETCONF application know
which substrate-dependent features are available? Glenn Waters: We need only one substrate Rob Enns: We had negative implementation experience with SSH, in
particular concerning XML framing, leaking of error messages intended
for humans etc. Margaret Wasserman: Supporting multiple transports complexifies
the base protocol. Margaret: Why do operators like SSH? Because they know it and it fits into existing provisioning and
security models. Eliot Lear: How many operators are in the room? (about 15). Some
questions for operators: Dave Plonka: Key distribution is already there. I'd like to see
the other protocols talk about bootstrapping the
authentication/authorization issue. Someone from a big carrier: We wouldn't care about the protocol if
the element management vendors would better support our needs. Glenn Waters: BEEP is not as widely available as e.g. SSH How would high-level app code know that some proto-ops (or mgmt
channel features) are not available? A: We talked about channels having this capability. The channels
capability is not functional with SSH (rpc-progress and
rpc-abort). Those channels are out-of-band. Should an end-of-message directive <?eom?> be used
to provide message framing? The issue is that if you get anything
malformed, there is no easy way to say end that one and get back some
error. In BEEP, if there is a framing error, the whole connection is
dropped, so we could use it here. The problem is knowing when you
have a framing error. Really want framing to be outside the XML. Or
can come up with something outside legal XML (like &&). Request for clarification: at one time we were talking about
setting up multiple ssh connections and binding them together to form
channels. Has that been dropped? A: Yes, for now. Ted Goddard presented draft-ietf-netconf-soap-00.txt. Under this
mapping, the manager initiates connection to agent. Multiple SOAP/HTTP connections with the same credentials and
session ID in request-URI constitute a session. Multiple connections
are needed for things like aborting operations. This leads to some
security and complexity concerns. Where SOAP is not strong at all is for asynchronous notifications,
because of HTTP's very distinct client/server roles. This does not
fit with notification coming from server, in this case the agent. How
can this be solved? No notifications over SOAP/HTTP, instead use
reliable syslog. Notifications are contained in HTTP requests to the
server. It is not clear if SOAP based tools would support
notifications. WSDL is used to describe a NETCONF SOAP interface, which enables
use of code generation tools. XSD and WSDL should be hosted by
IANA.org. Application scenarios: Configuration, not monitoring - Implementation issues: Need SOAP client and server stacks. The
NETCONF SOAP binding is designed for code re-use with other
transports. Requires document/literal SOAP encoding, not generic
encoding - a little more work here. Embedded SOAP static footprint
100k + application >
Eugene Golovinsky: Since this uses WSDL, why don't we just call it
Web Services? A: yes. Can the SOAP binding be made reversible? Let's say the agent is on
other side of the firewall and needs to contact the manager. A: Yes, the agent can do a get request and pull the commands from
the server. Is the use of multiple TCP connections per session problematic?
Some devices may not be able to handle multiple TCP connections. Async notification done by polling? Doesn t seem scalable. BCP 56 describes issues when using HTTP as a substrate. Only the
security area of the draft uses BCP 56. The next version of the
document should take these issues into account. There is some concern
that NETCONF should not run over TCP port 80. A: It seems like SOAP/HTTP violates much of the intention of BCP
56; however, it is very popular and viable, so I m not sure what to
do. Inherent messaging weaknesses. Pls review more and follow
recommendations for how to do XML exchanges. Using port 80 or different? A: usually goes over 80, but could specify it as unique.
Currently this is the implementer's choice. We will need to define a
port as the standard, be it 80 or other. Randy Bush: Section 3.6 discusses use of Proxies. My experience
with this kind of things in other protocols is that proxies only
complicates things by an order of magnitude. Please remove them for
now. With proxies, the connection could get torn down w/o you knowing
about it. If the proxy is gone, can you dictate the connections stays
alive? Otherwise you have to do time-based or human-based clean
up. Not sure we can do away with idea of proxies. They sit in the
middle of the network. We can't change them not being there. And if
they aren't, then non-port-80 HTTP looking protos are sniffed out by
stateful FW things. We need to admit they are there, and act
accordingly. Andy Bierman: proxies are designed to sit in the network and just
work. They shouldn't be our problem. Wes Hardaker points out a possible security problem with multiple
channels/connections within a session: If you have multiple channels
with different security properties, then you could end up sending data
through the management channel and returning through the other
channel, at a lower crypto level. You might want to add text that
requires the same security level for all bound channels. A: Agreed. Andy Bierman: Consider SOAP over BEEP (better for NETCONF than
HTTP). Is the SOAP community going to adopt this mapping soon? Is
the SOAP usage defined in netconf-soap-00 reasonable or will existing
tools expect more features to be used? The only reason for using SOAP is that it is useful for some
application developers and their choice of toolsets. Randy Bush: In order to make a selection, you need very clear and
detailed requirements, from operators, security experts, etc. Request for having only one mandatory. Others can exist, with
supporting text, but only one will be mandatory. Andy Bierman: Opinions that SSH is best have diminished, mostly
because of framing issues. Insiders at Cisco have tried SSH, and
finally went away from it. Randy Bush, with AD hat on. You can have 95 protocols if you
want, but only one mandatory. I don t care which one. But
one is necessary in order to have users/vendors be able to
interoperate Picking up implementations intended for use by humans (like SSH or
Telnet) has issues. Example: error messages that were intended for
humans leak and now you have to figure out if it is part of data or
not. Find something that is industrial strength, bullet proof, etc.
But keep another lying around for easy scripting and lower
requirements for robustness. Randy Bush, as operator. I want SSH because of fear of the
unknown, and because I already have a lot of SSH around, and I know
it. Operators are not adventurous types. Wes Hardaker. Noone has come forth and said, one of these
transports will not work for me. Andy Bierman: Notifications don t work well over HTTP. You have to
poll from them. Wes Hardaker: And they don t work well over SSH either. Looks like
we are looking toward BEEP Wes Hardaker, as operator. I have SSH already. Keys deployed,
etc. Would operators be aware of whether it was BEEP or SSH?
Randy: the large operators are rolling their own, so they would
know. The middle folks are rolling over and dying. The smaller ones
are buying off the shelf, and they would not know the difference. Question to operators: is compatibility w/ existing tool set more
important? Carrier1: think about bootstrapping. We have keys rolled out for
the elements now. We have ACLs configured already to allow the SSH
through. Would we need to create new ACLs for BEEP? Need new app
layer passwords? Easier to use the SSH already there, from bootstrap
perspective. Carrier2: if the vendors were to implement element management
systems that worked well with their elements, we wouldn t care. But
due to their lack of an object-oriented system that works well, we
have to build our expect/Tk scripting tools. Glenn Waters: BEEP not as widely available as SSH. SSH is in
anything, Perl, Python, C, etc. in any language. Should we optimize the protocol for which transport it is on, or
keep the same for each application mapping? Andy Bierman: makes the choice easier if only use one way. Margaret Wasserman: but if the transport has some feature, we
should use it, no? Why live to the least common denominator? + per transport connection. SSH can support multiple channels, so
we could change the document today make it a multiple channel
documents. * requires multiple transport connections ** Notifications are mixed w/ responses Enterprise folks aren't interested in cut and paste and Perl.
Library for BEEP for C, C++, TCL, Perl, JAVA, etc. The only thing
really missing is cut and paste and expect-style scripts. Typically
you'll see the name of the data and the data. But in XML format, that
stuff no longer works. Data and the Tag for the data may not be
easily located with regular expressions in expect scripts. R: These are not widely used compared to SOAP. On the roadshow
(NANOG) we wanted to know why people weren't using SNMP. Answer was
lack of toolsets. If we create something that doesn't get many tools
around it, they will not use it again, like SNMP for
configuration. Tools: a developer for another WG has done XML over BEEP. Tools
are there. The SOAP/HTTP issues. Randy Bush: we are going to run around in circles here. Get
detailed requirements. Get the audiences: Operators, vendors, people
who know transport issues, etc. Framing. If going to give a multi-megabyte config to a router,
difficult to compute the total length before start sending. A: can say "more coming" in BEEP. BEEP is built as libraries. The other tools for SSH and SOAP/HTTP
are not as well structured. Requirements for debugging are very different than those of
configuration. Config must be reliable, very solid, etc. Debugging
req s might be lower threshold. Andy Bierman: What about multiple operation channels? We have all
these not-quite-requirements for channels now. But it may be nice to
have in the future for extensibility. Andy Bierman: Propose to move on and discuss operational model.
If we make decisions on some of those areas, may help make the
requirements more clear for application/transport mapping. Andy Bierman: Should a mapping be allowed to leave out protocol
features? Modularization of channel definition: Application mapping resolutions Pick one mandatory to implement - important for interoperability Long discussion over comparision of application mapping
costs/benefits. Resolution: need to clearly identify functional requirements and
use cases for each one. No decision made on mandatory-to-implement
mapping. If agent initiates session then how does it know which user
identity to use during login? reverse connection model uses different security model Capability representation -
URI/URI+Version/Naming authority+name+version? Ted Goddard: If possible, should use URLs that point to actual
schema definitions. There is some concern over too many capabilities. Notification element didn't make it into the protocol document
Prefer to buy rather than build, when available. RFC 3195 is
there now. I think you'd be insane not to allow flexibility for future. Like
the IDS format stuff. Propose to allow 3195 as one of the options,
but not the only way. Andy Bierman: How to import their data model? what if 3195 gets
revised? Response: There is no data model in RFC 3195. Either cooked or raw
mode. Suggest taking out the one line in the doc that prescribes RFC
3195. Agreement on this point from chair. For now, line will be
removed. Either you follow RFC 3195 or you don't. Either is fine,
but we need to be clear. Wednesday November 12, 1300-1500 Weijing Chen: Notifications are specified in our draft. Eliot: We're looking at notifications related to configuration in
particular. Andy Bierman: Take it to the mailing list. Weijing could make a
propsal for WG defined notification structure. Otherwise don't use; RFC 3195 does not need this top level element
Attendee a: points out that 3195 references BEEP channel as
mechanism. Attendee b: points out that syslog connection would be required
24x7 Eliot Lear: some mediation element provides filtered notification to
NETCONF aware element Weijing Chen: comments re: 3195 tying to beep and pointing to SOAP
and other transports. Eliot Lear: suggestion for punting on notification and let other folks
work on the issue or alternatively making it an option Weijing Chen: Points to a discontinuity in XML wrapping. Attendee c: points out that charter states requirements for
transport independent protocol as well as asynchronous operation. The inability to separate notification from transport provides a
challenge. Taken to the list List the advantages of multiple channels, and ask operators whether
those are worthwhile to them. David Perkins: Is there anyone for whom the addition of channels
would make matters worse? Randy Bush </ad>: complicates things and narrows choices,
doesn't need channels. This is NETCONF - configuration
specific, not out to replace SNMP notifications, traps, etc. Andy Bierman: It adds complexity to the spec, to
implementations... Randy Bush: Complicates protocol, limits our options. Bert Wijnen: Having everything as capabilities makes usage more
complex. Wes Hardaker: People aren't sure whether they need them [channels]
until they have been able to work with implementations. Randy Bush: I like doing things in lockstep: I have changed
configuration in the device - then I want to check whether it had the
intended effect. I don't want to replace notifications and traps.
Network configurations (NETCONF) is fully synchronous. Eliot Lear: question to operators - where do they stand relative
to channels? Simon Leinen: A single channel is adequate. The interactive
element is nice but not core to the configuration capability. Weijing Chen suggests dropping channels. Action on Eliot to send mail to NANOG regarding applicability and
use of channels and follow up to list. Multiple transport connections for one session, or have all
channels in a single transport connection. Andy Bierman: punt this issue until we understand what to do
w/channels? edit session - management of volatile session properties, Do we need <edit-session> to change per-session
state/configuration? Randy Presuhn: An example would be to enable/disable XML
pretty-printing. Andy Bierman: ssh session management (minor -> to list) punt for now Inconsistency in SSH draft: <kill-session> requires
session ID, Andy would propose to use session ID=0 to kill current
session, but this is incompatible with current protocol draft. Proposal: Go back to original idea of just using a URI. Version ID at the end or in the middle? Do we even want to
standardize these URIs? No objections to using style B. So we'll say we're going to use
style B. comments re: style A vs. style B Ted Goddard: Capability negotiation is the only thing that doesn't
fit into the RPC form. Having it as a regular RPC would make the SOAP
mapping easier. Randy Presuhn: Another reason to treat capabilities exchange as
another RPC: It doesn't really change what you should accept, it is
advice from your partner as to what you should send. Having
capabilities as an RPC is an elegant idea. Some comments regarding the ability to change capabilities over
the course of the session Weijing: Dynamic capability notifications Andy Bierman: It would make use of the protocol easier if
capabilities would remain static for a session. Discussion to
solidify this to be taken to the list. Manager/agent capabilities - preventing deadlocks on startup. Andy Bierman went through list of current capabilities as well as
a few ones that could be added, soliciting comments. There were no objections to having the following as capabilities:
User-defined databases and files. <xpath> - propose to leave them out. Weijing Chen: what protocol elements are impacted by these
"missing capabilities"? Andy Bierman: Come back to this later, I have other slides. Wes Hardaker had brought up a potential DOS issue, when you grant a global
lock and a user with local privileges locks out access to the entire
database. Wes Hardaker: It's an important issue in my mind, because it is a DOS
attack that cannot be fixed. No objections to adding a lock-stealing operation (may be an
optional attribute to the <lock> operation. underlying assumption that there's a configuration database that
is NETCONF aware/capable Limited set of protocol operations allowed on files: Query for more file operations - no response from group Solicitation for comments re: user named databases - taken to the
list for further feedback Do we need <create-config>? Some database people don't like implicit creation. solicitation for comments re: text mode vs. text wrapper Add a new "<text>" element rather than have the (text/xml vs
text/plain) parameter? Ted Goddard: You could use another tag, for example
<example:cli>. Rob Enns: Or you add <get-text-config> in addition to
<get-config>. Phil Shafer: It is important to keep the possibility of retrieving
text-based configuration. People will use this to archive
configurations etc., and text mode remains easier for people to deal
with. Attendee X: suggests that API hooks be provided to let folks get
config info into their systems. Attendee Y: points to the importance of having text mode
available, points to config archival/diff/retrieval. Weijing: The format is really decided by the schema. One could
use a special text-oriented schema, maybe with just one element. Wes Hardaker raised concerns about applying consistent access
control to XML and text modes. Can't specify mechanisms for text
content since there will not be a well-defined schema. Rob Enns: Having the format= attribute makes it easier to
use XML-based access control. Phil Shafer: Access control for modifications via XML should match
access control through CLI. Andy Bierman: Those may not always be linked so closely. Randy Presuhn: Text and XML versions may either not be directly
related, or there may be a mapping through e.g. XSLT. Keep the param only for copy-config because this feature of
providing XML or text output is meant to apply to the entire
configuration, not complex data selection found in edit-config and
get-config. There were also concerns that there may not be a complete mapping
between XML and text representations of a data model. The device may
return an rpc-error if a copy-config cannot be completely generated
for a particular format. no clear consensus reach on this item - taken to the list Should there be per-session candidate configurations? <commit> Provides implicit rollback. Protocol should have an explicit
rollback. Andy Bierman: This is one of the features that customers
actually have asked us for. Ted: What if you don't have enough storage space for a
configuration to roll back to? Andy Bierman: Then you don't advertise the capability. John Schnizlein: Would this be a global or a per-session rollback?
Andy Bierman: Global. It takes out the last committed
change. John/Wes: This is non-transparent and dangerous. Andy Bierman: Rollback-on-error doesn't have the same problem,
does it? Wes Hardaker: Rollbacks could actually undo changes that the user
shouldn't be able to undo. Andy Bierman: Ok, I understand. But I still think
rollback-on-error doesn't have these problems. There's no explicit "add" operation (only merge, replace and
delete). An "add" (or "create") would fail if the thing that's being
added already exists. No objection to adding this. rollback-on-error no formal param for txt or xml encoding Decided to have <get-all> instead. Action: Add text to the draft explaining the issues to the draft Rob Enns doesn't like the name <get-all> Rüdiger: Agree, you cannot clearly separate "state"
(non-configuration) and configuration data. So having <get-all>
and <get-config> is fine. Wes Hardaker: get-all would have filtering mechanisms Andy Bierman: doesn't concur re: get-config and get-all john: query re: the need to have 1 massive operation vs. 2 smaller
operations Wes Hardaker: points that the single operation provides a match
between the configuration and the state of the device and provides a
binding between the 2. john: wants the text to reflect Wes' reasoning to provide the
rationale (binding the 2 elements together) Glenn Waters Modeling and the Protocol How should documents be named Granularity Should the actual implemented model be available through the
protcol? Andy Bierman: feels that "document naming" is a bit misleading
given that element may have nested structure. Modeling requirements Change control rules Managing standards based objects vs. vendor objects, version
numbers, etc. Modelling Language XSD of course - it is very popular, and there is an abundance of
tools. But... Next Steps Anyone want to help out on this? Wes Hardaker: thanks for the work being done. Andy Bierman: new mailing list for the data modelling? Sandeep Adwankar presented
draft-adwankar-netconf-symple-00.txt. synclet - based on SyncML Folks are encouraged to read the draft and make comments on the
list. Attendee: request for a comparison between SNMPCONF, SYMPLE and
NETCONF. Goals and Milestones:
Done Working Group formed Done Submit initial Netconf Protocol draft Done Submit initial Netconf over (transport-TBD) draft Dec 03 Begin Working Group Last Call for the Netconf Protocol
draft Jan 04 Begin Working Group Last Call for the Netconf over
(transport-TBD) draft Mar 04 Submit final version of the Netconf Protocol draft to the
IESG Apr 04 Submit final version of the Netconf over (transport-TBD)
draft to the IESG Internet-Drafts:
No Request For Comments
Current Meeting Report
Network Configuration WG (NETCONF) Meeting Minutes
OPS Area
Network Configuration WG (NETCONF) Meeting Minutes
IETF #58
Note takers: Gregory M. Lebovitz, Steve Ulrich, Simon Leinen, Andy Bierman
Agenda Bashing
NETCONF over BEEP
Directionality is considered important because TCP goes easily
through NAT and firewall devices, but SNMP makes this difficult.
BEEP natural for many peer to peer use cases.
Q&A
NETCONF over SSH
Q&A
NETCONF over SOAP
Typically
implemented in .NET or Java
(SOAP libraries exist for most
languages) Q&A
Discussion of Mandatory Substrate Selection
Application Mapping Comparison
Feature BEEP SOAP SSH Agent inits connection Y N Y Multiple Channels per conn+ Y N N Supports <rpc-progress> Y Y* Y* Supports <rpc-abort> Y Y* Y* Supports notifications Y Y* Y** Use exiting key env N N Y
Operational model
Channels
How important is rpc-process? rpc-abort can be
approximated by closing the session, but no such workaround for
rpc-progress.
Sessions
Capabilities
Notifications
Q&A
Notifications (continued)
Channels
Sessions (dependent on channels)
Capabilities
Capability representation:
Capabilities Negotiation
missing capabilities
Locks
<steal-lock>
Configuration Files
User-Named Databases
Text vs. XML Format
<candidate> Configuration
Protocol Operations
<edit-config>
<get-state>
Notes on Data Modeling Issues
XPATH, XML Query?
Can we pull back just a set of attributes,
or do we pull back entire documents
could be a URI or an XSD xferred via the protocol
- requires two models
SYMPLE - scripting protocol & architecture for managing
devices
2003/12/15 0:11:20
Simon Leinen <simon@switch.ch>
Slides
Agenda
NETCONF over BEEP mapping
NETCONF Over SOAP
Data Modeling
SYMPLE Scripting Protocol and architecture for seamless management of XML based mobile devices and SNMP based devices