Subject: [netmod] any guidelines for statistics data model

From: "Shitanshu Shah (svshah)" <[email-masked]>
Date: Thu, 16 Apr 2015 16:41:04 +0000

Hi,

Am curious to know if there is any guidelines on how stats to be modeled? I understand that one style may not fit all but at the least for consistency across different technologies if there is any list defined from which is the best preferred approach to the least preferred?

Like from one extreme, embedding stats in each config container, to another extreme, each vendor to implement its own RPC?

We are working on a diffserv data model and one specific aspect of this model is that there is a config model to define a template which then associated, by reference of a template name, to different interfaces. The stats requirement is for each interface relevant instance in this case and thus embedding stats in the config template not sure make sense.

Thus we may have options of either 1) define separate (separate from config) model for stats with the same key definition but stats model is then used directly under interface or 2) use of RPC

Regards,
Shitanshu

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Apr 2015 20:28:18 +0200

> Thus we may have options of either 1) define separate (separate from config) model for stats with the same key definition but stats model is then used directly under interface or 2) use of RPC

If stats are associated with an interface, they should be modeled as
such, i.e., augment them at an apropriate place into the
/interface-state tree.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Anees Shaikh <[email-masked]>
Date: Thu, 16 Apr 2015 12:02:56 -0700

I suggest you have a look at draft-openconfig-netmod-opstate-00, which
describes an operational perspective on how to represent state (including
stats/counters) in a consistent way using current YANG constructs.

thanks.
-- Anees

On Thu, Apr 16, 2015 at 11:28 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > Am curious to know if there is any guidelines on how stats to be
> modeled? I understand that one style may not fit all but at the least for
> consistency across different technologies if there is any list defined from
> which is the best preferred approach to the least preferred?
> >
> > Like from one extreme, embedding stats in each config container, to
> another extreme, each vendor to implement its own RPC?
> >
> > We are working on a diffserv data model and one specific aspect of this
> model is that there is a config model to define a template which then
> associated, by reference of a template name, to different interfaces. The
> stats requirement is for each interface relevant instance in this case and
> thus embedding stats in the config template not sure make sense.
> >
> > Thus we may have options of either 1) define separate (separate from
> config) model for stats with the same key definition but stats model is
> then used directly under interface or 2) use of RPC
> >
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Apr 2015 12:24:29 -0700

On Thu, Apr 16, 2015 at 9:41 AM, Shitanshu Shah (svshah)
<[email-masked]> wrote:
>
> Hi,
>
> Am curious to know if there is any guidelines on how stats to be modeled? I
> understand that one style may not fit all but at the least for consistency
> across different technologies if there is any list defined from which is the
> best preferred approach to the least preferred?
>
> Like from one extreme, embedding stats in each config container, to another
> extreme, each vendor to implement its own RPC?
>

You are mixing 2 different issues:

  1) data organization: where should the operational data be located
      relative to other data nodes in the system

  2) protocol mechanism: should standard <get> be used or
      separate <get-foo>, <get-bar> operations be used?

For 1) I prefer the least amount of redundant information and implementation.
For 2) I prefer standard <get>

Andy

> Thus we may have options of either 1) define separate (separate from config)
> model for stats with the same key definition but stats model is then used
> directly under interface or 2) use of RPC
>
> Regards,
> Shitanshu
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Apr 2015 21:29:02 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> > modeled? I understand that one style may not fit all but at the least
> > for consistency across different technologies if there is any list
> > defined from which is the best preferred approach to the least
> > preferred?
> > 
> > We are working on a diffserv data model and one specific aspect of
> > this model is that there is a config model to define a template which
> > then associated, by reference of a template name, to different
> > interfaces. The stats requirement is for each interface relevant
> > instance in this case and thus embedding stats in the config template
> > not sure make sense.
> > 
> > config) model for stats with the same key definition but stats model
> > is then used directly under interface or 2) use of RPC
> >
> 

Agreed.  And this also answers your second question - model this as
config false data rather than defining a special operation to retrieve
it.

/martin

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 16 Apr 2015 20:17:50 +0000

I agree we need guidelines for statistics. There is plenty of lessons to learn (to do and not to do) from stats defined in SNMP MIBs.
Having draft-openconfig-netmod-opstate-00 and draft-ietf-netmod-rfc6087bis-01 are excellent idea. Should they be consolidated into one?
I just started writing my own guidelines for modeling YANG statistics (more questions than answers so far). IMO Martin did set the stage for the base set of guidelines for stat definition in RFC7223.

Some of my notes are:

·         I see the usage of grouping whereas a single ro container for stats could easily do

·         I prefer to use ro statistics as opposed to ro counters

·         When defining a 64-bit counter, we should use the common YANG data types as much possible. Many new drafts are ignoring it.

·         I believe we need to define additional stats as common YANG data types.

·         I see that most stats are defined as optional nodes. I prefer we define a small set of mandatory stats (when applicable) and let the vendor indicates when a specific mandatory stat is not currently supported.

·         The counter name (leaf identifier) is still an art form. I am hoping we could define a simple naming convention. Simple things like re-using the same stat name, in vs input and octets vs bytes, etc

-Steve B

From: netmod [mailto:[email-masked]] On Behalf Of Anees Shaikh
Sent: Thursday, April 16, 2015 3:03 PM
To: Juergen Schoenwaelder; Shitanshu Shah (svshah); [email-masked]
Subject: Re: [netmod] any guidelines for statistics data model

I suggest you have a look at draft-openconfig-netmod-opstate-00, which describes an operational perspective on how to represent state (including stats/counters) in a consistent way using current YANG constructs.

thanks.
-- Anees

On Thu, Apr 16, 2015 at 11:28 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587>         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Apr 2015 00:07:22 +0200

> ·         I see the usage of grouping whereas a single ro container for stats could easily do

???
 
> ·         I prefer to use ro statistics as opposed to ro counters

???
 
> ·         When defining a 64-bit counter, we should use the common YANG data types as much possible. Many new drafts are ignoring it.

It is in general a good idea to use common types.

> ·         I believe we need to define additional stats as common YANG data types.

Which ones?

> ·         I see that most stats are defined as optional nodes. I prefer we define a small set of mandatory stats (when applicable) and let the vendor indicates when a specific mandatory stat is not…

This not only applies to statistics / counters.

> ·         The counter name (leaf identifier) is still an art form. I am hoping we could define a simple naming convention. Simple things like re-using the same stat name, in vs input and octets vs…

Use the units statement to define the units. (Agreeing on a common set
of unit writing styles may be nice.)

/js

---

From: Steve Baillargeon <[email-masked]>
Date: Thu, 16 Apr 2015 22:16:16 +0000

Hi JS
I was not specifically talking about the units statement but I also have it on my to do list.
Can I proceed with a few pages (draft?) on stats guidelines? 

-Steve

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, April 16, 2015 6:07 PM
To: Steve Baillargeon
Cc: Anees Shaikh; Shitanshu Shah (svshah); [email-masked]
Subject: Re: [netmod] any guidelines for statistics data model

On Thu, Apr 16, 2015 at 08:17:50PM +0000, Steve Baillargeon wrote:
> 
> Some of my notes are:
> 
> 
> *         I see the usage of grouping whereas a single ro container for stats could easily do

???
 
> *         I prefer to use ro statistics as opposed to ro counters

???
 
> *         When defining a 64-bit counter, we should use the common YANG data types as much possible. Many new drafts are ignoring it.

> *         I believe we need to define additional stats as common YANG data types.

Which ones?

> *         I see that most stats are defined as optional nodes. I prefer we define a small set of mandatory stats (when applicable) and let the vendor indicates when a specific mandatory stat is not currently supported.

> *         The counter name (leaf identifier) is still an art form. I am hoping we could define a simple naming convention. Simple things like re-using the same stat name, in vs input and octets vs bytes, etc
>

Use the units statement to define the units. (Agreeing on a common set of unit writing styles may be nice.)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Apr 2015 08:04:15 +0200

Oh,

if the question is whether we use 'bytes' or 'octets', I think the
policy in the IETF has always been to prefer 'octets'. The reason is
that octet _always_ means 8 bits while the number of bits in a byte is
historically not necessarily 8 bits (even though this is the common
case today).

http://en.wikipedia.org/wiki/Byte

/js