Subject: Re: [OPSAWG] Review of draft-ersue-opsawg-management-fw-01, part 2

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Sat, 4 Dec 2010 01:05:12 +0100

Hi Benoit,

thank you for your review and comments. See inline.

Mehmet

From: ext Benoit Claise [mailto:[email-masked]] 
Sent: Wednesday, December 01, 2010 1:51 AM
To: Ersue, Mehmet (NSN - DE/Munich); [email-masked]
Subject: Review of draft-ersue-opsawg-management-fw-01, part 2

Hi Mehmet,

Here is the review of the remaining part.

. . . 

3.9.2.  COPS-PR

   [RFC3159] defines the Structure of Policy Provisioning Information
   (SPPI), an extension to the SMI modeling language used to write
   Policy Information Base (PIB) modules.  COPS-PR [RFC3084
<http://tools.ietf.org/html/rfc3084> ] uses the
   Common Open Policy Service (COPS) protocol for support of policy
   provisioning.  COPS-PR and the Structure of Policy Provisioning
   Information (SPPI) have been approved as Proposed Standards.

I would cut/paste this sentence below.
Expressed like this, it means that this is an important standard, but
the end of the section is quite different.
[Mehmet]: I assume you mean the last sentence above.

. . .

   These metrics are designed for network operator use and provide
   unbiased quantitative measures of performance.

This sentence, copied from the charter, should be in here.

The metrics developed by the WG were developed inside an active
measurement context, that is, the devices used to measure the metrics
produce their own traffic. However, most metrics can be used inside a
passive context as well. No work is planned is this area though,
this may be changed with AD approval.

[Mehmet]: I agree. I would though skip " this may be changed with AD
approval."

	   The main properties of individual IPPM performance and
reliability
	   metrics are that the metrics should be well-defined and
concrete thus
	   implementable, and they should exhibit no bias for IP clouds
	   implemented with identical technology.  In addition, the
methodology
	   used to implement a metric should have the property of being
	   repeatable with consistent measurements.
	 
	   IETF IP Performance Metrics have been introduced widely in
the
	   industry and adopted by different SDOs such as ITU-T.

Actually, any others than ITU-T?
[Mehmet]: Al wrote MEF was active in this area too.

 
   RTFM is e.g. used for the measurement of DNS performance.

I consider RTFM as an experiment done before IPFIX.
btw, http://tools.ietf.org/html//rfc2724
<http://tools.ietf.org/html/rfc2724>  is experimental.
Again, it depends on the target audience. If we want to keep a history
of what has been done in OPS, that's interesting. Otherwise, I would
remove RTFM
[Mehmet]: I think I can agree. RTFM is probably not important anymore.

. . .
 
   Management data models have a slightly different interpretation for
   interoperability.  This is discussed in detail in [BCP27]
   "Advancement of MIB specifications on the IETF Standards Track"
   [RFC2438 <http://tools.ietf.org/html/rfc2438> ] with special
considerations about the advancement process
   for management data models.  However most IETF management data models
   never advance beyond Proposed Standard.

Note that MIB is just one data model.
What about IPFIX?
[Mehmet]: What would be your proposal? Should we put it into chapter
4.2?

4.4.  Performance Management

Should we mention the IPPM perf metrics in here?

[Mehmet]: RFC4150 and BCP0108(RFC4148) are mentioned below. Which RFC do
you mean? 

. . .
 
   The RMON matrix group stores statistics for conversations between
   sets of two addresses.  The filter group allows packets to be matched
   by a filter equation.  These matched packets form a data stream that
   may be captured or may generate events.  The Packet Capture group
   allows packets to be captured after they flow through a channel.  The
   event group controls the generation and notification of events from
   this device.

Don't want to start a lengthy debate here, but my personal view is that
RMON host, matrix are superseded by IPFIX: more granular, more flexible
At the minimum, we should mention IPFIX somewhere here. This comes back
to my point before that MIBs are not the only data model at the IETF.

Indeed, this is worth a discussion. At the end, I think we may not skip
RMON, which is still important for some folks.

I would like to suggest to describe this use case in IPFIX chapter in
detail. Would like to provide text for it?

. . .

---

From: Benoit Claise <[email-masked]>
Date: Mon, 06 Dec 2010 14:48:21 -0800

Hi Mehmet,
> *From:*ext Benoit Claise [mailto:[email-masked]]
> *Sent:* Wednesday, December 01, 2010 1:51 AM
> *To:* Ersue, Mehmet (NSN - DE/Munich); [email-masked]
> *Subject:* Review of draft-ersue-opsawg-management-fw-01, part 2
>
> Hi Mehmet,
>
>     (SPPI), an extension to the SMImodeling language used to write
>     Policy Information Base (PIB) modules.  COPS-PR [RFC3084  <http://tools.ietf.org/html/rfc3084>] uses the
Yes, sorry.
> [Mehmet]: I agree. I would though skip "this may be changed with AD 
> approval."
>
>         The main properties of individual IPPM performance and reliability
>
>         metrics are that the metrics should be well-defined and concrete thus
>
>         implemented with identical technology.  In addition, the methodology
>
>         IETF IP Performance Metrics have been introduced widely in the
>
>     [RFC2438  <http://tools.ietf.org/html/rfc2438>] with special considerations about the advancement process
> [Mehmet]: What would be your proposal? Should we put it into chapter 4.2?
>
First list the different data models in the intro of sectoin 4.0: MIB, 
IPFIX, RADIUS. Somehow, when I read it, because the second paragraph 
focuses on MIB, I misinterpreted that you were only covering MIB. 
Re-reading this, I missed the "s" at the end of the data models in:

    This section lists solutions for which information or data models
    have been standardized at the IETF

Then, for IPFIX, at least list it in accounting and performance management.
> [Mehmet]: RFC4150 and BCP0108(RFC4148) are mentioned below. Which RFC 
> do you mean?
>

>     sets of two addresses.  The filter group allows packetsto be matched
> Don't want to start a lengthy debate here, but my personal view is 
> that RMON host, matrix are superseded by IPFIX: more granular, more 
> flexible
> At the minimum, we should mention IPFIX somewhere here. This comes 
> back to my point before that MIBs are not the only data model at the IETF.
>
> Indeed, this is worth a discussion. At the end, I think we may not 
> skip RMON, which is still important for some folks.
>
The goal is certainly to skip RMON, but to explain RMON and IPFIX scopes.
> detail. Would like to provide text for it?
Not sure exactly where this text should be, but yes, I will provide some 
text.

Regards, Benoit.