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 B) XML Network Management Interface C) Using the NETCONF Configuration Protocol over Secure Shell (SSH) D) The SSH Protocol Mapping for NETCONF E) A SOAP Binding for NETCONF F) NETCONF Transport over BEEP 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 operation of the attacker's session. The group decided to add a 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 ). 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 , , , , . 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., ) to contain new schema for the inserted module which is not present in another configuration database (e.g., ). Action Item: Glenn Waters will post a list of attributes that apply to configuration files. 3.7.3) Mandatory Running Configuration The 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 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 ietf.org 1.0 candidate b) specific elements c) URI http://ietf.org/netconf/capabilities#candidate 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 and elements are not needed. The group decided to keep them because: - the use of a consistent end tag (e.g., ) 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 or an 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 ( and ) 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 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 Style 2: by simple element eth0 Style 3: by nested element(s) eth0 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 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 operation needed for named configurations? - Can apply to the target ? - Can 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 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 apply to remote configurations? - Is a special operation needed? - Is a special operation needed? - Should a special operation be created for named functions, or should these functions be nested under the element? - Is an explicit 'create' sub-operation needed for use with the 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 , , and ) 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 Steve Waldbusser Ted Goddard Wes Hardaker Tim Stoddard Glenn Waters Michael Baer Eliot Lear Bert Wijnen Bob Moore Sharon Chisholm Keith Allen Weijing Chen Simon Leinen Rudy Deca Rob Enns Ken Crozier Satgan Raju Shmulik Nehama Mi-Jung Choi David T. Perkins Lixia Zhang David Harrington Kevin Little Margaret Wasserman Phil Schafer Randy Turner Chris Norris 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