draft-shafer-netconf-syslog-00.txt

1
draft-shafer-netconf-syslog-00.txt

• Phil Shafer ltphil_at_juniper.netgt
• 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 (namevalue 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
System components
Remote SYSLOG Receiver
SYSLOG
c1
SYSLOG server
c2
NETCONF server
c3
NETCONF client
NETCONF

cn
Historical Repository
Remote SYSLOG sender
SYSLOG
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
ltrpc xmlns"urnietfparamsxmlnsnetconfbase1.
0"gt ltget-syslog-stream xmlns"http//ietf.org
/netconf/syslog/1.0"/gt lt/rpcgt ltrpc-reply
xmlns"urnietfparamsxmlnsnetconfbase1.0"gt
ltsyslog-streams xmlns"http//ietf.org/netco
nf/syslog/1.0"gt ltstreamgt
ltnamegtmessageslt/namegt ltrecording/gt
ltformatgttraditionallt/formatgt
ltpriority facility"" level"notice"/gt
ltpriority facility"kern" level"debug"/gt
lt/streamgt lt!- --gt
lt/syslog-streamsgt lt/rpc-replygt
7
get-syslog-events
ltrpc xmlns"urnietfparamsxmlnsnetconfbase1
.0"gt ltget-syslog-events xmlns"http//ietf.
org/netconf/syslog/1.0
ltstreamgtmessageslt/streamgt
ltfacilitygtdaemonlt/facilitygt
ltseveritygtemergencylt/severitygt
lttext-patterngtUser 'r.' logoutlt/text-patterngt
ltprocessgtmgdlt/processgt
lteventgtUI_CHILD_STARTlt/eventgt
ltattributesgtusernameregresslt/attributesgt
ltattributesgtinputconfigurelt/attributesgt
ltattributesgtauthentication-levelsuper-userlt/
attributesgt ltattributesgtsignal-nameBro
ken pipelt/attributesgt
ltstart-timegt2006-5-31.121000lt/start-timegt
ltcountgt100lt/countgt lt/get-syslog-eventsgt
lt/rpcgt
8
get-syslog-events reply
ltrpc-reply xmlns"urnietfparamsxmlnsnetcon
fbase1.0"gt ltsyslog-events
xmlns"http//ietf.org/netconf/syslog/1.0"gt
ltsyslog-eventsgt ltdatagt 1
2006-06-14T082914.3970530 kitkat mgd 3993
UI_CHILD_START junos_at_2636.1.1.1.2.13
command"/sbin/ifinfo" Starting
child '/sbin/ifinfo' lt/datagt
ltdatagt 1 2006-06-14T082914.41705
30 kitkat mgd 3993 UI_CHILD_STATUS
junos_at_2636.1.1.1.2.13
command"/sbin/ifinfo" process-id"3996"
status"0" Cleanup child
'/sbin/ifinfo', PID 3996, status 0
lt/datagt lt/syslog-eventsgt lt/rpc-replygt
9
ltinsert-convincing-argument-heregt

• 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
• ltget-syslog-streamsgt .vs. ltgetgt
• SYSLOG specific
• Not a generic notification framework
• Use of RPCs
• Needs a complete configuration data model

11
ltget-syslog-streamsgt .vs. ltgetgt

• Make real APIs
• API method as a first class construct
• Parameters are important
• Dont' stuff meaningful parameters into ltfiltergt
• 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 ltfiltergts

• 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 ltfiltersgts (cont)

• "show interfaces statistics" makes
  interface-information/physical-interface/traffic-s
  tatistics
• "show interfaces media" makes
  interface-information/physical-interface/ethernet-
  mac-statistics
• Add in parameter substitution
• "show interfaces so-0/0/0"
• interface-information/physical-interfacen
  ame"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