Subject: (FRNETMIB) Questions and comments on the FRSLD-MIB draft

From: "Nisbet, Tom" <[email-masked]>
Date: Thu, 11 Oct 2001 11:06:27 -0400

I have several questions and comments on the FRSLD-MIB draft that was
Published as draft-ietf-frnetmib-frmrelay-service-06.txt.

IMPLEMENTATION SPECIFIC OBJECTS
Section 3.5 states that no implementation is suggested in the document.
However, the data and configuration tables contain objects that seem
to be implementation dependent.  Specifically, the frsldPvcCtrlEntry
contains PacketFreq, DelayFrSize, and DelayTimeout objects.  The data
and sample data tables contain a MissedPolls object.  The use of these
is not adequately explained.

REFERENCE MODEL EXAMPLES
Several of the examples in section 3.6.2.1 seem to suggest configurations
that cannot provide the data needed to do the FDR and DDR calculations.
The second examples in 3.6.2.1.1 and 3.6.2.1.2 and 3.6.2.1.3 all place
the Offered and Delivered counts for a single flow on different devices.
To calculate DDR and FDR, the counts need to be synchronized.

This is particularly evident when using the frsldPvcSampleTable.  To
calculate FDR and DDR, the two devices would need to collect their
samples for exactly the same time periods.

SAMPLE TABLE ORGANIZATION
I don't understand the concept of discontinuities in the sample table
that justify the use of start and stop times.  Are the discontinuities
caused by DLCIs transitioning in and out of an INVALID state?  If so,
how does this effect the sample index?  Should it increment for each time
interval, or only for intervals that contain sample data?

MEASUREMENT OF TRAFFIC DELIVERED WITHIN CIR
It is relatively easy to calculate delivered frames, but difficult to
calculate it within a CIR or EIR range.  If a device cannot differentiate,
how should it populate the DeliveredE and DeliveredC objects?  It might make
sense to just use one counter and leave the other at zero, but that
condition
could also occur normally.  Should we add a capabilities bit for this?

There has not been much discussion of this draft on the list.  How many
people are implementing this?  I'd be interested in other people's
experience.

Thanks,
Tom Nisbet
[email-masked]
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.

---

From: Robert Steinberger <[email-masked]>
Date: Fri, 12 Oct 2001 14:07:50 -0500

Tom

This MIB was thoroughly discussed in the working group over the past 2
years,
and I believe you were present at some of the meeting during which it
was
discussed.  It has been through working group last call, and there were
comments on the list both during last call and the general review
process.  All
of the issues, some of which were very similar to yours, have been
worked out.
As you know, implementation reports come later in the process, and the
number
of companies actually implementing an internet draft is not really as
relevant
as those implementing a draft standard.

See further comments in line below.

Rob.

> is not adequately explained.

This issue was discussed previously in both e-mail  on the list and
during
meetings.  It was decided that these would be handled as optional
items.  See
the capabilities section of the MIB.

> samples for exactly the same time periods.

Synchronization mechanisms are not part of FRF.13.  It is true that
accuracy
demands some synchronization.  In fact, this was also discussed in the
process.  Some companies will simply provide better accuracy than
others.

> interval, or only for intervals that contain sample data?

The sample index should increment as stated, "once for each new bucket
in the
table".  The start and end times are recorded to allow for
discontinuities.
The discontinuities are caused by the fact that frsldSmplCtrlStatus
follows the
frsldPvcCtrlStatus in respect to activity.  If frsldPvcCtrlStatus
becomes
notReady, no samples will be collected.

> could also occur normally.  Should we add a capabilities bit for this?

Perhaps in a future release of this MIB we could add items related to
the OAM
agreement, but this MIB concerns solely with in and out of CIR.  It is
not
concerned with EIR.  If an implementation is not capable of determining
CIR
status, it is not really compliant with those statistics.  If the device
cannot
differentiate, neither of the statistics, DeliveredC or DeliveredE, are
correct.  Reporting a number in DeliveredC states that octets or frames
were
delivered within CIR.  If you are reporting a number that is not
correct, it is
a problem.

> people are implementing this?  I'd be interested in other people's

See comments above.