Subject: (FRNETMIB) RE: FRNETMIB) Comments - WG last call on draft-ietf-frnetmib-frmrelay-service-0 0.txt

From: Rob Steinberger <[email-masked]>
Date: Fri, 21 Apr 2000 16:00:27 -0400

Ken,

Thanks for clarifying your  problems of this MIB.  I will not address
your opening comments in this message beyond agreeing that the lack of
comments on the list is  frustrating.  However, this same comment can
be said about ALL documents that are currently in or going to last
call.   We know there are already early implementations and have
witnessed people at the IETF meetings from NSPs, device vendors and
management software vendors state interest in this particular MIB. I
will point out that posting the comments after the Last Call was
announced to be closed is a bit difficult to deal with.  None the
less, it is in the interest of this group to resolve ALL issues and
get this document to an acceptable state as quickly as possible.

Thanks for the comments.  I will address them in-line below.

Rob Steinberger
Paradyne Networks.

"Rehbehn, Kenneth" wrote:

> Specific comments follow:
>
> 1) Section 2.5 states that this document does not suggest or
> recommend a
> particular implementation.  The frsldPvcCtrlTable contains several
> configuration variables that certainly seem to imply specific
> implementations.  These configuration objects should be removed or
> the
> implementation details should be described.  For example:
>
>   frsldPvcCtrlPacketFreq
>   frsldPvcCtrlDelayLoc
>   frsldPvcCtrlDelayFrSize
>   frsldPvcCtrlDelayType
>   frsldPvcCtrlDelayTimeOut
>

The delay objects you mention

       frsldPvcCtrlPacketFreq - Frequency of delay packet - if
     supported
       frsldPvcCtrlDelayLoc - Location of delay calculation
       frsldPvcCtrlDelayFrSize - Size of delay packet - if supported
       frsldPvcCtrlDelayType - One way or Round Trip Delay
       frsldPvcCtrlDelayTimeOut - Time out for delay response - if
     supported

are put in for the purpose of controlling delay measurement.  They are
not specific to an implementation nor do they force the user to do
delay measurement in a specific manner.  Delay is a definition as
stated in FRF.13, and there needs to be some means of controlling and
describing how this is measured.  Both control and description are
important and are part of the basis of the MIB.  The location and type
are important to adding meaning to how delay is measured, but I will
address this in a reply to your comment 8.

Perhaps, we should move some of these variables into a separate groups
in the compliance section to allow them to be skipped easier.

In your comment, you gave this list as a "for example."  This suggests
that this is only a sampling of the objects you have problems with.
We cannot fully address your issues until your issue list is complete.

>
> 2) The frsldPvcDataTable is a table of free-running counters.  This
> means
> that the time period for the min, max, and average variables in the
> frsldPvcDataTable would be infinite, making these values
> meaningless.
> What's the point?

The min, max and avg values in the data table were discussed in
Washington.  I pointed the same thing out there, and this correction
was acceptable at the time.  From the meeting minutes:

     Rob pointed out an error in the document on
     frsldPvcDataDelayMin/Max/Avg.  The reference is to the
     free-running table and this should have relevance only to the
     free running world. This will be corrected.

Further, I showed this change again in Adelaide.  We can either alter
the text to state how the object  decay should be handled or add a
variable to show the life span of the value.  This would bring up
implementation issues as to whether to use a sliding window or a
polled window.  I don't feel comfortable removing the values in that
they are needed if the implementation chooses not to do any sampling.
What would you prefer?

>
> 3) Having separate data and availability history tables does not
> make sense.
> A single table is used for free running counters that populate the
> two
> separate tables.  Likewise, make the MIB simpler by having a single
> sample
> table that includes both data and availability.  Do users really
> have a need
> to do independent history collections of availability and DDR? Would
>
> someone, for example, want fifty samples at 15 minute intervals for
> availability but want only 25 samples for DDR?

The data and availability were both in one table in the pre-draft
state of this MIB.  However, it was requested at that time that they
be separated.  The extra table allows more flexibility without adding
much complication, so I did not disagree with the request.   I can see
users wanting day samples of Availability and fifteen minute samples
of the other statistics.

>
> 4) Provide index mechanisms to support the modeling of a circuit as
> two
> half-duplex flows so that delivery success can be reported for the
> east-to-west direction as well as the west-to-east direction.

This MIB is described as working with two devices to get the
information.  The mechanism you describe is implementation specific
and requires that a single device can be used to get the statistics
for both ends of the PVC.  However, if implementations exist that
currently do this, it should be covered.  This issue is handled in my
solution to question 12.  If we let the user index on reference points
as well, we can add both directions of data by selecting the
appropriate reference point.

>
> 5) Add a "theory of operations" section to the introductory sections
> so that
> the reader can understand how to setup, tear down, and read the
> service
> sample sessions.  The theory should describe the operation for each
> of the
> permutations of data collection ("cooked" and "raw" - my terms, the
> current
> text uses an odd set of collection nomenclature).

This section is a good idea, but it comes at the risk of being too
implementation specific.  It will need to carry the warnings and
appropriate nomenclature (SHOULD, MAY, etc.).

>
> 6) Why is the collection location distinction between
> source/destination/intermediate so important?  How does the fact
> that the
> collection location is "source" versus "destination" versus
> "intermediate"
> change how the MIB is used or interpreted?  The actions seem the
> same and
> each unit has to use implementation-specific mechanisms to pull
> together the
> data from the two endpoints.  These should all be combined into a
> single
> value called "cooked" - because they all share the characteristic
> that all
> required data has been collected, correlated, and calculated.  This
> is in
> contrast the "distributed" model where only information from one end
> is
> available.  The distributed distinction should be divided into "raw
> source"
> and "raw destination".  This provides the management system with
> clear
> indication that the data needs to be combined with another sample
> set.

Section 2.6 describes the importance of the collection locations.  In
that two devices are needed to get the information, the management
software needs to know where to go to get the appropriate data.

>
> 7) the second paragraph of Section 2.6, Distributed is confusing.
> What does
> it mean to act for separate source-destination pairs? What does this
> have to
> do with the concept of not having access to both source and
> destination sets
> of data?

Data is sent from a source node to a destination node which form a
source-destination node pair.  If the device collects data only about
itself as it acts as both a source and a destination, the data will
reflect this.  The management software needs to know what the meaning
of the statistics is so that it can use them appropriately.

> 8) Different collection location types are allowed for delay
> measurement and
> delivery measurement on the SAME sample - why?  This just adds more
> complexity.

Delay and data calculations can be calculated with different
mechanisms.  Forcing only one location limits the ability to capture
all existing low level implementations.  I know of implementations
that can separate the collection locations.  Restricting this would
mean forcing an implementation on existing vendors,  violate a goal of
the document, and reduce the general use of the MIB.

>
> 9) Explicitly describe how an agent should respond if access is
> attempted to
> an object that is not supported by the particular implementation.

No Such Name

>
> 10) Make sure all comments are moved into object DESCRIPTION text.
> Especially for enumerations.

Comments will be fixed.

>
> 11) The frssldPvcDataOffered objects will wrap too quickly for high
> speed
> frame relay interfaces.  Use a high-capacity count.

The same thing can be said about all current Frame Relay MIBs.  Do we
fix all of them now, let them all work the same, or just fix this one?

> 12) The indexing of the CtrlTable and the frsldPvcCtrlSrcRP and
> frsldPvcCtrlDstRP objects would imply that a single device cannot do
>
> measurements between multiple reference points for the same PVC. For
>
> example, you couldn't measure end to end and end to NNI.  Is this
> true?

Good point.  I can add the reference points as indices and this will
be fixed along with the comment as well as issue 4.

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