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

2. 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?

3. 333 Introduction March, 2001 OPS-NM Area Meeting Randy Bush asks crowd of 300 how many operators enable SNMP writes. Zero hands raised April, 2001 – May 2002 OPS-NM Road show visits Operators at RIPE, NANOG, LISA to determine network management needs June, 2002 IAB Workshop on Network Management Operators want better scripting tools; Interest in XML July, 2002 XMLCONF BOF at IETF #54 Well attended, lots of interest, but no concrete proposals November, 2002 Small team started by Margaret Wasserman to write XMLCONF I-D and attempt to get WG created History

4. 444 Introduction Andy Bierman Eliot Lear David Perkins Ted Goddard Phil Shafer Rob Enns Ken Crozier Steve Waldbusser Margaret Wasserman Team members (in no particular order)

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

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

7. 777 Protocol Layering XMLCONF BEEP TCP IP Initial Protocol Mapping Other transport mappings (SSH, …) can be defined

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

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

10. 10 RPC Mechanism Request on operations channel Reply sent on operations channel Provides progress reports (percentage completion) for long duration RPC operations, sent on the management channel Provides a way to abort an RPC in progress, or queued for processing, sent on the management channel Abort RPC reply, sent on the management channel XML Based Messages

11. 11 RPC Mechanism Included in if an error occurs during processing of an RPC request Included in if no error occurred during processing of an RPC request Error reporting

12. 12 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 http:/ietf.org/xmlconf/1.0/base http:/ietf.org/xmlconf/1.0/base#notifications http:/ietf.org/xmlconf/1.0/base#candidate http:/ietf.org/xmlconf/1.0/base#lock At least 1 version of the base protocol must be advertised Vendor specific capabilities may also be advertised http:/example.com/xmlconf/1.0/extensions Base protocol + optional capabilities

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

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

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

16. 16 Operational Model candidaterunningstartup Configuration datastores Different variants of this model are possible

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

19. 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. 20 Protocol Operations: get-config request xml

21. 21 Protocol Operations: get-config reply root superuser fred admin

22. 22 Protocol Operations: get-config notes The element sub-tree specified in the 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 parameter which correspond to the XML Schema defining the configuration commands used (unless format is text) Text format for parameter allows CLI style ASCII instead of XML element tree

23. 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. 24 Protocol Operations: edit-config request test-then-set replace stop-on-error xml 1.2.3.4 255.0.0.0

25. 25 Protocol Operations: edit-config notes One or more namespace declarations (xmlns) must be included in the parameter which correspond to the XML Schema defining the configuration commands used (unless format is text) Text format for parameter allows CLI style ASCII instead of XML element tree The parameter includes zero or more commands; could be an entire configuration file

26. 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. 27 Protocol Operations: copy-config request ftp://example.com/myconfig.txt text

28. 28 Protocol Operations: copy-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 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

29. 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. 30 Protocol Operations: get-state Retrieve device state information Parameters: state: (@element-tree | text) format: (xml | text)

31. 31 Protocol Operations: get-state request xml

32. 32 Protocol Operations: get-state reply 9456823 1228484566 4326 4821050 634712154 2096

33. 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. 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. 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. 36 Protocol Operations: is inserted in if an error occurred Standard error message format (still TBD): UI_RANGE_ERROR 207 error interface-daemon interfaces so-0/0/0 mtu 40000; mtu exceeds allowable maximum discarded Multiple error responses would be returned per request if applicable

37. 37 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: 14 fred High Level Remote Procedure Call

38. 38 Notifications An XMLCONF peer advertising the ‘notifications’ capability supports the notification channel Used for sending asynchronous messages operation requests opening notification channel with specific parameters format: rfc3195 is the only legal value (in v1.0) requests that the notification channel be closed

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