[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
minutes for NETCONF WG interim meeting (09/03)
Hi,
Here are the minutes for the recent NETCONF interim meeting.
Sorry for the delay.
Andy
NETCONF WG
OPS Area
Minutes for Interim meeting, September 8-10, 2003
Minutes by Andy Bierman from notes by Sharon Chisholm,
Rudy Deca, David Harrington, and Eliot Lear
1) Agenda
- Design Goals
- Operational Model
- Capabilities Exchange
- RPC features
- Protocol Operations
- Error Messages
- Operation details
- Selection of standardized transports
- Selection of mandatory transport
- Review of netconf-over-foo drafts
1.1) Reading Material
A) NETCONF Configuration Protocol
<draft-ietf-netconf-prot-00.txt>
B) XML Network Management Interface
<draft-weijing-netconf-interface-01.txt>
C) Using the NETCONF Configuration Protocol over Secure Shell (SSH)
<draft-wasserman-netconf-over-ssh-00.txt>
D) The SSH Protocol Mapping for NETCONF
<draft-lear-netconf-over-ssh-00.txt>
E) A SOAP Binding for NETCONF
<draft-goddard-netconfsoap-00.txt>
F) NETCONF Transport over BEEP
<draft-lear-netconfbeep-00.txt>
2) Design Goals
The following list of design goals was compiled by the group.
This is not an ordered list.
- Interoperability
- Transport Neutral
- Ease of use for existing tools, such as XML parsers
- Ease of use for script writers and toolkits
- Biased towards script writers to start
- rapid prototyping, easy to debug
- Existing SSH clients
- true programmatic interface
- Don't preclude complex application development
- Maximum common functionality
- Multiple device transactions
- Technology close to the CLI
- Support for netconf same timeframe as the CLI
- Facilitate a strong similarity between CLI data model
and netconf data model, but don't preclude other data
model design
- Ease of implementation on devices
- Scales from very small to very large devices
- Easy to create and use data models
- Integrated support for security
- Appropriate granularity for authorization
- Get and edit on full or partial configurations
- Support for actions (exec commands)
- State data retrieval
The major discussion points centered on the 'ease of use' goal.
The group decided that initially priority should be given
to operators who write scripts over application developers,
although decisions on protocol features should not preclude
complex application development.
There was also a concern raised that the NETCONF protocol
is not needed at all because WEB Services covers all of the
functionality proposed for the NETCONF protocol. The group
decided that until and unless a comprehensive Internet draft
is proposed to the WG which details how all the features of
the NETCONF protocol are addressed, WEB Services will not
be considered. There is also some significant concern that
the Operator Requirements (as expressed in RFC 3535) do not
ask for this approach. Also, some vendors are concerned
about the extra overhead in development, runtime resources,
and developer training that would be required.
3) Operational Model
It is understood that the protocol operations defined in
the NETCONF protocol are meant to be applied in a specific
operational environment.
The protocol operations in the NETCONF protocol are
designed to be as independent as possible from the
data models supported by the device. The terminology
"operations on the suitcase" is used to describe operations
which are completely independent of the data model.
The data models are considered the "contents of the suitcase".
3.1) Sessions
The following operational requirements were re-affirmed:
- the NETCONF protocol is session-oriented (not packet
oriented).
- there is a single user associated with a session.
3.2) Directionality of Connections
There are valid use cases which require a managed device
to initiate a connection to a management station, such as:
- large quantity of small devices (Cable or DSL modems)
- firewall or NAT configuration prevents manager to device
connection
The group decided that at least one transport mapping must
support bi-directionality for connection initiation.
3.3) Use of Channels
The group discussed the use of channels within the
NETCONF protocol, and whether support for multiple
channels should be mandatory. The uses for channels
are:
- session-related asynchronous notifications
- overlapping/asynchronous RPC requests
- control of ongoing requests
The group decided that channels should be optional.
For the case where only one channel is supported,
then some mechanism to abort an RPC in progress must
be devised.
3.4) RPC Processing Order
A request was made to remove text in the netconf-00 draft
which requires RPC requests to be processed in the order
received. After much discussion it was decided that:
- RPC requests within a single session are serialized
- commands within a single RPC request are serialized
- there is no specified scheduling behavior for RPC
requests across different operations channel within
the same session
- there is no specified scheduling behavior for RPC
requests across different sessions
- there will be no mechanisms added to the NETCONF protocol
to facilitate safe parallel processing of RPC requests
- explicit support for parallel RPC processing may be added
in the future
3.5) Configuration Locks
Locking was discussed, and several points were raised:
- Configuration locks are held by a session, and apply to a
specific configuration database.
- Locks are global (apply to the entire configuration database)
- More granular locks depend on the data model. An implementation
must figure out how to apply a partial lock across different
overlaid data models (per access mechanism).
- An access control issue was raised in which a user can lock
an entire database, even if that user does not have write
access to the entire database. It's not clear how serious
this problem is, but the solution is an open issue. Potential
solutions include:
- simply document problem in the Security Considerations
section (not really a solution)
- Disallow locking unless the user has write access to the
entire configuration database
- Make the lock apply only to the portions of the
configuration database that the user has write access
- A potential denial-of-service attack can occur since a user
can grab a global lock and hold it, locking out all other
activity. The attacker could create a script that immediately
reconnects and locks a database, if another user issues a
<kill-session> operation of the attacker's session. The
group decided to add a <steal-lock> command to prevent
a race condition related to acquiring a lock to delete the
user from the system.
3.6) Multi-device Transaction Support
The following operations are useful to make network-wide
configuration changes easier:
- lock, unlock, checkpoint, rollback, validate
It may also be useful to add an additional parameter to
RPC requests and replies to represent a distributed unit
of work identifier. This would be provided by the application
and ignored by the device (simply returned in the <rpc-reply>).
3.7) Configuration Databases
Configuration databases were discussed in some detail.
3.7.1) Specified as RPC Parameters or as part of the data model
It is possible to identify a configuration database as part
of the element path in the data model, as opposed to a
specific parameter in the RPC request (e.g., target parameter
in the edit-config operation). There are tradeoffs to each
approach:
Data Model Approach:
- more flexible, allows for multiple configuration database
targets in a single RPC operation
- more complex corner cases to check for, such as the same
configuration database being listed more than once, with
overlapping (possibly conflicting) data model subsets
Parameter Approach:
- restricts an RPC operation to a single configuration
database
- simpler to validate instance documents against a schema
- simpler to identify the parameters to a specific RPC
operation
The group decided to specify a configuration database
as part of the RPC parameter set, not as part of the
data model.
3.7.2) Named Configurations
The group decided that user named configurations should be
an optional feature, identified by capabilities. There are
two types of named configurations:
- named configuration database : configuration directives
stored in an internal format and can be accessed in
fine-grained granularity
- named configuration file : a text file containing
an ordered list of configuration directives
The difference between these two named configuration types
is the set of protocol operations that can be performed on
them. A named configuration database is capable of supporting
operations such as <edit-config>, <get-config>, <validate>,
<lock>, <unlock>. A named configuration file can only support
a limited subset of the protocol operations. The exact list
of supported commands for each type of named configuration is
still TBD.
One question raised was whether different configuration
databases have the same schema files associated with them.
It was decided that they all have the same superset of
schema files. It is possible for the actual schema to
be different in some situations. For example, if some
schema is loaded dynamically when a module in inserted,
it is possible for one configuration database (e.g.,
<running>) to contain new schema for the inserted module
which is not present in another configuration database
(e.g., <startup>).
Action Item: Glenn Waters will post a list of attributes
that apply to configuration files.
3.7.3) Mandatory Running Configuration
The <running> configuration is the set of all currently
operational configuration parameters. All devices have
a running configuration. There was some discussion
about the inability of some devices to allow an application
to retrieve the entire running configuration with one
<get-config> operation. It was decided that the operator
requirements clearly state that the entire device
configuration should be retrievable in a single protocol
operation.
3.7.4) Multiple Running Configurations
There was some discussion on the inability of some devices
to represent all current operational parameters in a
single running configuration. An example of multiple
instances of a MIB (distinguished by SNMP context ID)
was given. The group decided that the data models
must be constructed (or extended) in a manner that allows
all instances to be identified, without the use of an
extra naming parameter in the protocol. The operator
requirement for retrieval of the entire configuration
overrides this corner case. This issue will be
discussed further on the mailing list.
3.8) Object Oriented vs. RPC Design
There was a discussion on whether the structure of the
protocol operations should be structured in an RPC-like
fashion (i.e., as in the netconf-00 draft (A)) or in an
object-oriented fashion (i.e., as in the weijing-01
draft (B)). The group decided the RPC approach is
easier to read, and operators are more likely to be
familiar with this structure.
3.9) Capabilities Model
Capabilities are exchanged when the NETCONF session is started,
and they can also be retrieved with an RPC request. They are
used to identify the static capabilities of the NETCONF peer
(e.g., 'candidate' configuration supported on a device).
They are also used to identify the list of schemas supported
by a device.
The group discussed the format of a capability. The three choices
considered were:
a) separate data elements
<capability>
<authority>ietf.org</authority>
<version>1.0</version>
<name>candidate</name>
</capability>
b) specific elements
<capability>
<abc:candidate version="1.0"
xmlns:abc="http://ietf.org/netconf/capabilities"/>
</capability>
c) URI
<capability>
http://ietf.org/netconf/capabilities#candidate
</capability>
The group decided on approach (a) because it is sometimes
necessary to parse the version number. Approach (b) requires
more maintenance when a new capability is created, and
also does not allow standard and proprietary capabilities
to be handled in the same fashion. Approach (c) does not
allow the version field to be easily identified and parsed.
3.10) RPC Model
Several aspects of the RPC model were discussed.
3.10.1) Message ID
The message ID may not be needed if RPC requests must be
processed in a serial fashion, but the group decided to
keep the message ID anyway.
3.10.2) Choice of RPC mechanism
The group discussed whether the lightweight RPC mechanism
defined in the netconf-00 draft should be used, or if the
SOAP RPC mechanism should be used instead. The group decided
to use the netconf-00 mechanism because the protocol should
be transport-neutral and the SOAP headers may not be present
in all scenarios.
3.10.3) Keep the RPC element
It is possible that the high level <rpc> and <rpc-reply>
elements are not needed. The group decided to keep them
because:
- the use of a consistent end tag (e.g., </rpc>) may
make parsing easier
- a container is needed if an RPC request is ever allowed
to contain more than one operation
- for dual-role entities, it is possible that instance
documents containing either a top-level <rpc>
or an <rpc-reply> element may be encountered.
3.10.4) Multiple operations per RPC
The group decided that (for now) only one operation per
RPC request is allowed. If this is ever supported in the
future, then error handling and processing order issues
would need to be resolved.
4) Protocol Operations
4.1) Generic vs. Specific Operations
The group discussed whether the NETCONF protocol should
define specific operations (on the "suitcase") or should
there be a generic operation (e.g., perform-request) and
let the data model designers define protocol operations
within each data model.
This is essentially a tradeoff between flexibility and
interoperability. Operations defined within the protocol
must be implemented exactly the same on different platforms,
regardless of the standard and proprietary data models
supported by each platform. The group decided to use
specific operations (like those found in the netconf-00
draft).
4.2) Base Operations
The group discussed the set of protocol operations and
decided that the following grouping should be used:
Operation Associated with capability
----------------------------------------------------------
get-config
edit-config
copy-config
get-all *
kill-session base
edit-session *
lock
unlock
steal-lock *
-----------------------------------------------------------
create-config *
delete-config named-configs
-----------------------------------------------------------
commit
discard-changes candidate
-----------------------------------------------------------
validate validate
-----------------------------------------------------------
open-notifications
close-notifications notifications
notification *
-----------------------------------------------------------
* == new operation not yet defined or documented
4.3) Get Operations
The different 'get' operations (<get-config> and <get-state>)
were discussed. There are concerns that this is the wrong
combination of get operations. These concerns include:
- multiple operations are needed to retrieve configuration
and state data
- current implementations (e.g., CLI show commands) do not
separate state data and operational parameters, so the
requirement to exclude configuration data in a <get-state>
operation would be an implementation burden
The group discussed several options for the 'get' operation
and finally decided that two variants are actually needed:
- get-config
- get-all
4.4) Specifying a subset of a data model
There are several different approaches that can be used
to identify a subset of a particular data model. This
feature would normally be applied to 'get' operations, but
could also be applied to 'set' operations.
The functional requirements for this feature have not
been determined, but some choices for granularity are:
- subset by name
- table row(s)
- column(s)
- instances (of rows and/or columns)
- subset by parameter value
- similar to SQL SELECT
- retrieval options
- selected subset
- instance identifiers of selected subset
- N levels of selected subset
- select all children of specific start point
- select all siblings (and their children of a
specific start point
There are a few different solution proposals that need
to be examined:
- sub-tree filtering (as defined in netconf-00 draft)
- XPath filtering
- XML Query
The current proposal is to use the selection mechanisms
defined in netconf-00 and possibly add XPath filtering
as an optional capability. The idea of defining a subset
of XPath was dismissed because the WG wants to leverage
the XPath standard so existing and future tools which
support XPath could be used.
The details of subset specification need to be finalized
on the mailing list. There are some concerns that we
should not add complicated filtering and subsetting
mechanisms to version 1 of the NETCONF protocol.
4.5) Data Naming Issues
Three distinct styles of instance naming were discussed.
The choice of instance naming style may have some impact
of protocol operations and access control mechanisms.
Style 1: by attribute
<interface name="eth0">
Style 2: by simple element
<interface>
<name>eth0</name>
Style 3: by nested element(s)
<interface>
<name>
<ifName>eth0</ifName>
</name>
The actual impact of instance naming on the protocol,
and the choice for the preferred naming style were left
as open issues.
4.6) Text vs. XML Mode
The 'get' and 'edit' operations include a parameter
which specifies either test or XML mode. For 'get'
operations, the value 'text' indicates that the
data model specified in the input, and retrieved
in the output, is a proprietary text format.
For 'edit' operations, the value 'text' indicates that
the data model specified in the input is a proprietary
text format.
There are concerns that this feature will not work
well with the access control mechanisms defined for
use with the NETCONF protocol. The filtering and
subset selection mechanisms can not be applied to
the text format, but this is not a significant concern.
The WG will need to consider the importance of this
feature as it relates to access control.
The group also discussed conventions for including
text blocks within XML formatted data, such as a
special <text> element that could appear inside a
data model. No conclusions were reached on this feature.
4.7) Protocol Operation Open Issues
There were several additional protocol operation issues
raised that were not fully resolved:
- Is a <create-config> operation needed for named
configurations?
- Can <delete-config> apply to the target <running>?
- Can <copy-config> be used to create a named
configuration? (currently -- yes)
- Need a data model to determine the list of
configurations and their attributes
- Can the target <startup> be deleted or just emptied
of commands?
- Do we need a special designation for the 'last-known-good'
configuration (remote or local)?
- Can any operations besides <copy-config> apply to remote
configurations?
- Is a special <edit-session> operation needed?
- Is a special <steal-lock> operation needed?
- Should a special <action> operation be created for
named functions, or should these functions be nested
under the <rpc> element?
- Is an explicit 'create' sub-operation needed for use
with the <edit-config> operation?
5) Transport Issues
The WG is considering three separate application protocol
bindings for the transport of the NETCONF protocol:
- SSH
- SOAP over HTTP
- BEEP
It is possible that not all of these bindings will be
standardized. The WG goal is to select one of these choices
as the mandatory-to-implement binding. The WG will also need
to provide detailed applicability statements to justify
each standard application transport protocol for the
NETCONF protocol.
5.1) Authorization Model
There is minimal impact on the protocol to support access
control. A 'permission denied' error needs to be defined.
Also, new capabilities should be defined such that the
default behavior is to disable the associated feature.
This might simplify access control configuration.
There is some information that needs to be passed from a
NETCONF protocol implementation to an access control
implementation:
- user's name
- user's credentials
- transport used
- properties of the transport used for the session
- authentication
- privacy
The NETCONF protocol does not absolutely need to include a
standard schema for the configuration of access control.
This will be needed as standard data models are defined.
There are varying approaches possible for the configuration
of access control, offering a trade-off between simplicity
and granularity of control. The WG will need to decide on
the appropriate level of granularity when a standard data
model for configuration of access control is created.
There is some concern that high-level RPC functions
(e.g., add_bgp_neighbor) will complicate the access
control model because these functions can potentially
allow access to underlying data that the user may
not have permission to access. It was suggested that
the name of the function could be used in the access
control configuration, just as the name of a protocol
operation (e.g., edit-config) can be used. The group
did not make any decision on prohibiting these high-level
RPC functions.
5.2) SSH Approach
The SSH protocol is being considered as an application
transport for the NETCONF protocol. Some customers
have expressed a preference for SSH, while others
prefer SSL, SOAP, or BEEP. The group discussed some
details of using SSH effectively with existing tools.
There were mixed opinions as to how useful the NETCONF
protocol would be over SSH. Most people agreed that
it may be more appropriate as a rapid-prototyping
or debugging tool rather than an API for complex applications.
The arguments in favor of SSH include:
- leverages a deployed protocol that operators already
use and are familiar with.
- application developers can take advantage of existing
SW libraries, such as OpenSSH.
- operators who already use SSH for CLI access may not
need to do any additional security administration
The arguments against SSH include:
- no framing mechanism
- application and SSH error messages are mixed together,
making automated error handling difficult
- support for channels is difficult
Eliot Lear send an email to the NANOG mailing list, asking
operators to comment on the WGs proposed use of SSH as an
application transport for the NETCONF protocol. Responses
to this request will be posted on the WG mailing list.
The group decided that SSH should be pursued as one of the
standardized application transports for NETCONF. The two
individual submissions (C and D) on this topic will be
combined, and a single WG draft will be submitted.
5.3) SOAP over HTTP
There is significant interest in SOAP as an application
transport for the NETCONF protocol. Although it is
possible to use SOAP over BEEP (RFC 3288), this transport
mapping is not widely deployed at this time. The NETCONF
WG is considering use of SOAP over HTTP, since this mapping
is the most widely supported by existing tools. Operators and
application developers that do not currently use SOAP based
tools are not likely to change their SW development environments
without significant benefit.
There are some issues related to the usage of SOAP over HTTP,
some of which the group believes are resolved:
- use of HTTP 1.0 vs. 1.1: the NETCONF protocol requires
persistent connections for many operations, so use of
HTTP 1.1 is required to fully support these features.
- directionality of connections: HTTP is not symmetric,
which makes it difficult for a device to connect to
a manager.
- The connection initiator is the entity that must
generate RPC requests.
- Asynchronous notifications cannot be properly
generated from the device to a management application.
This can be partially resolved by creating a standard
notification log data model, which can be polled by
the management application.
- SOAP encoding: it was agreed that the document literal
encoding should be used, in order to minimize the
SOAP overhead and keep the NETCONF payload encoding
transport-neutral.
- unneeded SOAP protocol features: There is some concern
that SOAP has some mandatory features that are not
needed by NETCONF, which will contribute to codesize
overhead and development costs. Features such as proxy
support and the ability to process partial requests
(i.e., mustUnderstand == false) are not needed by the
NETCONF protocol. Ted Goddard has the action item to
examine the SOAP specification and determine exactly
which SOAP header mechanisms need to be supported.
- redundant tags: Although some elements (such as the <rpc>,
<rpc-reply>, and <rpc-error>) seem redundant if SOAP is
used, it was decided that the NETCONF mechanisms should
be used for all transports, even if redundant information
is also encoded in the header of a particular application
transport protocol.
The group decided that the WG should pursue a SOAP over HTTP
application transport binding for the NETCONF protocol.
The individual submission on this topic (E) will be updated
and submitted as a WG draft.
5.4) BEEP
The BEEP protocol (RFC 3080) is the most technically complete
application transport for use with the NETCONF protocol. It
provides the following features which are important for use
with the NETCONF protocol:
- Manager or agent can initiate the connection
- Support for multiple channels within a single connection
- Framing (with ASCII, not requiring XML parsing)
- Error reporting
- Security (TLS and SASL)
There are freely available SW toolkits which support BEEP.
The downside to BEEP is that it is not widely deployed at
this time, in either network devices or end user operating
systems.
The group decided that the WG should pursue a BEEP application
transport binding for the NETCONF protocol. The individual
submission on this topic (F) will be updated and submitted as
a WG draft.
5.5) Selection of a mandatory transport
It is desirable to select a single application transport as
a mandatory-to-implement requirement for compliance with the
NETCONF protocol, in order to promote interoperability.
However, the group decided this choice cannot be made at
this time. Once the details of all application transport
bindings are known, the WG will attempt to select one of
them as the mandatory binding.
A1) List of Attendees
Andy Bierman <abierman@cisco.com>
Steve Waldbusser <waldbusser@nextbeacon.com>
Ted Goddard <ted.goddard@windriver.com>
Wes Hardaker <wjhns1@hardakers.net>
Tim Stoddard <timothy.stoddard@utstar.com>
Glenn Waters <gww@nortel.com>
Michael Baer <baerm@sparta.com>
Eliot Lear <lear@cisco.com>
Bert Wijnen <bwijnen@lucent.com>
Bob Moore <remoore@us.ibm.com>
Sharon Chisholm <schishol@nortelnetworks.com>
Keith Allen <kallaen@labs.sbc.com>
Weijing Chen <wchen@labs.sbc.com>
Simon Leinen <simon@switch.ch>
Rudy Deca <rdeca@cisco.com>
Rob Enns <rpe@juniper.net>
Ken Crozier <kcrozier@cisco.com>
Satgan Raju <saraju@cisco.com>
Shmulik Nehama <snehama@nortelnetworks.com>
Mi-Jung Choi <mjchoi@postech.ac.kr>
David T. Perkins <dperkins@dsperkins.com>
Lixia Zhang <lixia@cs.ucla.edu>
David Harrington <dbh@enterasys.com>
Kevin Little <kclittle@enterasys.com>
Margaret Wasserman <mrw@windriver.com>
Phil Schafer <phil@juniper.net>
Randy Turner
Chris Norris <chrisn@cisco.com>
A2) Additional Materials
The raw notes used to create these minutes, and some
slides presented during the meeting, are available
online at:
http://www.ops.ietf.org/netconf/interim-2003-09/raw-notes.html