Subject: RE: NETCONF Notifications: Consensus Points

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 29 Nov 2005 09:59:05 -0500

<Andy>
Notification Info Model/Payload

  There is WG consensus to reuse syslog classification, although
  the ability to transfer additional user data (similar to the OBJECTS
  clause in an SNMP notification) is also required.  The option
  of asking the SYSLOG WG for enhancements to RFC 3195 is also
  possible, and some WG members prefer this approach if syslog
  is going to be enhanced in any meaningful way.
</Andy>

This one I think requires more discussion before we can declare some
consensus. I think there is a general sense that there is something from
the land of syslog that we want to take advantage of and learn from, but
I have not seen strong consensus as to what that is. And which version
of syslog are people looking to leverage? 

I think being able to tunnel syslog content into netconf is good for
transitioning and our internet draft discusses this a bit in one of the
appendices. What is more interesting though, is some of the SD-Params we
have developed in syslog. I think bringing these in, not using SD-Param
grammar, but as properly tagged XML would be very very useful.

Sharon

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Nov 2005 08:42:04 -0800

>grammar, but as properly tagged XML would be very very useful.

I think this WG is a little better at discussing detailed text
than abstract concepts.  I suppose we will know which
fields people agree on when we get down in the details
and hammer out every option of every feature from top
to bottom and back again.

So go ahead and write up details for SD-Params if you want.
At this point there isn't WG consensus for any particular
field of any message over any transport. 

However several people have expressed concern over reinventing
syslog or SNMP Notifications, and this will be a factor in the process.

>Sharon

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Nov 2005 17:25:25 -0500

"Sharon Chisholm" writes:
>I think bringing these in, not using SD-Param

XML has its uses, but log data is not one of them.  We need to be
careful that we don't start seeing everything as a nail to our xml
hammer.

XML is useful for encoding hierarchical data, but is horrible for
simple flat data (try encoding a csv file in xml).  XML is good at
encoding data that is highly variable, but expensive for more
normalizable data.  XML is great for data interchange, where both
sides of the conversation need to be flexible and resilient.  But
it's horrible for data storage.  XML's overhead can be ignored for
intermittent operations like configuration requests, but will kill
you at high volume.

Compare a notification in XML:

    <notification>
      <time seconds=234532455432345>Oct 18 16:01:37</time>
      <tag>RPD_RSVP_NBRUP</tag>
      <hostname>my-host</hostname>
      <process pid=2958>rpd</process>
      <data>
        <neighbor>10.5.14.2</neighbor>
        <interface>fe-1/3/0.0</interface>
      </data>
      <message>RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0</message>
    </notification>

and the same data in syslog:

Oct 18 16:01:37  my-host rpd[2958]: RPD_RSVP_NBRUP: RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0

The syslog-SD form of this would be something like:

1 888 4 00 2005-10-18-16:01:37 my-host rpd 2958 RPD_RSVP_NBRUP [JNPR-0 neighbor="10.5.14.2" interface="fe-1/3/0.0"] RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0

(That should be close enough; I'm not an SD-guru)

wc -c reports the lengths as 321, 104, and 168.

I take it as a given that customers will use notification data from
netconf in the same pattern we see with syslog data.  They configure
large volumes of data, which they store and use to investigate
problems, either real-time or port-mortem.

IMHO, the SD-PARAM version wins hands down, based on functionality
.vs.  footprint.  I can filter by severity, date, msgid, and message
content parameters.  That's pretty much all I'm after.

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 30 Nov 2005 08:45:25 +0100

As the draft already indicated there are multiple reasons to send a notification.
For information messages where the manager's main activity is just to store the content a 
concise format is the way to go.
On the other hand a fault or maintenance type notification might result in further 
processing and actions so these should be kept in a structured XML format.
Balazs

---

From: Phil Shafer <[email-masked]>
Date: Wed, 30 Nov 2005 10:42:20 -0500

>processing and actions so these should be kept in a structured XML format.

What does XML give you here that SD wouldn't?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Nov 2005 08:26:25 -0800

>What does XML give you here that SD wouldn't?

An encoding that a wide variety of tools support for NMS development.
That is the rationale that got us started with XML in the first place.
It is important to lots of people.

However, I sort of agree with you.  The history of tools development
is one of putting up with the deficiencies of the "current approach"
until something better comes along.

In this case, all XML buys you is the encoding of the individual message 
fields,
which is a small fraction of the work needed to do anything interesting with
the data (I submit that a log-dumper doesn't qualify as interesting).
But -- this is a lot more than nothing -- if you don't really care about
the 2X or 3X in encoding size overhead.

I wonder if  the "dual syntax" approach of RelaxNG (XML and Compact syntax)
would work here?  Sharon's suggestion of an XML format could coexist with
this one,  if someone did all the work to spec it out. 

The problem with your theory is the premise that people using XML care about
encoding and transfer efficiency.  It would hard to come up with a
syntax that was more verbose or more complicated to encode/decode
than XML.  It's not built for speed.  (Not built for comfort either ;-)

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 30 Nov 2005 11:47:21 -0500

Andy Bierman writes:
>encoding and transfer efficiency.

Well, my theory is that operators save lots of log data and won't
be happy about a 3x xml tax.  They then inspect log files, where
filtering is invaluable.  They want the juice, but in a cheaper
form.  Syslog w/ SD-Params fills the need without filling your
log servers.

FWIW, I take it as a given that they'll go crazy over SD data, but
that's a point that should be verified.  I know I'm drooling over it.

>It's not built for speed.  (Not built for comfort either ;-)

Yup, Willie Dixon would not be caught dead playing with XML.

Thanks,
 Phil

---

From: Chris Elliott <[email-masked]>
Date: Wed, 30 Nov 2005 11:53:18 -0500 (EST)

> form.  Syslog w/ SD-Params fills the need without filling your

CPU is still considerably cheaper than disk in most cases, so compress the 
files. My experience leads me to believe that both formats will compress 
to a at least close to the same size.

As far a efficiency over the wire, network management traffic is such a 
small fraction of the total these days that I don't think anyone's too 
worried about increasing it, even a fair amount.

I'd rather not have to deal with two formats--and, yes, certain apps will 
have to deal with both formats and will have to try to resolve what a 
particular SD-Param relates to in XML, or the SNMP MIB, or CLI...We have 
enough formats already.

Chris.

> Yup, Willie Dixon would not be caught dead playing with XML.

Chris Elliott  CCIE# 2013       |         |
Customer Diagnostic Engineer   |||       |||
RTP, NC, USA                  |||||     |||||
919-392-2146              .:|||||||||:|||||||||:.
[email-masked]        c i s c o S y s t e m s

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 30 Nov 2005 12:04:22 -0500

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Chris Elliott
>
I concur

David Harrington
[email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 30 Nov 2005 17:20:44 +0100

I feel it is easier to separate the different fields in XML.
Balazs