Subject: [Hubmib] IETF 50 HUBMIB Working Group Meeting Minutes

From: Steve Moulton <[email-masked]>
Date: Fri, 6 Apr 2001 16:58:32 -0400 (EDT)

The following is the final version of the minutes of the
HUBMIB Working Groupt Meeting at the 50th IETF (Minneapolis).
The copy submitted to [email-masked] will have the slides
attached.  In the meantime, the slides are available at
ftp://ftp.snmp.com/pub/hubmib/ietf50.

I am submitting a copy to Nathan Kohn for submission to the
AToMMIB working group, as I am not on that mailing list.

-------------------------------------------------------------------------

Minutes
HUBMIB (Ethernet Interfaces and Hub MIB) Working Group
Recorded by Steve Moulton
50th IETF
Minneapolis, Minnesota, USA
Thursday, March 22, 2001, 3:30 PM

Welcome by Dan Romascanu.

Agenda Bashing.  No changes from published agenda.

Roughly 18 Present.  

In general information available from the slides will not be reproduced
here.  

Agenda:

.  Introduction, agenda bashing
.  Status of the Working Group
.  Status of the 802.3 Working Group
.  10Gbs Ethernet Management 802.3 ae
.  Power Ethernet Management: 802.3 af 
.  RFC 2665 Editorial Issues
.  Discussions, working group actions, new charter (if relevant).

Administrivia:

.  Working Group Chair - [email-masked]
.  AD and Advisor - [email-masked]
.  New working group mailing list list - [email-masked]
.  To subscribe - send "subscribe <mail address>" to
   [email-masked].
.  Archive: 
   http://www.ietf.org/mail-archive/working-groups/hubmib/current/maillist
.  IEEE 802.3 WG Web page:
   http://grouper.ieee.org/groups/802/3/index.html

Liaison with the IEEE 802.3 WG

    The liaison function was set up by Scott Bradner.  Dan Romascanu is
    the liaison person.  The intent of this was to make 802.3 private
    documents available for those who are actually writing the MIB 
    documents without having to attend IEEE meetings.

HUBMIB Documents Status.

   RFC2108 Hub MIB - leave alone?  
   RFC2668 MAU MIB - MAU MIB
   RFC2665 - Ethernet-like Interfaces MIB
   RFC2666 - ChipSets for Ethernet-like interfaces MIB (Informational).
   
   All documents save RFC2666 are at proposed standard status.
   
   In the mind of the working group chair, RFC2668 and RFC2665 are
   living documents.  There is potential work in tracking changes in the 
   Ethernet world.
   
   Should implementation experience for RFC2108 be gathered to forward it to
   draft status?  While no consensus was established in the room, there
   was a frequently expressed opinion that since little new
   repeater implementation is taking place, there is little value in
   advancing this document.  The question is referred to the area
   director for his opinion.
   
   A discussion took place on the relevant merits of having this document
   status changed to informational or historic.  Since the MIB is in
   fairly widespread use, there was support for moving it to
   informational if IETF procedures would allow it.  Referred to the
   area director.
   
   The room consensus is that implementation reports for RFC2665 and RFC2668 
   should be gathered with the view of advancing these documents to 
   draft status.  An open question is whether these documents should be
   modified to support 10gb interfaces and therefore spun at proposed, or
   if they should be advanced to draft as is.
   
What is happening in the IEEE 802.3 Working Group Nowadays?

   There are three areas of activity:

   .  10 Gpbs Ethernet - 802.3ae
   .  Power Ethernet - 802.3af
   .  Ethernet First Mile - EFM

   The number of participants in IEEE 802.3 in the past 10 months has
   doubled with increased change and interest in Ethernet.

   The IEEE 802.3ae Charter is to define 802.3 MAC parameters and minimal 
   augmentation of its operation physical layer characteristics, and 
   management parameters for Ethernet 10 Gb/s using full duplex operation.
   Note that this takes out repeaters from considerations, since they run
   at half duplex.
   
   In addition to the traditional LAN space, we should consider implications 
   of data rates compatible with OC-192c and SDH VC-4-64c payload rate.
   This has implications at layer 5, and has implications wrt the SONET MIB
   working group.  We probably need to understand how we can work
   together and reuse the models that have been defined there.
   
   The IEEE 802.3af Charter is to define ways to provide power to
   Ethernet devices via the network connection [see slides for details].
   Compatibility with existing equipment is an issue.
   
   Both working groups belong to the 802.3 committee.  Defining management
   from their point of view is providing a set of managed objects, all 
   hardware related, and providing a set of registers and considering 
   other hardware implications necessary to implement these objects.  
   The 802.3 committee explicitly leaves the MIB work to the IETF.
   The statement was made that there are probably 10 or 20 people in the 
   IEEE that fully understand SNMP-based management.  
   
   EFM (Ethernet First Mile) Proposed Charter.  This working group was
   changed from Ethernet Last Mile, due to "last mile == end" connotation.
   The intent is to expand Ethernet applications to subscriber access
   networks, over copper (Ethernet over VDSL), fiber, and PON.
   This group applied for charter last week in the IEEE.  This work
   is not yet approved - we need to be aware of it, but not to approach
   the work yet.  On this round of work, we would like to be fully in sync 
   with IEEE, so that when the IEEE standard is being released, we can 
   produce the MIBs without a year gap.
    
Presentation: Ethernet MIB Updates for 10 Gb - John Flick. 

Please see the slide presentation for the bulk of the material 
(IETF50EtherMib.ppt).

   802.8ae adds three new objects associated with rate control.
   It is not clear that the Ethernet MIB needs to reflect these object,
   particularly since aStretchRatio is a read-write integer that
   can only have the value 104.
   
   Is the equipment going to be able to determine these things on its
   own, or it is going to be set at provisioning time?  
   We need to send a question back to them to clarify these objects.
   Everyone on the mailing list is welcome to comment.
   
   Updates to existing definitions - dot3StatsAlignmentErrors and 
   dot3StatsSymbolErorrs have editorial changes.
   
   Do we need 64-bit error counters?  Some objects can now roll over
   in less than one hour.   Of course, if these counters are rolling in 
   less than one hour, you probably have a problem anyway.
   
   Do we need to reopen the interface MIB?  Or do we define an extension 
   for ifInErrors?
   
   ifTstTabletext and test OIDs have nothing to point to anymore.
   The table died and its replacement table died.  Do we want to 
   define our own test methods?  I.e., do we want a way to do a
   loopback test on an interface via SNMP?  This is an open issue.
   
   We need to fix ifInErrors definition since it currently double-counts 
   symbol errors, since every symbol error causes a FCS error.  We need to 
   update ifMtu mapping to reflect implementations that support greater 
   than 1500.  802.3 does not support MTU > 1500, but many vendors do.
   
   There is a section in rfc2665 that says Ethernet has no layers in ifStack
   table.  There is an editor's note from six years ago that that might
   not always be the case.  It is certainly not the case now.  So this 
   working needs to be fixed.  We need to explain how to use the stack
   interface.
   
   There was such a long lag between IEEE implementing 100mbit and this
   WG dealing with it that many vendors registered their own types. 
   The document should say that should you run into the old vendor specific
   ifType values, this is what you SHOULD do when implementing an agent.
   
   The comment was made from the floor that in general we should tighten
   up this text with respect to MUST/SHOULD.
   
   Action Item:  Get procedure from IANA for fixing the ifTypes mess.
   The interface MIB does request that IANA deprecate these old ifType
   values. 

Presentation: MAU MIB Updates - John Flick.
Slides are in IETF50MauMib.ppt.

   There should be MUST text indicating the relationship between MAU MIB
   and Ethernet MIB and that the implementations must be kept consistent.
   The rest of the changes are covered in the slides.  Note that this new 
   technology does not use repeaters, so the underlying tables need not 
   be realized in this document.

Presentation: WAN Interface Sublayer Management - John Flick.
Slides are in IETF50WisMib.ppt. 

   The edge objects defined by SONET do not match up with the EtherNet
   MIB definitions.  The SONET MIB has 15 minute Ethernet interval counters,
   rather than the traditional SNMP free running counters.  The story was
   told of the old telecom practice of taking pictures of counters on
   phone switches every fifteen minutes (literal snapshots), and how the 
   current practice echoes this historical practice.   The SONET MIB has 
   a table that has values from the current interval, and a 15 minute 
   table.  You can derive the counters from the interval tables.  
   If we do this work, we should do it in cooperation with the 
   SONET guys.  The co-chairs of the AToMMIB working group have asked for
   this issue to be crossposted.  We have a volunteer (Tom Rutt) to 
   contribute an analysis.

   [Note that the AToMMIB working group handles ATM, SONET, and 
   Optical (DWDM) MIBs]

The Power Ethernet MIB (draft-romascanu-hubmib-power-ethernet-mib-00.txt).

   This document is based on 802.3af.  See the main meeting slides
   (ethernet_mib_wg.ppt) for details.  We have several volunteers for 
   document co-editors.  It is nice that there is no legacy MIBs or other 
   curse-of-the-installed-base issues.

New Charter Proposal.

   Please see the slides for details.  The changes are primarily
   with respect to the new work already discussed.
   Note that repeaters are removed from the charter proposal.

   We expect no new implementations of the current MIB documents, so it
   is not clear whether or not these documents should move forward.
   The area director (Bert Wijnen) indicated that this is a good
   thing to consider, but that the pressure to do so is not high
   at the moment.

   There was a discussion of the informational versus historic
   status.  The reason that people are not implementing RFC2108
   is that that companies aren't implementing hubs so much anymore, 
   in favor of switches.

   Bert will research having RFC2108 going informational rather than 
   historic.  The chair's opinion is that having this document go to 
   draft standard is not terribly important, but vendors may think 
   differently.   Please submit implementation reports.

Goals and milestones.

   A final deadline of 2 Jan 2002 for the new documents is proposed.

   Volunteers are 
       Tom Rutt <[email-masked]>
       Dan Romascanu <[email-masked]>
       K.C. Norseth  <[email-masked]>
       John Flick <[email-masked]>
       Avi Berger <[email-masked]> - specific interest in 802.3af
       Mike Ayers <[email-masked]> - specific interest in 802.3ae

End of meeting.

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