XMLCONF

1. XMLCONF Topics • Introduction • Strategy • Protocol Layering • Session Management • RPC Mechanism • Capabilities Exchange • Operational Model • Protocol Operations • Standard Schema • Design Decisions

2. Introduction What is XMLCONF? • 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

3. Introduction History • 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

4. Introduction Team members (in no particular order) • 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>

5. 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

6. 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

7. Protocol Layering Initial Protocol Mapping Other transport mappings (SSH, …) can be defined

8. Protocol Layering Functional Layers • 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

9. Session Management Channels • 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

10. RPC Mechanism XML Based Messages • <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

11. RPC Mechanism Error reporting • <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

12. Capabilities Exchange Base protocol + optional capabilities • 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>

13. Capabilities List Initial set • 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

14. Operational Model: Concepts Basic framework 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

15. Operational Model: Datastores Special configuration 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

16. Operational Model Configuration datastores candidate running startup • Different variants of this model are possible

17. 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

18. Protocol Operations Low Level Standard Commands • 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

19. Protocol Operations: get-config • Retrieve all or part of the specified configuration • Parameters: • source: (@config-name) • config: (@element-tree | text) • format: (xml | text)

20. 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>

21. 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>

22. 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

23. 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)

24. 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>

25. 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

26. 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

27. 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>

28. Protocol Operations: copy-config edit-config and copy-config differences • <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)

29. 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

30. Protocol Operations: get-state • Retrieve device state information • Parameters: • state: (@element-tree | text) • format: (xml | text)

31. 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>

32. 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>

33. 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)

34. 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)

35. 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

36. 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

37. Protocol Operations High Level Remote Procedure Call • 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>

38. 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

39. 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)

40. 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…

41. Design Decisions • Transport – Why BEEP first? • Connection oriented • Multi-channel capability • Simple and robust framing • Ability to initiate a connection from either end

42. 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)

43. 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