Subject: RE: (FRNETMIB) Comments on Frame Relay Services MIB

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Mon, 15 Feb 1999 10:32:48 -0500

Some good ideas!  My comments below:

> -----Original Message-----
> From: Rob Steinberger [mailto:[email-masked]]
> Sent: Sunday, February 14, 1999 2:47 PM
> To: [email-masked]
> Subject: (FRNETMIB) Comments on Frame Relay Services MIB
> 
> 
> I have the following comments concerning the new version of the MIB:
> 
> 1)   The "Service Level Agreement Counters" (in the Changes from RFC
> 1604 section) should be renamed "Congestion Counters". This may be a
> trivial issue, but Service Level Agreement directs me to FRF.13.  In
> that these counters neither fully relate to FRF.13 nor is there a
> complete set of Service Level Agreement counters in the MIB, I would
> prefer not to even suggest it to the reader.
> 

I think this is an excellent idea.  The objects have generic utility
that goes beyond SLA verification.  Unless there are good arguments to
the contrary, I'll change the comment.

> 2) If we are heading down the path of FRF.13 support for Service Level
> Agreements, we need more actual Service Level Agreement variables.
> 
> 2a) On a per end point basis, I think that it would be good to have an
> Unavailable Seconds counter and possibly some FDR / DDR counters both
> as frames and octets.  It may also be nice to have the aggregate
> counters on a per logical port basis.
> 
> 2b) We are also missing a frame transfer delay object.  Some have
> stated that this object can be found elsewhere in the MIBs.  My
> feelings are that this object should both relate to Frame Relay and be
> generic enough to simply report the delay and not imply any mechanism
> used to actually calculate the delay.  This allows the user to utilize
> either some ping type mechanism or proprietary mechanism without
> having to further extend their MIB view.
> 
> 2c) We need both frame and octet counts within and/or in excess of
> CIR.  Right now, we only have frame counts for the excess frames and
> FRF.13 requires both octets and frames.

Rob is saying that the current MIB objects were not designed with
FRF.13-based Service Level Agreements in mind.  Other than the
congestion discard counts cited above, this is true.  However, the
addition of a number of new objects (and protocol, in the case of some
new delay measure) is probably a working group task that goes beyond
"last call" fixing of I-D problems.  If sufficient interest exists,
let's defer this for a follow-on RFC - perhaps one focused on FR SLA.

> 
> 3) In that we are now controlling fragmentation in this MIB, we now
> also need fragmentation counters on a per end point basis.  I think
> that we will find the need to know how many fragmentation failures
> actually occurred in that a network can appear to run in the normal
> range but never get data through due to fragmentation failures. This
> information may also suggest the need for the total number of
> fragments and the total number of successful reassembles.  A complete
> set would include the number of segments, the number of segment
> octets, and the number of reassembly errors.  These are important in
> that when fragmentation is enabled, the fragment information will feed
> the FDR and DDR counters.

I could see an object to track fragmentation failure events as an aid to
trouble shooting a mis-matched configuration.  I don't see the value in
more granularity (number of segments, number of segment octets, total
number of fragments, total number of successful reassemblies).
Specifically, the fragment information does not feed into FDR and DDR.
Those counts are based on actual full frames.  A fragmentation error
means that the frame never shows up!  The "failure to appear" means that
a bench warrent is issued and FDR/DDR reflects poor delivery quality.

> Thanks for any comments.
> Rob Steinberger
> MTS
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.

---

From: Rob Steinberger <[email-masked]>
Date: Tue, 16 Feb 1999 11:20:32 -0500

I agree that we may want to hold off on the complete set SLA statistics
until the group decides that it is appropriate to add them.  Maybe we
should discuss adding this as a work item at the meeting in March.

As for fragmentation statistics, I feel that the user needs more
information. In the case of end-to-end fragmentation, or in the case of a
probe doing SLA measurements at the FRF12 fragmentation layer, (or
Multilink fragmentation layer), simply counting octets and frames at only
one of the layers does not yield a good picture of network performance. If
SLA measurements are made at the re-assembled frame-layer and not the
fragmentation layer, small values of loss in the network may result in
large values at the frame-level, thus making the network appear much worse
than it is. Conversely, making the measurements at only the fragmentation
layer would properly reflect the network's performance, but would not
address the reason that the user isn't getting any data across. In order to
allow an NMS to properly assess fault and give a complete picture of the
network performance, I think we need a more robust set of statistics.

If it is the case that we do not have time to discuss the statistics at
this point, maybe this should be added as an action item as well and we
should withhold the ability to configure fragmentation until we can
properly track its effects on the network.