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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 17:15:12 +0200

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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 17:15:12 +0200

Regards,

Dan

ib-00.txt>

*

Thanks and Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 18:27:36 +0200

Edward,

(speaking as a contributor)

We agree on everything but the statistics. Obviously deprecated groups are deprecated, and non-relevant functions need not be supported. The remaining - statistics objects - are however very useful. They are not too big a MIB (fifteen objects or so?) and the compliance clauses would clarify what is needed. I can hardly see how you can debug an Ethernet interface in their absence, and I do not think that IF-MIB objects or specific EFM-CU-MIB objects can replace them.

Regards,

Dan

> Sent: 23 October, 2003 6:20 PM
> To: Romascanu, Dan (Dan)
> 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.
> - 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.
> 
> 
> 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. 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 18:27:36 +0200

Edward,

Regards,

Dan

---

From: "Harrington, David" <[email-masked]>
Date: Thu, 23 Oct 2003 12:43:41 -0400

Hi,

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: "Harrington, David" <[email-masked]>
Date: Thu, 23 Oct 2003 12:43:41 -0400

Hi,

dbh

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 27 Oct 2003 09:46:33 -0500

> - dot3PauseTable - The EFMCu interfaces do not support Pause 

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.  

> + interface specific stats in EFM-CU-MIB which could be just 

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.  

ib-00.txt>

*

Thanks and Regards,

Dan

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 27 Oct 2003 10:13:45 -0500

Yep, my bad.  Forgot about that half-dup stuff.  

- Matt

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 27, 2003 9:57 AM
> To: Matt Squire
> Cc: Edward Beili; Romascanu, Dan (Dan); [email-masked]
> Subject: Re: Augmenting MAU-MIB - was: RE: [Hubmib] EFM MIB
> Matt,
> Since EFMCu uses the half-duplex mode of the MAC to do MAC-PHY rate
> matching, PAUSE frames cannot be used. The current text of the draft
> (D2.1) states:
> 
> "Both EFM Copper port PHYs are only defined for full duplex operation
> (notwithstanding the definition of PHY-MAC Rate Matching (see 61.2.1)
> which requires that the MAC operates in half-duplex mode for 
> the purposes
> of flow control). PAUSE frame transmission via EFM Copper PHYs is
> therefore precluded, since the requirements of 31B.1 (see Clause 31)
> restrict the transmission of PAUSE frames to DTEs configured 
> to the full
> duplex mode of operation."
> 
> Regards,
> 
> Michael Beck
> Editor, EFM/Copper
> 
> Matt Squire wrote:
> > 
> > > 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.
>

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 27 Oct 2003 10:13:45 -0500

- Matt

---

From: "Matt Squire" <[email-masked]>
Date: Tue, 28 Oct 2003 11:42:15 -0500

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: "Matt Squire" <[email-masked]>
Date: Tue, 28 Oct 2003 11:42:15 -0500

- Matt

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 28 Oct 2003 21:10:46 +0200

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 28 Oct 2003 21:10:46 +0200

Regards,

Dan