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

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)

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

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

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

get-syslog-streams messages traditional

get-syslog-events <get-syslog-events xmlns=" messages daemon emergency ^User 'r.*' logout$ mgd UI_CHILD_START username=regress input=configure authentication-level=super-user signal-name=Broken pipe :10:00 100

get-syslog-events reply T08:29: :30 kitkat mgd 3993 UI_CHILD_START command="/sbin/ifinfo"] Starting child '/sbin/ifinfo' T08:29: :30 kitkat mgd 3993 UI_CHILD_STATUS command="/sbin/ifinfo" process-id="3996" status="0"] Cleanup child '/sbin/ifinfo', PID 3996, status 0

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

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

.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

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

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

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?

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

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

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