Subject: Ether-like issues from Chicago

From: John Flick <[email-masked]>
Date: Fri, 23 Oct 1998 15:53:21 -0700 (PDT)

Some questions to try to understand the edits needed to the Ether-like 
MIB based on the discussion in Chicago.

Lynn Kubinec writes:
 > Minutes of the HUBMIB Working Group at the 42nd IETF

...

 > The final topic for discussion were the Ethernet-Like MIB Issues
 > raised on the list by the document editor, John Flick.  This discussion
 > was actually more of a review by the chair.  Comments need to be 
 > posted to the list.
 > 
 > Issue 1:
 >     - I put the new objects relating to MAC Control and PAUSE into a
 >       new table, the dot3ControlTable.  Is this the way we want this
 >       structured?  Should MAC Control and PAUSE be separate tables?
 >       Or should we just keep everything in dot3StatsTable?
 > Chair doesn't like this control table as the counters are only related
 > to PAUSE.  If a new control function is added, then these counters don't
 > make sense.  Should have separate tables for each control function.

So, it sounds like what the chair wants is two tables:
dot3ControlTable which would contain dot3ControlFunctionsSupported and 
dot3ControlUnknownOpcodes, and a separate table with the four
pause-specific objects.  Is this the consensus of the group?

 > Issue 2:
 >     - dot3ControlFunctionsSupported: Is it needed, or is it redundant
 >       with ifMauAutoNegCapability?  Should it be settable (as in the
 >       IEEE doc)?  If so, what does it mean to set it?
 > Chair's comment is that this is not redundant.

I have some concerns about this object.  The IEEE doc specifies this
object as read-write.  Does this mean an implementation is supposed to 
suddenly figure out how to support a previously unsupported function
because you set a new bit in the object?  This obviously doesn't make
sense, which suggests that this object should be read-only.  If we
want a read-only FunctionsSupported object and a read-write
FunctionsEnabled object, that seems to overlap the function of
ifMauAutoNegCapAdvertized, at least for all ControlFunctions that have 
been defined so far.  I would suggest perhaps keeping a read-only
Capabilities object here, and using the MAU MIB object for controlling 
what is enabled.

 > Issue 3:
 >     - dot3ControlPauseLinkDelayAllowance: Do we need this object?  I
 >       am a bit unclear as to what it means to set this.  It is not
 >       mentioned in any of the MAC Control or PAUSE state machines.
 > Chair noted that this is not in the IEEE spec because during those
 > discussions it was thought to be too hard to implement.  It turns out
 > that this is not true, so perhaps it would be a good think to manage.

The IEEE spec defines aPAUSELinkDelayAllowance in Clause 30, but the
state machine for PAUSE operation doesn't give any indication as to
how the value is used.  I guess if we are going to support this
object, I need some help understanding how to write a DESCRIPTION for
an object which has no documented use in the IEEE spec.

(Issues 4 and 5 deleted since they seem to be non-controversial.)

 > Issue 6:
 >     - I haven't added a DuplexMode object, since the consensus here
 >       seemed to be that it should be in the IF-MIB.  I believe Brian
 >       O'Keefe was supposed to be submitting a proposal to the ifmib
 >       mailing list, but that hasn't happened yet.  If IF-MIB doesn't
 >       add this object, we should probably add it to this MIB.
 > Jeff Johnson noted that currently the IFMIB cannot be used to determine
 > whether an interface is operating in half duplex mode or not.  There is
 > also the question of whether having the duplex information present in
 > the MAU MIB is sufficient.  He noted that generic applications only look
 > at the IFMIB to do utilization calculation, so even if the duplex 
 > information is added to this MIB, it may not be solving a problem.
 > 
 > Group consensus was that it's probably best to put the information here
 > anyway.  Note was made that interfaces like xDSL can be full duplex and
 > have different speeds in each direction.  This means more work for the
 > NMS, but it is necessary.

So, is it the consensus of the WG to add a read-only DuplexMode object 
to the Ether-like MIB?

 > The chair noted that the only new Gigabit related counter in the 
 > IEEE spec was the number of burst frames and in LA the group had
 > decided that it is probably not a necessary counter.

Actually, the burst frames counter is in the repeater section of the
IEEE spec, so doesn't belong in any of the docs we are currently editing.

 > There was also a question about error counters.  If the rate is
 > greater than 640 Mbps, then probably need High Capacity (HC) counters.
 > The chair proposed that HC counters not be added.  The paragraph in
 > the draft regarding relation to the IEEE standard should mention this
 > decision.

I agree that we don't need HC error counters in this MIB.  If your
error counters are incrementing that quickly, you are in BIG trouble.
However, I assume we want to specify that gigabit interfaces should
implement the HC packet counters in IF-MIB.

John

---

From: "Dan romascanu DVP-TA" <[email-masked]>
Date: Mon, 26 Oct 98 9:28:26 +0200

John,

> pause-specific objects.  Is this the consensus of the group?

If this is not clear, the rationale of my proposal is making the 
mechanism open for extensions covering future control fucntions.

> Capabilities object here, and using the MAU MIB object for controlling 

This works, but should be clarified by text in this document (and maybe 
also in the MAU MIB).

> an object which has no documented use in the IEEE spec.

I am still not very convinced on this. I would be glad to hear some more 
opinions. The description should be derivated from 30.3.4.1. in the IEEE 
x/y document ('...value, in bits of the allowance made by the PAUSE MAC 
Control entity for the round-trip propagation delay of the full duplex 
link').

> So, is it the consensus of the WG to add a read-only DuplexMode object 

It looks like it is. We can deprecate later, if the IF-MIB comes in our 
help.

> IEEE spec, so doesn't belong in any of the docs we are currently 
editing.

Correct.

> implement the HC packet counters in

Yes.

Dan

--------------------------------------------------------------------------
------
Dan Romascanu,
Systems Architecture Group Manager,
LANNET (Lucent Israel),
Voice: 972-3-645-8414, e-mail: [email-masked]
--------------------------------------------------------------------------
------