Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, W G Meetings

From: Edward Beili <[email-masked]>
Date: Thu, 23 Oct 2003 16:56:19 +0200

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-masked]
Cc: [email-masked]
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-masked]]
Sent: Thursday, October 23, 2003 4:59 AM
To: [email-masked]
Cc: [email-masked]; 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-mib-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-epon-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-masked]. 

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

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Lior Khermosh" <[email-masked]>
Date: Thu, 23 Oct 2003 17:24:33 +0200

Edward,
I added some suggestion to amendments to the MAU MIBs in my draft for EPON
to adapt it.
I do not know if it should be under dot3MauType or elsewhere.

Lior

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Edward Beili
Sent: Thursday, October 23, 2003 4:56 PM
To: 'Romascanu, Dan (Dan) '
Cc: [email-masked] '; 'Matt Squire '
Subject: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Drafts, WG
Meetings

Hi,

-Edward

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, October 23, 2003 4:59 AM
To: [email-masked]
Cc: [email-masked]; Bert Wijnen (E-mail)
Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings

*

*

Thanks and Regards,

Dan

---

From: "Lior Khermosh" <[email-masked]>
Date: Thu, 23 Oct 2003 17:24:33 +0200

Edward,

Lior

-----Original Message-----

Hi,

-Edward

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, October 23, 2003 4:59 AM
To: [email-masked]
Cc: [email-masked]; Bert Wijnen (E-mail)
Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings

*

*

Thanks and Regards,

Dan

---

From: Edward Beili <[email-masked]>
Date: Tue, 28 Oct 2003 23:40:02 +0200

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-masked]
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

> From: Matt Squire [mailto:[email-masked]]
> Sent: 28 October, 2003 6:42 PM
> To: Edward Beili; Romascanu, Dan (Dan)
> Cc: [email-masked]
> 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
> > > 
>

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 28 Oct 2003 21:51:20 -0800 (PST)

On Thu, 23 Oct 2003, Edward Beili wrote:
> 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?

and on Tue, 28 Oct 2003, Edward Beili wrote:
> Going back to my original question: what is the procedure for
> updating the MAU-MIB?

What actually needs to be done is to generate some new
OBJECT-IDENTITY definitions to specify OIDs that can figure as
values of rpMauType or ifMauType and ifMauDefaultType.  I think that
the question is whether it is feasible to put the new
OBJECT-IDENTITY definitions in another MIB module or whether they
need to go into the MAU-MIB.  Here is my take on that question.

If the new MAU types could be potentially auto-negotiated, then they
must have corresponding bit positions in ifMauTypeListBits.  In that
case the right thing to do would be to register the new values under
dot3MauType (as has been done for other "standard" MAU types) and to
add corresponding bit positions to ifMauDefaultType.  This would
require that the MAU-MIB be revised and that a new RFC be issued to
replace RFC 3636.  The WG group has the authority to do this if it's
deemed necessary.  I don't believe that small modifications like
this would necessarily affect "time in grade" for the purposes of
standards track advancement since no new objects would be added.

On the other hand, if the new MAU types could NOT be auto-negotiated
but could only be set statically or reported, then there would be no
need to add bit positions to ifMauDefaultType, and the new OID
values could in principle be registered anywhere convenient.  If
they were registered under some top-level OID other than dot3MauType
then there would be no need to revise the MAU-MIB.  This is how
proprietary MAU types are handled, BTW.

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 28 Oct 2003 21:51:20 -0800 (PST)

Mike