Subject: Re: [NGO] NETCONF monitoring schema

From: Martin Bjorklund <[email-masked]>
Date: Tue, 07 Aug 2007 14:20:28 +0200 (CEST)

Hi,

As input to the monitoring schema discussions, here's the statistics
schema we have.

(the format is our DML; you can view it as pseudo-XSD)

/martin

   <elem name="sessions">
      <desc>
	A list of the currently active user sessions in the system.
      </desc>
      <elem name="session" minOccurs="0" maxOccurs="unbounded">
	<elem name="id" type="SessionId" key="true"/>
	<elem name="user" type="xs:string"/>
	<elem name="srcIp" type="confd:inetAddressIP"/>
	<elem name="context" type="contextType"/>
	<elem name="protocol" type="protocolType"/>
	<elem name="login" type="xs:dateTime"/>
	<elem name="locks">
	  <desc>
	    A list of the locks currently held by the session.
	  </desc>
	  <elem name="lock" minOccurs="0" maxOccurs="unbounded">
	    <!-- Use a idx as key instead of the config name; this is
	         to allow for future partial locks. -->
	    <elem name="idx" type="xs:unsignedInt" key="true"/>
	    <elem name="configName" type="configNameType"/>
	  </elem>
	</elem>
      </elem>
    </elem>

   <elem name="statistics">
      <elem name="inSessions" type="xs:unsignedInt">
	<desc>
	  The total number of NETCONF sessions started towards the
	  NETCONF peer.
	  inSessions - inBadHellos = 
              'number of correctly started netconf sessions'
	</desc>
      </elem>
      <elem name="inXMLParseErrs" type="xs:unsignedInt">
	<desc>
	  The total number of messages that were unparsable and thus
	  ignored.  This covers both unparsable 'hello' and 'rpc'
	  messages.
	</desc>
      </elem>
      <elem name="inBadHellos" type="xs:unsignedInt">
	<desc>
	  The total number of sessions silently dropped because an
	  invalid 'hello' message was received.  This includes hello
	  messages with a 'session-id' attribute, bad namespace, and
	  bad capability declarations.
	</desc>
      </elem>
      <elem name="inRpcs" type="xs:unsignedInt">
	<desc>
	  The total number of rpc requests received.
	</desc>
      </elem>
      <elem name="inBadRpcs" type="xs:unsignedInt">
	<desc>
	  The total number of rpcs which were parsed correctly, but
	  couldn't be serviced because they contained non-conformant XML.
	</desc>
      </elem>
      <elem name="inNotSupportedRpcs" type="xs:unsignedInt">
	<desc>
	  The total number of rpcs which were parsed correctly, but
	  couldn't be serviced because they were not supported by the
	  agent.
	</desc>
      </elem>
      <elem name="outRpcReplies" type="xs:unsignedInt">
	<desc>
	  The total number of 'rpc-reply' messages sent.
	</desc>
      </elem>
      <elem name="outRpcErrors" type="xs:unsignedInt">
	<desc>
	  The total number of 'rpc-reply' messages with 'rpc-error'
	  sent.
	</desc>
      </elem>
      <elem name="outNotification" type="xs:unsignedInt">
	<desc>
	  The total number of 'notification' messages sent.
	</desc>
      </elem>
    </elem>

  <xs:simpleType name="protocolType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="console"/>
      <xs:enumeration value="tcp"/>
      <xs:enumeration value="ssh"/>
      <xs:enumeration value="ssl"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType name="contextType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="cli"/>
      <xs:enumeration value="netconf"/>
      <xs:enumeration value="webui"/>
    </xs:restriction>
  </xs:simpleType>

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Aug 2007 11:45:45 -0700

> (the format is our DML; you can view it as pseudo-XSD)

It looks close enough to XSD that I was fooled into
thinking I was reading XSD.  Then I noticed it was too easy
to understand to be XSD ;-)

Is there enough interest in this work to
standardize a NETCONF protocol monitoring schema?
I am counting almost the same things, although with different
names and data types.

> /martin

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 9 Aug 2007 11:03:52 +0200

Let me play the devil's advocate: 

- why do we need to monitor NETCONF using NETCONF? 
- how efficient using NETCONF can be? 
- why not use SNMP? :-)

Dan

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Wednesday, August 08, 2007 9:46 PM
> To: Martin Bjorklund
> Cc: [email-masked]
> Subject: Re: [NGO] NETCONF monitoring schema
> 
> Martin Bjorklund wrote:
> > Hi,
> > 
> It looks close enough to XSD that I was fooled into thinking 
> I was reading XSD.  Then I noticed it was too easy to 
> understand to be XSD ;-)
> 
> Is there enough interest in this work to standardize a 
> NETCONF protocol monitoring schema?

---

From: Andy Bierman <[email-masked]>
Date: Thu, 09 Aug 2007 04:22:35 -0700

> - why do we need to monitor NETCONF using NETCONF? 

It is of minor value during initial deployment,
but we are in the initial deployment phase.

> - how efficient using NETCONF can be? 

It's just a sub-tree of monitoring data and the <get>
operation is all that is needed to support it.

> - why not use SNMP? :-)

The mandatory components of NETCONF completely support
all the feature requirements.  Adding an SNMP stack
to retrieve some monitoring data is all overhead.

Also the point of the <get> operation is that the manager
needs to monitor the agent with the same data organization
and data naming that is used for configuration.

Since most configuration maps to CLI, not SMI, there is
a major data model mismatch that first must be solved in order
to even use SNMP.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 09 Aug 2007 16:25:39 +0200

Hello,
See below.
Balazs

> - why do we need to monitor NETCONF using NETCONF? 
- to allow management SW to make sophisticated decisions based on the state of Netconf
- to allow the troubleshooting of Netconf and Access control configuration and some 
connectivity problems (e.g. why doesn't my newly installed manager receive notifications)
- to allow the debugging of Netconf SW
> - how efficient using NETCONF can be? 
We are speaking of limited amounts of data, that is read only occasionally and usually not 
periodically. If we add statistics to the model, we should consider making it available in SNMP 
as well. Is there an underlying assumption here: statistics shall be collected by SNMP, not 
Netconf?
> - why not use SNMP? :-)
We do not want to force manager applications to have an SNMP stack beside the Netconf stack. We 
do not say don't use SNMP.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 9 Aug 2007 18:11:22 +0200

> From: Balazs Lengyel [mailto:[email-masked]] 

...

> Romascanu, Dan (Dan) wrote:

...

> - to allow management SW to make sophisticated decisions based on the
state of Netconf

...

> We are speaking of limited amounts of data, that is read only 
> occasionally and usually not periodically. If we add 
> statistics to the model, we should consider making it 
> available in SNMP as well. Is there an underlying assumption 
> here: statistics shall be collected by SNMP, not Netconf?

It depends who you ask. 

We are missing a multi-protocol management framework. Actually we
missing a NETCONF-based management framework as well. In the absence of
the above the default management framework in the IETF is SNMP-based,
with NETCONF being added for configuration management operations,
because of a set of problems that were identified when it comes to
configuration by SNMP. 

The data models that I am seeing already contain some statistics. I
doubt that 'limited amounts of data' ... 'read only occasionally' are
good enough to 'allow management SW to make sophisticated decisions
based on the state of Netconf'. So what are we left with? 

Dan