Subject: [ippm] IPPM-MIB/SSPM-MIB comparaison

From: STEPHAN Emile FTRD/DAC/LAN <[email-masked]>
Date: Wed, 1 Aug 2001 17:10:51 +0200

Hi  Dan, all

Dan wrote 

		I have seen your recent individual submission
draft-stephan-ippm-mib-00.txt. There are some very interesting ideas in your
work, and I am glad to see this MIB proposal being closely related to the
IPPM framework. At the same time I would like to point to the work that we
have initiated in the last year for the definition of a framework for
synthetic sources for performance monitoring (SSPM), and the corresponding
SSPM MIB. The two relevant Internet-Drafts are:

http://www.ietf.cnri.reston.va.us/internet-drafts/draft-cole-sspm-03.txt
	
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-kalbfleisch-sspmmib-
02.txt

		Our work was also presented and made visible to the IPPM
Working Group. It will be discussed at the London IETF in the RMON Working
Group, with the intention to make it a WG item in the new Charter of RMON. 

		It would be useful if you can comment on the similarities
between your proposal and ours. I would encourage a dialog, to ensure 
		that our efforts are coordinated and not duplicated.
____________________________________________________________________________
_______

Abstract:
This document point the similarities between the 2 MIBs defined respectively
in draft-kalbfleisch-sspmmib-02.txt (SSPM-MIB) and
draft-stephan-ippm-mib-00.txt (IPPM-MIB).  The comments focus on the
comparison of the scalability  aspects of the 2 MIBs. The others MIB are
reference by their module identifier.

Firstly I apologize if the following comments include mistakes due to
misunderstandings. The aim is to found the similarities and of course the
differences  to found quickly a common way.

The redaction of the draft-stephan-ippm-mib-00.txt document started in 1998.
The first release was registered internally in October 1998.  It was
motivated mainly by the need to provide a end to end management interface
for troubleshooting and SLA monitoring. So the 2 MIB have similar semantic.

While the motivations are identical, the approach is quite different.
SSPM-MIB relies on items defines in the draft-ietf-rmonmib-apm-mib-03.txt
(APM-MIB) when the IPPM-MIB specifies a framework for managing the measures
specified by the IPPM WG.

I totally agree with the motivation " there are very few pieces of
information that one might extract from a resource that are only useful for
just one purpose, e.g.,  fault, policy or performance monitoring".
Fundamentally the integration of the management of the measures provided by
a passive probe and a active probe is a function relevant to the NMS
application not to the probe. An active probe may be configured by the NMS
application to perform a measure at the network level because some trigger
in a passive probe informs the NMS that some HTTP server looks down (e.g.:
the passive probe detects a lot of TCP timeout).  In the SSPM implementation
this integration needs an implementation of the APM-MIB and of the SSPM-MIB
in the same agent. The field sspmSourceType of the SSPM-MIB uses a field
value from APM-MIB. So it is impossible to implement the SSPM-MIB without
implementing the APM-MIB. The SSPM-MIB is not easily reusable for
implementing  only an active probe. That is not scalable. Further more the
APM-MIB results do not guaranties the privacy of the customers.

The aim of the IPPM-MIB is to provide a framework for the implementation of
peering management of active probes. The customers of the probes manage
their individual indexes range. The configuration is very simple and fast
because there is no need to manage indexes per probe. So the same index is
used for the same measure in the different probes. A customer grants other
user to share the result of a its measures. The SSPM-MIB is quite different.
It is very difficult to identify the source in the history of a sink if the
source address is identical. It is quite difficult to a customer to use
result provided by the measure of another customer.

IPPM-MIB monitors dynamically the clocks synchronisation so unusable results
may be explicitly identified while computing statistics. 

IPPM-MIB provides an independent model of sampling distribution while
SSPM-MIB specifies only 2 sampling distributions.

IPPM-MIB specifies a independent model for the TypeP addresses while
SSPM-MIB is not compatible with Diffserv. 

The 2 MIB look similar. But there are intrinsically different. IPPM-MIB is
extranet oriented while SSPM-MIB is intranet oriented. IPPM-MIB model is
distributed and multi customers while the SSPM-MIB implementations are
difficult to share. SSPM-MIB relies on other MIBs. That point should be a
value add if the connexion with the other MIB was more abstract. It should
quite interesting to study how to use Script MIB to interface the components
of the SSPM framework while integrating the next release of the IPPM-MIB in
that framework. IPPM-MIB is immature so the previous point may be easily
integrated in its workflow redaction.

Please give me any feedback that you may have.

Best regards
Emile

	- 

_______________________________________________
ippm mailing list
[email-masked]
http://mailhost.advanced.org/mailman/listinfo/ippm

---

From: "Cole, Robert G (Bob), ALSVC" <[email-masked]>
Date: Wed, 1 Aug 2001 18:09:01 -0400

Emile,

As well, the SSPM-MIB work has been in progress for quite a while now in
an open venue.  A BOF was held in Adelaide on this topic where a set
of very specific recommendations were made (the meeting minutes are
available to everyone).  One of which was the development
of the SSPM-MIB within the RMON WG.  The IPPM WG
has been well aware of this work since Adelaide, through mailings 
and in all the WG meetings since that time.

The SSPM-MIB intends to fit within the performance monitoring framework
being defined within the RMONMIB working group.  The relevant drafts are:
<draft-ietf-rmonmib-apm-mib-04.txt>
<draft-ietf-rmonmib-appverbs-02.txt>
<draft-ietf-rmonmib-tpm-mib-03.txt>
<draft-kalbfleisch-sspm-mib-02.txt>
<draft-cole-sspm-03.txt>

The goals include:

+ Seperation of monitoring and traffic generation by defining different MIBs
within
different documents, e.g., apm-mib, tpm-mib, sspm-mib.  (BTW, your draft
seems
to combine the traffic control and monitoring and hence you should be
comparing
to sspm-mib and the apm and tmp mibs.)

+ Implementation flexibility, so a vendor could choose to implement,
apm-mib,
or apm and tpm, or sspm-mib, or sspm-mib and tmp, etc.

+ Support for various metrics through references to other standards, e.g.,
support for
IPPM metrics through reference, or support for other standards for that
matter, e.g.,
ITU standards.

+ Support the traffic generation requirements of the IPPM work ( as we have
clearly
stated in our framework drafts ).

We support the recommendations of the Adeliade PerfMgmt BOF and believe
there are
good reasons that this type of work be addressed within the RMONMIB WG and
related WGs, e.g., DISMAN.  The current work in the RMONMIB WG are 
works in progress, i.e., drafts.  We would expect that if folks had specific
requirements
on this work, then they would have brought them to the attention of the WG
and the
authors through the mailing lists and the meetings.  Although aspects this
work has
been in progress for two years, not once has there been any discussion
on the mailing lists from the IPPM WG.

On a more specific level:

We agree that there is value in having a MIB interface to IPPM metrics.  We
believe that some of your suggestions can and should be incorporated into
the
current sspm-mib draft. E.g., the points your proposal makes
about the sampling mechanism and the address types - though DiffServ 
support is achieved in RMON by the use of the DS-MON proposal. These
issues should be considered.

We believe that the critic of SSPM being related to other MIBs is actually
an advantage, 
because it is expected that SPPM can be plugged into the other RMON
framework 
MIBs, and used in modular combination. Providing an abstract mechanism to 
connect SSPM to 'any MIB' would be too expensive to implement, and 
actually non-necessary because RMON already has built-in mechanism 
that can trigger actions based on the Alarms thresholding mechanism 
(and if you want the Script MIB).

We suggest that there may be value in bringing your proposal closer to 
the RMON framework, if not make it part of it.

Finally, I am sorry that I am unable to attend the London meeting due to
personal
matters (nothing bad, just an unavoidable vacation :-)  ) and in fact will
not
have access to email for the next several weeks.
However, I look forward to hearing about the discussions on these topics
from you, my co-authors and the mailing list when I get back to work.

Thanks,
Bob

> -----Original Message-----
> From:	STEPHAN Emile FTRD/DAC/LAN [SMTP:[email-masked]]
> Sent:	Wednesday, August 01, 2001 3:11 PM
> To:	Dan Romascanu; STEPHAN Emile FTRD/DAC/LAN
> Cc:	[email-masked]; [email-masked]'; Matthew J Zekauskas
> Subject:	[ippm] IPPM-MIB/SSPM-MIB comparaison
> 
> Hi  Dan, all
> 
> Dan wrote 
>

---

From: STEPHAN Emile FTRD/DAC/LAN <[email-masked]>
Date: Thu, 2 Aug 2001 18:50:26 +0200

Hi Cole, all

I totally agree with the motivation of the SSPM motivations and with the
effort to define a framework for the integration of the MIB and protocols
involved in measurement. 

I will be glad if you may point out what are the main differences between
the IPPM-MIB framework and the RMON and SSPM framework.

The IPPM-MIB specification is very closed to the RMON specifications. The
TypeP definition relies on 2 RFC produced by the RMON group. The RFC2895 who
specifies a macro for the definition of protocol identifier and the RFC2896
who defines the protocols identifiers for different protocols encapsulation
trees. 

The IPPM-MIB framework is very closed to the RMON framework too. Measures
and history are managed using the conceptual row model. Specialized measure,
sampler and statistics inherit from the measure table using the INDEX clause
like in the RMON RFCs. History produced several object instances per measure
step like objects in the RMON history table.

IPPM-MIB framework differs from the framework on 2 points. 

As IPPM measures are intrinsically distributed, the timestamp associated
with a result must be absolute. The implementation extend the TimeFilter TC
defined in the RMON2.

As Internet is operated by a lot of actors, the IPPM-MIB framework
introduced the concept of peering management to allow operators to share
their probes. Its specification relies on the ownerString Tc defined in the
first RMON RFC. Apparently there is no difference on that point with the
RMON framework. Actually IPPM-MIB differs dramatically. It uses the
Ownerstring to identify both the measure and the results of the measure.
That mechanism permits the NMS owner to manage its indexes by himself. That
allows an NMS to associate a unique index with a measure among set of
probes.

The future release will integrate the management the relationship between
the owner. 

As requested the next release will include connexion with the RMON-MIB and
RMON2-MIB.

I will look at the way to integrate the IPPM-MIB in the SSPM framework. 

I will be glad if you could you provide me some clarification on how the
SSPM-MIB may be implemented without the APM-MIB and on the connexion between
the SSPM-MIB and the RMON-MIB and the RMON2-MIB.

Best regards
emile

-----Message d'origine-----
De : Cole, Robert G (Bob), ALSVC [mailto:[email-masked]]
Envoyé : jeudi 2 août 2001 00:09
À : STEPHAN Emile FTRD/DAC/LAN; Dan Romascanu
Cc : [email-masked]; [email-masked]
Objet : RE: [ippm] IPPM-MIB/SSPM-MIB comparaison

Emile,

The goals include:

Thanks,
Bob

---

From: "Cole, Robert G (Bob), ALSVC" <[email-masked]>
Date: Fri, 3 Aug 2001 08:52:53 -0400

Emile,

I think that the RMON and IPPM frameworks/charters are
looking to accomplish two fundamentally different things.
I believe the IPPM framework defines methodologies
for measurements while the RMONMIB framework defines
capabilities for measurements within the general SNMP
framework.  

The capability for sharing management information within 
rmon is provided by the general SNMP framework it builds
its capabilities within.

I was not suggesting that you try to fit your
work within sspm-mib.  I would hope, however,
that you can find the time in London to attend
the rmonmib WG meetings and help clarify the
goals of your work in relationship to the
ongoing work in the rmonmib WG.

I apologize for not being able to attend the meetings
this time around but hope you can connect up
with Dan at the rmonmib meetings.

Thanks,
Bob

> Sent:	Thursday, August 02, 2001 4:50 PM
> To:	Cole, Robert G (Bob), ALSVC; STEPHAN Emile FTRD/DAC/LAN; Dan
> Romascanu
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: [ippm] IPPM-MIB/SSPM-MIB comparaison
> 
> Hi Cole, all
>