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

From: "Rehbehn, Kenneth" <[email-masked]>
Date: Wed, 19 Apr 2000 16:27:41 -0400

Well - I thought I had till today to get my comments in for WG Call for the
FR Service MIB.  Too much time out of the office to get a more timely
response.  Here are my comments anyway (it is still April 19)!

The Frame Relay Service MIB is not ready to complete WG Last Call. The
current draft lacks sufficient detail to enable interoperable implementation
of service monitoring for both half-duplex flows over a DLCI.  In addition,
the current MIB structure needs less complexity. Merging the sample tables
and providing a cleaner circuit management model will simplify the MIB and
enable interoperability.

My biggest beef is that this MIB is outside a generic policy/service
management tracking framework that covers multiple aspects of the
IETF-specified technology.  This MIB should not be on a standards track.
Standards Track status should be restricted to a MIB that fits into the
evolving framework being produced by the Policy Working Group.  This is the
wrong time to declare a particular approach to be a "standard".  I will
continue to urge the working group to keep this as a "Experimental" MIB.

I am distressed at the silence on this mail list.  The silence indicates a
great deal of apathy towards this particular attempt to produce a frame
relay service MIB.  That alone should give the IESG pause.

If we elect to charge ahead, then a lot more work is needed to get this MIB
into good shape.  See my specific comments below for elaboration.

Ken

===================================================================

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

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?

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?

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.

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).

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.

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?

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

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

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

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

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?

---------------------------------------------------------------
Ken Rehbehn                              Phone: +1-301-296-2325
Visual Networks                            Fax: +1-301-296-2302
2092 Gaither Rd              EMail: [email-masked]
Rockville, MD  20850              http://www.visualnetworks.com 
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe frnetmib' in the body of the message.