Subject: Re: [manet] performance metrics directorate review of draft-ietf-manet-olsrv2-mib-06

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 28 Apr 2013 18:31:41 +0100

Hi Ulrich,

Did you intend to post a new revision to make this change? 

Thanks,
Adrian

> -----Original Message-----
> From: Ulrich Herberg [mailto:[email-masked]]
> Sent: 15 April 2013 21:11
> To: Benoit Claise
> Cc: [email-masked]; Adrian Farrel;
[email-masked];
> [email-masked]
> Subject: Re: [manet] performance metrics directorate review of draft-ietf-
> manet-olsrv2-mib-06
> 
> Benoit,
> 
> thank you very much for this review. I agree that using the term
> "performance information" instead of "performance metrics" is a good
> idea. We will make the change.
> 
> Best regards
> Ulrich
> 
> On Mon, Apr 15, 2013 at 6:19 AM, Benoit Claise <[email-masked]> wrote:
> > Dear all,
> >
> > I reviewed http://tools.ietf.org/html/draft-ietf-manet-olsrv2-mib-06, from a
> > performance metric directorate point of view.
> >
> > This draft doesn't contain any reference to RFC6390, but contains
> > "performance metric". Hence this review was triggered. For details about the
> > directorate, see
> > http://www.ietf.org/iesg/directorate/performance-metrics.html
> >
> >
> > Definition of Managed Objects for the  Optimized Link State Routing
> > Protocol version 2
> >
> > Abstract
> >
> >    This document defines the Management Information Base (MIB) module
> >    for configuring and managing the Optimized Link State Routing
> >    protocol version 2 (OLSRv2).  The OLSRv2-MIB module is structured
> >    into state information, performance metrics, and notifications.  This
> >    additional state and performance information is useful to
> >    troubleshoot problems and performance issues of the routing protocol.
> >    Different levels of compliance allow implementers to use smaller
> >    subsets of all defined objects, allowing for this MIB module to be
> >    deployed on more constrained routers.
> >
> >
> > Basically, all performance metrics come from this table:
> >
> >    o  olsrv2InterfacePerfTable - records performance counters for each
> >       active OLSRv2 interface on this device. selected path to each
> >       destination for which any such path is known.  This table has
> >       AUGMENTS { nhdpInterfacePerfEntry } and as such it is indexed via
> >       nhdpIfIndex from the NHDP-MIB.
> >
> > NHDP-MIB is RFC 6779:
> >    NhdpInterfacePerfEntry ::=
> >       SEQUENCE {
> >          nhdpIfHelloMessageXmits
> >             Counter32,
> >          nhdpIfHelloMessageRecvd
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedSize
> >             Counter64,
> >          nhdpIfHelloMessageRecvdAccumulatedSize
> >             Counter64,
> >          nhdpIfHelloMessageTriggeredXmits
> >             Counter32,
> >          nhdpIfHelloMessagePeriodicXmits
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedSymmetricNeighborCount
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedHeardNeighborCount
> >             Counter32,
> >          nhdpIfHelloMessageXmitAccumulatedLostNeighborCount
> >             Counter32
> >       }
> >
> >
> > This draft contains similar objects in olsrv2InterfacePerfTable :
> >
> >     Olsrv2InterfacePerfEntry ::=
> >        SEQUENCE {
> >           olsrv2IfTcMessageXmits
> >              Counter32,
> >           olsrv2IfTcMessageRecvd
> >              Counter32,
> >           olsrv2IfTcMessageXmitAccumulatedSize
> >              Counter64,
> >           olsrv2IfTcMessageRecvdAccumulatedSize
> >              Counter64,
> >           olsrv2IfTcMessageTriggeredXmits
> >              Counter32,
> >           olsrv2IfTcMessagePeriodicXmits
> >              Counter32,
> >           olsrv2IfTcMessageForwardedXmits
> >              Counter32,
> >           olsrv2IfTcMessageXmitAccumulatedMPRSelectorCount
> >              Counter32
> >        }
> >
> >
> > Personally, I don't believe that those objects should be subject to the RFC
> > 6390 template definition. (Performance Metric Definition Template, section
> > 5.4.4, RFC 6390).
> > First reason: NhdpInterfacePerfEntry, from NHDP-MIB [RFC 6779] was not
> > subject to it
> > Second reason: these objects are not really performance metrics, but mainly
> > basic monitoring objects.
> >
> > Since RFC 6779 uses the term performance information (in the abstract), I
> > would propose that draft-ietf-manet-olsrv2-mib also uses this term, and not
> > the "performance metric". That would avoid some confusion. However,
> keeping
> > the olsrv2InterfacePerfTable OID name is perfectly fine, for consistency
> > reason with RFC 6779.
> >
> > Regards, Benoit
> >
> >
> >
> > _______________________________________________
> > manet mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/manet
> >

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 29 Apr 2013 12:17:14 -0700

Adrian,

yes, that was my intention...but sometimes, good intentions are not enough ;-)

I have submitted a new revision with the one-word change that Benoit requested.

Best regards
Ulrich

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 30 Apr 2013 18:58:53 +0100

Not sure in new version -07 why deleted some words/statement in section 9.

AB

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 30 Apr 2013 11:23:23 -0700

AB,

this sentence was out-of-place in section 9 and not related to
security considerations.

Best regards
Ulrich