Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB Internet-Draft s, WG Meetings

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

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.
- 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 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-masked]; 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-masked]]
> Sent: 23 October, 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,
> 
> 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-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-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: Edward Beili <[email-masked]>
Date: Thu, 23 Oct 2003 18:20:19 +0200

Dan,

Regards,
-E.

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

Regards,

Dan

ib-00.txt>

*

Thanks and Regards,

Dan

---

From: Edward Beili <[email-masked]>
Date: Tue, 28 Oct 2003 15:19:52 +0200

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

> From: Matt Squire [mailto:[email-masked]]
> Sent: Monday, October 27, 2003 04:47 PM
> To: Edward Beili; Romascanu, Dan (Dan) 
> Cc: [email-masked]
> Subject: RE: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB
> Internet-Drafts, WG Meetings
> 
> 
> 
> 
> > Dan,
> > 
> 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.  
> 
> 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.  
>

---

From: Edward Beili <[email-masked]>
Date: Tue, 28 Oct 2003 15:19:52 +0200

Dan, Matt,

Dot3StatsEntry:

What do you think?
-Edward

---

From: Edward Beili <[email-masked]>
Date: Tue, 28 Oct 2003 15:29:55 +0200

David,

I would certainly use the compliance clause in the MIB to identify needed
parts from the existing MIBs. I was just questioning the rational behind
using a MIB with almost 40 counters our of which only about 3 are
applicable.

-Edward

> From: Harrington, David [mailto:[email-masked]]
> Sent: Thursday, October 23, 2003 06:44 PM
> Yo say the advantage of duplicating the subset of objects you 
> care about
> is that it saves you from implementing a pretty big mib, what about
> those people who want to implement the pretty big Etherlike mib *and*
> the EFM mib? Using your approach means they would need to not only
> implement the pretty big mib but your unnecessary duplication of the
> same functionality as well. How is that a win?
> 
> Would a compliance clause in the EFM MIB identifying which subset of
> objects in the Etherlike MIB are needed for EFM functionality make it
> less painful? This would promote reuse of at least parts of 
> the existing
> standard. 
> 
> dbh
> 
> > Sent: Thursday, October 23, 2003 12:20 PM
> > To: 'Romascanu, Dan (Dan) '

---

From: Edward Beili <[email-masked]>
Date: Tue, 28 Oct 2003 15:29:55 +0200

David,

-Edward

---

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

> Sent: 28 October, 2003 6:42 PM
> 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
>

---

From: Edward Beili <[email-masked]>
Date: Wed, 29 Oct 2003 15:10:18 +0200

Mike,

The new copper interfaces can be administratively controlled and
auto-negotiated, so I guess a new RFC should be issued to replace RFC 3636.
I would suspect that new EPON interfaces can be auto-negotiated as well.

Dan,
Can we ask to open a new version of MAU-MIB?

Regards,
-Edward

> From: C. M. Heard [mailto:[email-masked]]
> Sent: Wednesday, October 29, 2003 07:51 AM
> To: [email-masked] '
> Internet-Draft s, WG Meetings
> 
> 
> On Thu, 23 Oct 2003, Edward Beili wrote:
> > 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: Edward Beili <[email-masked]>
Date: Wed, 29 Oct 2003 15:10:18 +0200

Mike,

Dan,

Regards,
-Edward

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 29 Oct 2003 15:14:38 +0200

See in-line. Thanks, Dan

> Sent: 29 October, 2003 3:10 PM
> To: 'C. M. Heard'; Romascanu, Dan (Dan)
> Cc: [email-masked]'; Lior Khermosh (E-mail)

Yes, you can. 

(speaking as chair)

I would like to hear more opinions - especially from the MAU MIB Editor before taking an action.

(speaking as contributor)

I think that we cannot avoid it.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 29 Oct 2003 15:14:38 +0200

See in-line. Thanks, Dan

Yes, you can. 

(speaking as chair)

---

From: Edward Beili <[email-masked]>
Date: Wed, 29 Oct 2003 16:54:49 +0200

You are correct that auto-negotiation is not specifically described in
802.3ah for EFMCu.
The EFMCu ports use master/slave (-O/-R ports) configuration, the master
management entity can detect slave's capabilities via xDSL handshake during
link initialization and choose mutually acceptable capabilities for both
sides (via clause 45 registers).
Note that negotiation of -O/-R configuration per port is not described at
the moment, for example if both peer ports support -O and -R subtypes which
port accepts the role of master and which one the role of slave. I'm going
to raise a comment against the latest draft and require the use of
auto-negotiation for that purpose. The mechanism would be using xDSL
handshake of course and thus be different from clauses 22 and 37.

Regards,
-E.  

> From: Lior Khermosh [mailto:[email-masked]]
> Sent: Wednesday, October 29, 2003 03:53 PM
> To: Edward Beili; 'C. M. Heard'; Dan Romascanu (E-mail)
> Actually I think that L2 auto-neg is disabled for an EPON 
> interface. What
> level of negotiation exist for the copper interface? Can it 
> be distinguished
> in L2 from 10BaseT for instance or is the negotiation only to 
> define between
> VDSL modes of operation.
> 
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Edward Beili
> Sent: Wednesday, October 29, 2003 3:10 PM
> To: 'C. M. Heard'; Dan Romascanu (E-mail)

---

From: Edward Beili <[email-masked]>
Date: Wed, 29 Oct 2003 16:54:49 +0200

Regards,
-E.