111

XMLCONF

• Introduction

• Strategy

• Protocol Layering

• Session Management

• RPC Mechanism

• Capabilities Exchange

• Operational Model

• Protocol Operations

• Standard Schema

• Design Decisions

Topics

222

Introduction

• Effort within the IETF to promote XML based Network Management

• Focus on configuration because it is the biggest unmet need wrt/ IETF NM standards

Include support for monitoring and notifications

• Focus on replacement for Expect/Perl scripts which interact with proprietary CLI

What is XMLCONF?

333

Introduction

• March, 2001 OPS-NM Area MeetingRandy Bush asks crowd of 300 how many operators enable SNMP writes. Zero hands raised

• April, 2001 – May 2002OPS-NM Road show visits Operators at RIPE, NANOG, LISA to determine network management needs

• June, 2002 IAB Workshop on Network ManagementOperators want better scripting tools; Interest in XML

• July, 2002 XMLCONF BOF at IETF #54Well attended, lots of interest, but no concrete proposals

• November, 2002Small team started by Margaret Wasserman to write XMLCONF I-D and attempt to get WG created

History

444

Introduction

• Andy Bierman <abierman@cisco.com>

• Eliot Lear <lear@cisco.com>

• David Perkins <dperkins@dsperkins.com>

• Ted Goddard <ted.goddard@windriver.com>

• Phil Shafer <phil@juniper.net>

• Rob Enns <rpe@juniper.net>

• Ken Crozier <kcrozier@cisco.com>

• Steve Waldbusser <waldbusser@nextbeacon.com>

• Margaret Wasserman <mrw@windriver.com>

Team members (in no particular order)

555

Strategy

• Create a standard operational framework for configuration

Allow for monitoring and notifications, but focus on configuration

• Separate the protocol from the data model

Allow for standard and proprietary content

Standardize the protocol first, and then start on content

• Create a transport independent, RPC-based configuration mechanism

Standardize XMLCONF protocol over BEEP/TCP first

• Develop high level protocol operations common to most devices

Focus on transactions

666

Strategy

• Allow implementation to mirror native capabilities of device

Text-based technology such as XML permits tight integration with CLI

No feature lag between XMLCONF and CLI

777

Protocol Layering

XMLCONF

BEEP

TCP

IP

Initial Protocol Mapping

Other transport mappings (SSH, …) can be defined

888

Protocol Layering

• XML Content

Standard or Proprietary XML Schemas

• Protocol Operations

Standard XML Schema (XMLCONF)

• RPC

Standard XML Schema (XMLCONF)

• Session

Create standard channels through BEEP

• Security

SASL, TLS through BEEP

• Transport

TCP

• Network

IP

Functional Layers

999

Session Management

• Management channel

Session control; creation of other channels

Abort command kills current command on the operations channel

Kill-session used to terminate the session of another user

• Operations channel

Used for RPC requests and replies

• Notification channel

Optional channel for asynchronous messages

Channels

101010

RPC Mechanism

• <rpc>

Request on operations channel

• <rpc-reply>

Reply sent on operations channel

• <rpc-progress>

Provides progress reports (percentage completion) for long duration RPC operations, sent on the management channel

• <rpc-abort>

Provides a way to abort an RPC in progress, or queued for processing, sent on the management channel

• <rpc-abort-reply>

Abort RPC reply, sent on the management channel

XML Based Messages

111111

RPC Mechanism

• <rpc-error>

Included in <rpc-reply> if an error occurs during processing of an RPC request

• <ok>

Included in <rpc-reply> if no error occurred during processing of an RPC request

Error reporting

121212

Capabilities Exchange

• Each peer sends capabilities summary during session startup

• Capability is used only if both parties advertise the same version of the same capability

• Capability expressed as a URI<capability>http:/ietf.org/xmlconf/1.0/base</capability><capability>http:/ietf.org/xmlconf/1.0/base#notifications</capability> <capability>http:/ietf.org/xmlconf/1.0/base#candidate</capability><capability>http:/ietf.org/xmlconf/1.0/base#lock</capability>

• At least 1 version of the base protocol must be advertised

• Vendor specific capabilities may also be advertised<capability>http:/example.com/xmlconf/1.0/extensions</capability>

Base protocol + optional capabilities

131313

Capabilities List

• Base protocol

Set, Get and Copy configuration commands

Get system state information

• Optional Capabilities

Notification channel supported

Separate candidate (scratchpad) configuration

Lock configuration for exclusive writing

Candidate configuration (commit and rollback)

Configuration Validation

Separate startup (NV-stored) configuration

Named Configurations can be stored on the device

Initial set

141414

Operational Model: Concepts

• A device contains one or more configuration datastores

• Some of these datastores have special semantics

candidate, running, startup

• Configuration datastores can be created, copied, retrieved, deleted, and validated

Basic framework concepts

151515

Operational Model: Datastores

• candidate

Collects changes that are applied all at once to the running config

Exists only if candidate capability is supported

• running

Current device configuration; changes to this config take effect immediately

Exists on all devices

• startup

Configuration to apply to device upon next reboot

Exists only if distinct startup capability is supported

Special configuration datastores

161616

Operational Model

candidate running startup

Configuration datastores

• Different variants of this model are possible

171717

Operational Model: Named Configs

• A simple text (or XML) file that contains a complete or partial configuration

Optionally supported by the device

Specified with a ‘file’ URL

181818

Protocol Operations

• Base set

get-config, edit-config, copy-config, delete-config, get-state, kill-session

• Configuration locking supported

lock, unlock

• Configuration validation supported

validate

• Candidate configuration supported

commit, discard-changes

Low Level Standard Commands

191919

Protocol Operations: get-config

• Retrieve all or part of the specified configuration

• Parameters:

source: (@config-name)

config: (@element-tree | text)

format: (xml | text)

202020

Protocol Operations: get-config request

<rpc id="102">

<get-config>

<source><running></running></source>

<config xmlns="http://example.com/schema/v2.1/config">

<users></users>

</config>

<format>xml</format>

</get-config>

</rpc>

212121

Protocol Operations: get-config reply

<rpc-reply id="102“><get-config> <config xmlns="http://example.com/schema/v2.1/config"> <users> <user> <name>root</name> <type>superuser</type> </user> <user> <name>fred</name> <type>admin</type> </user> </users> </config></get-config>

</rpc-reply>

222222

Protocol Operations: get-config notes

• The element sub-tree specified in the <config> parameter is used to filter the response.

Multiple filter elements can be specified

Wildcard characters currently not supported in a standard way

Use of XPath subset being debated; More complicated but more standard and more powerful approach

• One or more namespace declarations (xmlns) must be included in the <config> parameter which correspond to the XML Schema defining the configuration commands used (unless format is text)

• Text format for <config> parameter allows CLI style ASCII instead of XML element tree

232323

Protocol Operations: edit-config

• Load all or part of a specified configuration to the designated target configuration.

• Parameters:

target: (@config-name)

test-option: (test-then-set | set) [default: set]

write-option: (merge | replace | overwrite) [default: merge]

error-option: (stop-on-err | ignore-err) [default: stop-on-err]

format: (xml | text)

config: (@URL | @config-name | @element-tree | text)

242424

Protocol Operations: edit-config request

<rpc id="101">

<edit-config>

<target><running></running></target>

<test-option>test-then-set</test-option>

<write-option>replace</write-option>

<error-option>stop-on-error</error-option>

<format>xml</format>

<config xmlns="http://example.com/schema/v1.2/config">

<interface name="Ethernet0/0">

<address>

<ipv4>1.2.3.4</ipv4>

<ipv4-mask>255.0.0.0</ipv4-mask>

</address>

</interface>

</config>

</edit-config>

</rpc>

252525

Protocol Operations: edit-config notes

• One or more namespace declarations (xmlns) must be included in the <config> parameter which correspond to the XML Schema defining the configuration commands used (unless format is text)

• Text format for <config> parameter allows CLI style ASCII instead of XML element tree

• The <config> parameter includes zero or more commands; could be an entire configuration file

262626

Protocol Operations: copy-config

• Overwrite the target configuration with the source configuration

• Parameters:

source: (@config-name | URL)

target: (@config-name | URL)

format: (xml | text)

• Restrictions

Remote to remote copy is not supported

Device may not support URL based source or target parameter

Device may restrict protocol types specified in URL

272727

Protocol Operations: copy-config request

<rpc id="103">

<copy-config>

<source>

<url>ftp://example.com/myconfig.txt</url>

</source>

<target><running></running></target>

<format>text</format>

</copy-config>

</rpc>

282828

Protocol Operations: copy-config

• <edit-config> is used to apply partial or complete configuration commands to the designated target configuration

Complex set options supported such as test-then-set or merge

• <copy-config> is used to overwrite a complete configuration file with a different complete configuration file

Hardwired set options (set without validation, replace, ignore errors)

edit-config and copy-config differences

292929

Protocol Operations: delete-config

• Remove a specific local configuration file

• Parameters:

target: (@config-name)

• Restrictions:

The running config cannot be deleted

The device may refuse to delete the startup config

303030

Protocol Operations: get-state

• Retrieve device state information

• Parameters:

state: (@element-tree | text)

format: (xml | text)

313131

Protocol Operations: get-state request

<rpc id="104">

<get-state>

<state xmlns="http://example.com/schema/v3.2/int-stats">

<interface name="ethernet0/1">

<statistics></statistics>

</interface>

</state>

<format>xml</format>

</get-state>

</rpc>

323232

Protocol Operations: get-state reply

<rpc-reply id="104"> <get-state> <state xmlns="http://example.com/schema/v3.2/int-stats"> <interface name="ethernet0/1“> <statistics> <inPkts>9456823</inPkts> <inOctets>1228484566</inOctets> <inErrors>4326</inErrors> <outPkts>4821050</outPkts> <outOctets>634712154</outOctets> <outErrors>2096</outErrors> </statistics> </interface> </state> </get-state></rpc-reply>

333333

Protocol Operations: lock, unlock

• Lock is used to prevent any other sessions from writing to a specific configuration

Applies to all access mechanisms, not just XMLCONF

Partial locks are not supported in v1.0

Can request automatic rollback on ungraceful unlock

• Unlock is used to release a previously obtained lock

• Lock can fail if:

Lock is already granted

Candidate configuration has already been written but not saved

• Lock automatically released if the session is terminated for any reason

• Kill-session operation used to force another session to release a lock

• Configuration name is the only parameter (in v1.0)

343434

Protocol Operations: validate

• Validate is used to check configuration commands before they are applied to the running configuration

• Applies to any configuration datastore

• Tests performed depend on the device

Syntax check is performed at a minimum

Referential check may be performed

Resource check may be performed

• Parameters:

source: (@config-name)

format: (xml | text)

353535

Protocol Operations: commit

• Commit operation activates candidate configuration

• Available if ‘candidate’ capability is supported

• Parameters:

confirmed: requires a confirming commit or commit will be backed out

confirmed-timeout: timeout period for confirmed commit, default is 10 minutes

363636

Protocol Operations: <rpc-error>

• <rpc-error> is inserted in <rpc-reply> if an error occurred

• Standard error message format (still TBD):

<rpc-error> <tag>UI_RANGE_ERROR</tag> <error-code>207</error-code> <severity>error</severity> <software-component>interface-daemon</software-component> <edit-path>interfaces so-0/0/0</edit-path> <statement>mtu 40000;</statement> <message>mtu exceeds allowable maximum</message> <action>discarded</action></rpc-error>

• Multiple error responses would be returned per request if applicable

373737

Protocol Operations

• Generic RPC provided to allow high-level operations, not replace low-level protocol operations

High level procedure such as ‘set-bgp-peer’

Function could be achieved with multiple low-level operations, but done as a high-level RPC for ease-of-use

• Example:

<rpc xmlns="http://ietf.org/xmlconf/1.0/rpc"> <my-own-method xmlns="http://example.net/me/1.0/my-own"> <my-first-parameter>14</my-first-parameter> <another-parameter>fred</another-parameter> </my-own-method></rpc>

High Level Remote Procedure Call

383838

Notifications

• An XMLCONF peer advertising the ‘notifications’ capability supports the notification channel

• Used for sending asynchronous messages

• <open-notifications> operation requests opening notification channel with specific parameters

format: rfc3195 is the only legal value (in v1.0)

• <close-notifications> requests that the notification channel be closed

393939

Standard Schema

• Version 1.0 will have some standard attributes

• Some attributes are needed for the protocol to function properly:

Show session information

Show lock information

List named configurations (name, size, last modified timestamp)

Show debug information (capabilities advertised, capabilities in use)

404040

Design Decisions

• RPC – Why not SOAP?

XMLCONF’s RPC is low overhead, easy to understand, implement, debug

SOAP’s interoperability value based on transport over HTTP – want XMLCONF transport over BEEP, SSH, console…

414141

Design Decisions

• Transport – Why BEEP first?

Connection oriented

Multi-channel capability

Simple and robust framing

Ability to initiate a connection from either end

424242

XMLCONF Summary

• Provides common operational framework for configuration management

• Focus on features needed for configuration, like locking and rollback, generic high-level RPC mechanism

• Support for simple transactions

Building block for network transactions

• Configuration model maps to real-world networks (candidate, running, startup)

434343

XMLCONF Summary

• Leverages existing standards

• Standard and proprietary XML content is supported

• Monitoring functions and notifications are supported, but protocol is not optimized for monitoring

• Hierarchical content filtering used instead of get-next

• Clear separation between configuration and state information