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

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 12 Oct 2001 17:13:05 -0400

Tom,

As Robert said, these issues have been previously discussed.  I suggest you 
read the WG minutes in the IETF proceedings 
(http://www.ietf.org/proceedings/directory.html) and the email archive 
(ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/).

Thanks,
Andy

-------

At 10/11/2001 11:06 AM -0400, Nisbet, Tom wrote:
>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: "Nisbet, Tom" <[email-masked]>
Date: Fri, 12 Oct 2001 17:37:19 -0400

I have read the last two years of email archive and have seen some
discussion of my first issue, but nothing on the others.  I don't think I
stated the problems clearly and will follow up with more details.
 
In any case, I apologize for showing up late to the party.  However, I do
think that there are real issues here.
 
Tom

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]] 
Sent: Friday, October 12, 2001 5:13 PM
To: Nisbet, Tom
Cc: [email-masked]
Subject: Re: (FRNETMIB) Questions and comments on the FRSLD-MIB draft

Tom,

As Robert said, these issues have been previously discussed.  I suggest you
read the WG minutes in the IETF proceedings
(http://www.ietf.org/proceedings/directory.html
<http://www.ietf.org/proceedings/directory.html> ) and the email archive (
<ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/>
ftp://ftp.ietf.org/ietf-mail-archive/frnetmib/).

Thanks,
Andy

-------

REFERENCE MODEL EXAMPLES

Thanks,
Tom Nisbet

---

From: "Nisbet, Tom" <[email-masked]>
Date: Sat, 13 Oct 2001 22:37:15 -0400

Rob,

I probably didn't state the issues clearly.  I'll provide additional
details below.  Other than the first issue, I don't believe the others
have been covered.

Please see my comments inline.

Tom

Robert Steinberger wrote:
>
> 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.
> 
> "Nisbet, Tom" wrote:
> 
> 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.
>

Making the objects optional doesn't really solve the problem.  If
the objects can be implemented, then they should be described.  We
can't expect people to count missed polls if we don't state what a
poll is or how one can be missed.  The description of the 
frsldPvcCtrlDelayTimeout object is a bit unclear on this.  For example,
what does it mean for a delay frame to be updated?

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

It isn't a question of accuracy.  Some of the example configurations
will not provide the data necessary to do the calculations.  I'll put
together a detailed example of this.

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

It is unclear to me what advantage this has over a simpler mechanism
such as the RMON History Table or the DS1 MIB's Interval Table.  I'll
put together a more detailed set of questions that may clear this up.
 
> 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.
>

This is exactly what led me to ask if anyone was currently
implementing the MIB.  At first glance, the statistics look to be
very straightforward and easy to implement.  However, I believe
that it is not possible to non-intrusively measure delivered frames
with respect to ingress CIR.  This was discussed at some length
in the FRF.13 working group.

There seem to be three possibilities:
A) It is easy and I'm the only one who hasn't figured it out yet.
B) People are not as concerned as I am about either modifying
customer traffic or putting a burdensome amount of additional
measurement traffic on the link.
C) Not many people are implementing this yet and there will be
quite a few suprises when everyone finally attempts this.

If the answer is A or B, then there is no problem.  I suspect
that this is not the case.

> See comments above.