Netconf Event Notifications IETF 66 Sharon Chisholm Hector Trevino

Outline Key Features Architecture Requirements Issues Bugs

Key Features Clean subscribe/unsubscribe to notifications of interest Modification of subscription without loss of notifications Event Classes to enable ‘big bucket’ filtering Ability to carry Netconf-content

Netconf Layers Layer Example | Content | | Configuration data | | | | Operations | |, | | | | | | RPC | |, | | | | | | | Application | | BEEP, SSH, SSL, console | | Protocol | | |

An Architecture | Network Element | | | | | Alarm | | | | Management | | | |--->|Netconf Stack | | Netconf | | | | | | | | | | | | | --->| Client | | V | | | | | | | | | Event |--->| | | | | Management | | |Other Protocols | | | | |--->| | | | | | | | | | | | Network Element | | | | | | | Alarm | | | | | Management | | | | |--->|Netconf Stack |< | | | | | | | | | | | | V | | | | | | | Event |--->| | | | Management | | |Other Protocols | | | |--->| | | | | |

Message Flow C S | | | capability exchange | | >| | | | >| |< | | | |< | | | |< | | | | >| (buffered) | | |< | | | |< |

Message Format ___________________________________________________________________ || Notification Header || Data | ||__________________________________________________________||______| || subscriptionId| eventClasses| sequenceNumber| dateAndTime|| | ||_______________|_____________|_______________|____________||______|

Requirements NumberRequirementCompliance 1Initial release should ensure it supports notification in support of configuration operations Has event classes for configuration as well as to be able to report security audit logs 2Data content must be use the same data model as used in configuration Allows user to use the same data model (content) within both configuration commands and notifications 3solution should support structured hierarchical dataAble to support anything that can be modeled in XML. 4solution should be able to carry configuration fragments The configuration event class covers sending configuration fragments 5 solution should support a reasonable message size limit (syslog and SNMP are rather constrained in terms of message sizes) Currently no restrictions on message size 6 solution should provide reliable delivery of notifications Delivery is over SSH. The primary mechanism is reliable, but callHome method is not. 7 solution should support preconfigured notification destinations Not in the primary solution, but the callHome one does 8 solution should support agent initiated connections Not in the primary solution, but the callHome one does

Requirements NumberRequirement Compliance 9 solution should provide a subscription mechanism full 10 solution should support multiple subscriptions full 11 solution should provide a filtering mechanism Based on netconf subtree and/or xpath 12 solution should support notification names The name of the notification is defined by its path, but this is not currently included in the notification header. This can be easily added. 13 solution should support notification timestamps full 14 solution should support notification classes full 15 solution should support notification info There is the data field, although B 16 solution should provide the ability to specify the content of notifications to ensure predictability Notifications are identified within an XML Schema via an attribute.

Requirements NumberRequirementCompliance 17 solution should send sufficient information in a notification so that it can be analyzed independent of the transport mechanism I’m interpretting this to mean that the header and the content should tell you everything and you shouldn’t need to know which session and what happened recently on that session in order for all this to work 18 solution should allow notifications to refer to prior configuration change RPCs The configuration event class can do this, although the details of what specifically is in the data bit hasn’t been specified. Do we really mean to refer to the RPC or the content of the RPC? 19 solution should not bind subscriptions to a connection Main method does (it’s a feature ). Can define subscription information in a named profile for re-use and can use callHome feature if that fits your operational model 20 channels for configuration change notifications should share fate with a session that includes a configuration channel I’m not sure what that means. You can do the configuration changes on the same connection. Subscription connections, if not callHome, behave the same as configuration connections

Requirements NumberRequirementCompliance 21 solution should support replay of locally logged notifications This isn’t included in the draft, but replay had been fully designed from day one to ensure it wouldn’t cause issues when added. This design can be made available. 22 solution should support message chunking capability in cases channels carry mixed RPCs Each notification is a well-formed document, but a large notification can’t be broken into smaller pieces. 23 solution should scale to nodes which may emit notifications Don’t yet have engineering numbers for management software. This really depends on the volume of notifications expected from each node. 24 solution should scale to order nodes to send notifications How does this differ from 23?

Issues - Big Endless RPC versus Notifications Syslog Tunnelling versus Notification Framework

Issues – Less Big Best way to have initial set up event classes while allowing extensibility  Create separate Event Class document? More details of callHomeNotifications

Bugs Missing ‘data’ element from Notification XSD definition