Netconf%20Monitoring

1
Netconf Monitoring

• IETF 70
• Mark Scott markscot_at_nortel.com
• Sharon Chisholm schishol_at_nortel.com
• Hector Trevino htrevino_at_cisco.com

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

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

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

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