Subject: (FRNETMIB) Comments on Frame Relay Services MIB

From: Rob Steinberger <[email-masked]>
Date: Sun, 14 Feb 1999 14:46:50 -0500

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.

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.

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.

Thanks for any comments.

Rob Steinberger
MTS
Paradyne Corporation
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.

---

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Tue, 16 Feb 1999 11:42:08 -0500

Rob -

The fragmentation objects in the MIB apply ONLY to the interface and not
end-to-end.  There is no impact on network performance apart from the
load on the physical link supporting fragmentation.  One physical
segment of a connection path is not typically the target of a service
level agreement.

When fragmentation is configured for the port, I think the only
statistic needed is a reassembly failure count to trouble shoot
configuration problems.  

The impact of such failures on service level gets reflected in the
resulting drop of a frame.  That loss is noticed when service level is
monitored on an end-to-end basis.

Regards,
Ken

> -----Original Message-----
> From: Rob Steinberger [mailto:[email-masked]]
> Sent: Tuesday, February 16, 1999 11:21 AM
> To: Rehbehn, Kenneth
> Cc: [email-masked]'
> Subject: Re: (FRNETMIB) Comments on Frame Relay Services MIB
> 
> 
> 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.
> 
> Rehbehn, Kenneth wrote:
> 
> > 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 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.
> >
> > 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.
> >
> > >
> > 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
> 
> 
>