1. draft-shafer-netconf-syslog-00.txt Phil Shafer July 2006 IETF 66, Montreal

2. SYSLOG over NETCONF SYSLOG is the most prevalent mechanism for delivering event notification data off networking devices –SD-Params are completely cool (name=value pairs) Use existing NETCONF RPC constructs –To carry SYSLOG event streams Work the way operators work –Support their most common usage scenarios "What just happened to my box?" (history) "What's going on with my box"? (live feed)

3. Event Streams View SYSLOG data as a stream of events Streams are filtered subsets of events Configured on the device –Gives the device control over what apps see Additional filters can be imposed by client Multiple streams Recorded historical data (log files) Live data feed, as the events are generated

4. c1 c2 c3 cn SYSLOG server NETCONF server NETCONF client Remote SYSLOG Receiver Historical Repository System components … Remote SYSLOG sender SYSLOG NETCONF

5. Two RPCs One lists the available streams –get-syslog-streams One gets events from a stream –get-syslog-events get-syslog-events RPC is long-lived –Completes if/when termination conditions are met stop-time or count –Potentially open-ended response data

6. get-syslog-streams messages traditional

7. get-syslog-events <get-syslog-events xmlns="http://ietf.org/netconf/syslog/1.0 messages daemon emergency ^User 'r.*' logout$ mgd UI_CHILD_START username=regress input=configure authentication-level=super-user signal-name=Broken pipe 2006-5-31.12:10:00 100

8. get-syslog-events reply 1 2006-06-14T08:29:14.397+05:30 kitkat mgd 3993 UI_CHILD_START [junos@2636.1.1.1.2.13 command="/sbin/ifinfo"] Starting child '/sbin/ifinfo' 1 2006-06-14T08:29:14.417+05:30 kitkat mgd 3993 UI_CHILD_STATUS [junos@2636.1.1.1.2.13 command="/sbin/ifinfo" process-id="3996" status="0"] Cleanup child '/sbin/ifinfo', PID 3996, status 0

9. Simplicity –Simple to understand, to implement, and to adopt Power –Rich set of SYSLOG content Availability –Uses existing NETCONF concepts –Nothing wild here Future –Proof we can use our existing RPC mechanism

10. Issues Specificity of API –.vs. SYSLOG specific –Not a generic notification framework Use of RPCs Needs a complete configuration data model

11. .vs. Make real APIs –API method as a first class construct –Parameters are important Don’t' stuff meaningful parameters into Specificity: ioctl().vs. tcgetattr().vs. makeraw()? The socket library gives generic calls –But they perform specific functions –bind(), not ioctl(fd, SIOCBIND, &addr) Some balance is required

12. Cost of s NETCONF works to leverage the content and availability of the CLI Different than config data Mapping between filter expressions and the commands that generate them isn't trivial Working backward will be painful to learn and maintain

13. Cost of s (cont) "show interfaces statistics" makes interface-information/physical-interface/traffic-statistics "show interfaces media" makes interface-information/physical-interface/ethernet-mac-statistics Add in parameter substitution: "show interfaces so-0/0/0" interface-information/physical-interface[name="s0-0/0/0] /ethernet-mac-statistics

14. SYSLOG specific Richest content available Definite need to handle other types of notifications (snmp and syslog varients) Can it be done without tossing all the details into "void" parameters?

15. Use of RPCs Use the existing RPC mechanism Devote a channel to the RPC If you want to change, open a new channel Avoid investing a lot of energy in corner cases Simple wins

16. Complete Data Model NETCONF modeling isn't even in its infancy –Needs lots of work Do we want to wait? –If so, let's stop talking about notifications and get to work on modeling Data modeling is not a simple problem

17. Conclusion A million ways to skin a cat, but the cat won't enjoy any of them Complexity kills