RE: Augmenting MAU-MIB - was: RE: EFM MIB Internet-Draft s, WG Meetings
Edward Beili <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Dan, Matt,
While I don't have any strong feelings against EtherLike-MIB I do think that
its usefulness in case of EFMCu interfaces is a bit exaggerated.
I already went through the Control variables.
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
> -----Original Message-----
> From: Matt Squire [mailto:[email protected]]
> Sent: Monday, October 27, 2003 04:47 PM
> To: Edward Beili; Romascanu, Dan (Dan)
> Cc: [email protected]
> Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB
> Internet-Drafts, WG Meetings
>
>
>
>
> > Dan,
> >
> > Here are some arguments for not supporting the EtherLike-MIB
> > (just for the purpose of argument):
> >
> > Let's look at some of the control groups in EtherLike-MIB
> (rfc-3635):
> > - dot3PauseTable - The EFMCu interfaces do not support Pause
> > frames so this
> > may be omitted.
>
> I don't know this is true. I know that it is discussed that
> PAUSE can slow down or interfere with OAM operation on
> Ethernet links. But nothing really stops one from
> implementing PAUSE if they wanted to.
>
> > - dot3Tests - is already deprecated
> > - dot3Errors - is already deprecated
> > - dot3ColTable - no collisions on EFMCu
> >
> > So this leaves just the dot3ControlTable with currently
> > supported Pause()
> > function - see above for applicability.
> >
>
>
>
> > The rest are statistics. There are some rudimentary
> > statistics in the IF-MIB
> > + interface specific stats in EFM-CU-MIB which could be just
> > enough for the
> > trouble shooting.
> >
>
> The Ethernet stats were developed over a number of years,
> mostly with good reason. Throwing them away and just going
> with IF-MIB is quick but short-sighted.
>
> > The advantage of not implementing EtherLike-MIB - well, not
> > implementing a
> > pretty big MIB.
> >
> > Regards,
> > -E.
> >
> >
> > -----Original Message-----
> > From: Romascanu, Dan (Dan)
> > To: Edward Beili
> > Cc: [email protected]; Matt Squire
> > Sent: 23/10/03 17:15
> > Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB
> > Internet-Drafts,
> > WG Meetings
> >
> > My opinion (as a contributor) is that the Etherlike-MIB needs to be
> > supported. It would be the first MIB in the family that would be
> > excepted, and I would like to hear some technical arguments why we
> > should do it. IF_MIB does not provide any Ethernet specific
> objects to
> > manage the interface.
> >
> > I would defer the answer at the second question to John Flick - the
> > editor of the MAU MIB.
> >
> > Regards,
> >
> > Dan
> >
> >
> > > -----Original Message-----
> > > From: Edward Beili [mailto:[email protected]]
> > > Sent: 23 October, 2003 4:56 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: '[email protected] '; 'Matt Squire '
> > > Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB
> > > Internet-Drafts,
> > > WG Meetings
> > >
> > >
> > > Hi,
> > >
> > > I have a question as well - I assume that all new interfaces
> > > defined in
> > > the EFM would be considered as Ethernet Like with mandatory
> > > EtherLike-MIB
> > > and MAU-MIB implementation. Is this correct? Theoretically we
> > > could require
> > > just IF-MIB, considering that most implementors choose not support
> > > EtherLike-MIB.
> > >
> > > We would also need to augment current MAU-MIB with new
> > > dot3MauType instances
> > > defined for EPON and Copper interfaces. Do we have to open a
> > > new version of
> > > MAU-MIB (and who does it) or there's another way of doing it?
> > >
> > > -Edward
> > >
> > >
> > > -----Original Message-----
> > > From: Matt Squire
> > > To: Romascanu, Dan (Dan); [email protected]
> > > Cc: [email protected]
> > > Sent: 23/10/03 16:01
> > > Subject: RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings
> > >
> > >
> > > Just speaking for the draft I submitted, it is a very early
> > draft that
> > > still has a lot of holes. All input is very appreciated.
> > >
> > > In particular, one big nagging question is how these new MIBs are
> > > organized within the existing MIB heirarchy. For the common
> > > stuff, does
> > > it get a new mib-2 branch, or do we somehow hang it under the dot3
> > > branch as something under the Ethernet tree?
> > >
> > > Hoping some of you MIB experts can lend some guidance.
> > >
> > >
> > > -----Original Message-----
> > > From: Romascanu, Dan (Dan) [mailto:[email protected]]
> > > Sent: Thursday, October 23, 2003 4:59 AM
> > > To: [email protected]
> > > Cc: [email protected]; Bert Wijnen (E-mail)
> > > Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings
> > >
> > >
> > >
> > > As you have seen in the announcements that went out in the
> > last couple
> > > of days, the three individual submission Internet-Drafts
> > including the
> > > initial submissions for the EFM MIBs are now available.
> The relevant
> > > URLs are:
> > >
> > > *
> > >
> http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt
> > <http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-m
> ib-00.txt>
>
> *
> http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu-
> mib-00.txt
> <http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu
> -mib-00.tx
> t>
> *
> http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon
> -mib-00.tx
> t
> <http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epo
> n-mib-00.t
> xt>
>
>
> First, I would like to thank the editors of the three
> documents - Matt,
> Edward, and Lior for the effort, and for meeting the submission
> deadline. With this we have already accomplished in time the
> first item
> in our new charter!
>
> Second, I would strongly suggest that you read the proposals and send
> your comments. The final work can happen only with your support and
> contribution, and will be as good as we all make it. Take into account
> that these are only initial proposals, and there is a long way to go.
> All comments need to be sent to the WG list, at [email protected].
>
> Third, if there are other contributions, let me know, and prepare them
> in Internet-Draft format. Our next milestone is issuing the
> first round
> of WG Internet-Drafts in December - we need to know if the
> three drafts
> already published are the only contributions, or there will be other
> I-Ds to be considered.
>
> Now about WG meetings. The Ethernet Interfaces and Hub MIB WG will not
> meet during the November IETF meeting, because of the conflict between
> the IETF meeting and the IEEE Plenary that are scheduled for the same
> week. Personally I think that we do need face-to-face
> meetings, although
> much of the work can be done on the mailing list. The next two
> opportunities for face to face meetings seem to be:
>
> - an interim meeting in Vancouver, BC in January (I do not know the
> exact week) co-located with the IEEE 802.3 Interim meeting
>
> - meeting at the IETF meeting in Seoul, Korea (2/29-3/5)
>
> Everybody who thinks that they can/will attend one or both of the
> meetings - please send me an e-mail - we need a headcount
> before making
> a decision and engaging in any logistics.
>
> If we decide for an Interim, we need to have it approved by the IETF
> Area Director, and we might need a sponsor for the room
> meeting space in
> Vancouver (maybe IEEE 802.3ah can help?).
>
> Thanks and Regards,
>
> Dan
>