1. Netconf Monitoring IETF 70 Mark Scott markscot@nortel.commarkscot@nortel.com Sharon Chisholm schishol@nortel.comschishol@nortel.com Hector Trevino htrevino@cisco.comhtrevino@cisco.com

2. 2 Draft status Original draft expired draft-chisholm-netconf-monitoring-01.txt discussed at IETF69 Updated draft available as draft-scott-netconf-monitoring-00.txt updates on next slide

3. 3 Problem Statement No standard method to monitor NETCONF protocol, including session information lock information As NETCONF adds increasing capabilities which can impact configuration management, monitoring becomes increasingly important Examples: Fine-grain locking Impacts/Shortcomings Certain configuration is ‘best-effort’ with failures detected during transactions pessimistic locking is acceptable workaround in some cases Interoperability and Tools development is complicated Multi-vendor, large scale networks require vendor specific monitoring This draft provides basic monitoring for base NETCONF, sessions and notifications intended to alleviate the specific shortcomings above

4. 4 netconfState (overview) The monitored data capabilities: Netconf capabilities supported sessions: All active sessions on device configurations: Netconf datastores (running, startup, candidate) subscriptions: Active netconf notification subscriptions ComplexType: ManagementSessionInfo ComplexType: ConfigurationDatastoreInfo ComplexType: NetconfSubscriptionInfo

5. 5 Use Cases There are a number of cases where the success of NETCONF configuration attempts could benefit from the monitoring schema proposed in this draft The following are some cases where specific information in this monitoring schema could provide increased usability increase configuration attempt success rate ease implementation increase interop aid debugging

6. 6 ManagementSessionInfo Lack of monitoring prohibits pro-active decision making Requires knowledge of all sessions (not just netconf) that can change data store Eg: Session monitoring allows detection for exclusive access where required, rather than failing on attempt to commit changes Allows manager to make contextual decisions Eg: may want to restrict craft console disabling if console sessions are active Username, sourceIdentifier, loginTime: Eg: identify another user of system before terminating their session or distinguish machine session from human session Unique session identifier Console, ssh, ssl, etc Netconf, CLI, Web UI, etc Originator of the session Session owner Session start time

7. 7 ConfigurationDatastoreInfo Allows manager to stage large scale network updates Eg: Perform an audit prior to a bulk operation to ensure all nodes have prerequisite candidate configuration available May need to handle cases where data store handling differs, requiring monitoring of current configuration states Eg: some devices couple startup & candidate locking Eg: some devices have limitations on number of candidates Configuration name Candidate, startup, etc Locked or unlocked

8. 8 Updates since IETF69 As result of mailing list discussion following changes have been made to draft Modified some complex datatypes bug fixes, more flexible types Increased scope to monitor non-Netconf sessions Added monitoring of additional data, including Transport Session types Source identifier Data store type

9. 9 Next Steps Move this draft to be a working group document to address current updated charter item on NETCONF Monitoring Subject to agreement, update draft as consensus is reached on Content Datatypes used in the schema, including  sessionType  srcIdentifer (esp. IP address datatype)