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

System components c1 c2 c3 … cn

Historical Repository SYSLOG

Remote SYSLOG Receiver SYSLOG server

NETCONF server NETCONF NETCONF client

Remote SYSLOG sender

SYSLOG

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 reply

1 2006-06-14T08:29:14.397+05:30 kitkat mgd 3993 UI_CHILD_START [[email protected] command="/sbin/ifinfo"] Starting child '/sbin/ifinfo' 1 2006-06-14T08:29:14.417+05:30 kitkat mgd 3993 UI_CHILD_STATUS [[email protected]

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