RE: Augmenting MAU-MIB - was: RE: EFM MIB Internet-Draft s, WG Meetings

OK, let's close this thread with a decision of mandatory usage of the
EtherLike-MIB for the EFM-CU-MIB. I'll put little chapter in the RFC
discussing the relationship to the EtherLike-MIB and a compliance statement
to the MIB itself. 

Going back to my original question: what is the procedure for updating the
MAU-MIB?

Regards,
-Edward

-----Original Message-----
From: Romascanu, Dan (Dan)
To: Matt Squire; Edward Beili
Cc: [email protected]
Sent: 10/28/03 9:10 PM
Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts,
WG Meetings

(speaking as a contributor)

I am a little bothered by this 'revisionist' approach. I have witnessed
the efforts invested at the time when EFM PAR was discussed to
demonstrate that this is still Ethernet and we can make re-use of all
kinds of goodies, including management MIBs and applications. Was this
enthusiasm lost, or did we just get a reality shower? 

I still would plead that it is better to keep using the objects from the
Ethernet-like MIB, rather than duplicating them in an EFM-Cu MIB, even
if we are talking about three objects or so. Duplication does not make
sense, and what about the optical EFM MIBs? Conformance statements
should help us avoid the duplication.

Regards,

Dan
 

 

> -----Original Message-----
> From: Matt Squire [mailto:[email protected]]
> Sent: 28 October, 2003 6:42 PM
> To: Edward Beili; Romascanu, Dan (Dan)
> Cc: [email protected]
> Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB
> Internet-Drafts, WG Meetings
> 
> 
> 
> Its a fair point.  Most of the stats you mention that are not 
> applicable to 2BASE/10PASS are also not applicable on any 
> full-duplex PHY.  But in the past, even PHYs that are only 
> full-duplex support the MIB.  So I'm going with precedent.  
> 
> Also, I haven't looked at it closely, but aren't some of the 
> half-dup counters applicable because of the way the MAC runs 
> in half-duplex for rate matching?  I've seen the 
> implementation specific counters have some very good utility 
> as well.  
> 
> Thats my 2cents.  Take it for what its worth.
> 
> - Matt
> 
> > Let's look at the statistics.
> > 
> > Dot3StatsEntry:
> > - dot3StatsIndex                      - ifIndex
> > - dot3StatsAlignmentErrors            - would probably be always 0
> >                                         for EFMCu, as EFMCu framer
> >                                         is octet aligned.
> > - dot3StatsFCSErrors                  -
> > - dot3StatsSingleCollisionFrames      - always 0, no 
> > collisions in EFMCu
> > - dot3StatsMultipleCollisionFrames    - always 0, no 
> > collisions in EFMCu
> > - dot3StatsSQETestErrors              - always 0, Full-Duplex
> > - dot3StatsDeferredTransmissions      - always 0, Full-Duplex
> > - dot3StatsLateCollisions             - always 0, no 
> > collisions in EFMCu
> > - dot3StatsExcessiveCollisions        - always 0, no 
> > collisions in EFMCu
> > - dot3StatsInternalMacTransmitErrors  - implementation specific
> >                                         would probably be 0. 
> > - dot3StatsCarrierSenseErrors         - always 0, Full-duplex
> > - dot3StatsFrameTooLongs              -
> > - dot3StatsInternalMacReceiveErrors   - implementation specific
> >                                         would probably be 0.
> > - dot3StatsEtherChipSet               - deprecated
> > - dot3StatsSymbolErrors               - 
> > - dot3StatsDuplexStatus               - redundant, given in 
> ifMautype
> >                                         always Full-Duplex
> > - dot3StatsRateControlAbility         - always No
> > - dot3StatsRateControlStatus          - always Disabled
> > 
> > Dot3HCStatsEntry is not required for EFMCu interfaces as they 
> > are below
> > 100Mbps.
> > 
> > So in the end we have only 3 counters that have any meaning 
> > for an  EFMCu
> > interface:
> > dot3StatsFCSErrors, dot3StatsFrameTooLongs dot3StatsSymbolErrors
> > 
> > I agree these are important statistics. However we may decide 
> > to provide
> > them in the EFM-CU-MIB, especially taking into consideration 
> > that textual
> > description for these counters should be updated to include 
> > EFMCu specific
> > explanation (e.g. for dot3StatsSymbolErrors).
> > 
> > What do you think?
> > -Edward
> > > 
>