Subject: [Hubmib] joint meeting of hubmib and atommib

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 14 Dec 2001 01:50:23 +0200

The Ethernet Interfaces and Hub MIB (hubmib) WG and the ATM MIB
(atommib) WG hold a joint meeting at the 52nd IETF in Salt Lake City.
The main purpose of the meeting was the report from the design team
formed by members of the two WGs in order to provide recommendations for
the WAN Interface Sublayer (WIS) MIB. The participants in the meeting
approved the approach presented in the Internet-Drafts issued by the
Design Team. The participants in the meeting propose that the design
team is transformed in the editors team for the documents. A list of
four open issues and recommendations for resolution will be posted to
the two WG lists, and to the IEEE 802.3ae list. The Hub MIB WG chair
will request a slot for a presentation of the work and open issues at
the interim meeting of the IEEE in January 2002, in order to receive
more feedback from the IEEE. If now special problems show up, the next
version of the Internet-Draft is aimed for WG Last Call.

Regards,

Dan

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:41:20 -0800 (PST)

On Fri, 14 Dec 2001, Dan Romascanu wrote:
> formed by members of the two WGs in order to provide recommendations
> for the WAN Interface Sublayer (WIS) MIB.  The participants in the
> meeting approved the approach presented in the Internet-Drafts issued
> by the Design Team. The participants in the meeting propose that the
> design team is transformed in the editors team for the documents.  A
> list of four open issues and recommendations for resolution will be
> posted to the two WG lists, and to the IEEE 802.3ae list. The Hub MIB
> WG chair will request a slot for a presentation of the work and open
> issues at the interim meeting of the IEEE in January 2002, in order to
> receive more feedback from the IEEE. If [no] special problems show up,
> the next version of the Internet-Draft is aimed for WG Last Call.

Here is the first of the four open issues and recommendations for
resolution.  It applies to the current ETHER-WIS draft, available at

http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-01.txt

Issue Summary:  because the WIS payload mapping -- i.e., 64B/66B encoded
Ethernet data mapped directly into the STS-192c payload capacity, with
C2 set to '00011010'b -- is just one of several Ethernet over SONET
payload mappings, it has been suggested that an additional ifStackTable
layer in between ethernetCsmacd(6) and sonetPath(50) should be present
to indicate what type of Ethernet over SONET payload mapping is being
used.  An alternative suggestion has been to use ifMauType (and
ifMauDefaultType) for this purpose.

Proposed Resolution:  the consensus of the meeting participants was that
the interface layering model used to manage the WIS should be left as
it is in the draft (i.e., ethernetCsmacd(6) over sonetPath(50) over
sonet(39)) because in end systems the WIS payload mapping can identified
without the extra interface layer (it is used whenever ifMauType is one
of dot3MauType10GigBaseW, dot3MauType10GigBaseEW, dot3MauType10GigBaseLW,
or dot3MauType10GigBaseSW) and because there is no need to model payload
mapping information in intermediate systems (e.g. SONET ADMs) that do
not terminate the path layer.  Furthermore, there are no statistics that
an ifTable entry could provide for the WIS adaptation layer that are
not provided in the MAU-MIB already.  It MAY be appropriate to use a
different layering model for other payload mappings (e.g., LAPS/EoS,
GFP, or Ethernet MAC frames over PPP over SONET), but it is not within
the scope of the WIS MIB effort to settle such questions.

Mike

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:41:39 -0800 (PST)

> the next version of the Internet-Draft is aimed for WG Last Call.

Here is the second of the four open issues and recommendations for
resolution.  It applies to the current ETHER-WIS draft, available at

Issue Summary:  should the ETHER-WIS and SONET-MIB objects mentioned in
the ETHER-WIS compliance statement be mandatory for all SNMP-managed
10GBASE-W interfaces?  It has been suggested that in some circumstances
the statistics and status information provided by those objects might
not be required, in which case they could be made optional.  In that
case 10GBASE-W interfaces would require a multi-layer ifStackTable only
if ETHER-WIS and SONET-MIB were supported;  if not, then the usual
single-layer model as would apply.

Proposed Resolution:  the consensus of the meeting participants was
that the ETHER-WIS and SONET-MIB objects mentioned in the ETHER-WIS
compliance statement should be mandatory for all SNMP-managed
10GBASE-W interfaces.

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:41:57 -0800 (PST)

> the next version of the Internet-Draft is aimed for WG Last Call.

Here is the third of the four open issues and recommendations for
resolution.  It applies to the current ETHER-WIS draft, available at

Issue Summary:  during the discussions in the joint meeting it was asked
why the ETHER-WIS compliance statements directly specify the objects
incorporated by reference from the SONET-MIB but do not do so for the
objects incorporated by reference from the IF-MIB, EthernetLike-MIB, and
MAU-MIB -- instead, the text of the document simply states points to the
compliance statements for the latter three MIB modules.  The answer was
that certain of the object groups that are optional in the SONET-MIB
compliance statement are actually mandatory for the WIS application, and
so a customized compliance statement was deemed desirable.  It was then
requested that this point be clarified in the text of the document.

Proposed Resolution:  modify the first paragraph of Section 3.1 as
follows:

*** etherwis.txt	Tue Nov 20 13:23:57 2001
--- etherwis.txt	Sat Dec 15 09:37:36 2001
***************
*** 173,185 ****
  3.1.  Relationship to the SONET MIB
  
     Since the Ethernet WAN Interface Sublayer was designed to be SONET-
     compatible, information similar to that provided by most of the
     members of the oWIS managed object class is available from objects
     defined in the SONET MIB [SONETng].  Thus, the MIB module defined in
     this memo is a sparse augmentation of the SONET MIB -- in other
     words, every table defined here is an extension of some table in the
!    SONET MIB.  An agent implementing the objects defined in this memo
!    MUST implement the objects required by the sonetCompliance2
!    conformance statement in the SONET MIB, and as further detailed in
!    the conformance statement in the MIB module defined in this memo.
  
--- 173,185 ----
  3.1.  Relationship to the SONET MIB
  
     Since the Ethernet WAN Interface Sublayer was designed to be SONET-
     compatible, information similar to that provided by most of the
     members of the oWIS managed object class is available from objects
     defined in the SONET MIB [SONETng].  Thus, the MIB module defined in
     this memo is a sparse augmentation of the SONET MIB -- in other
     words, every table defined here is an extension of some table in the
!    SONET MIB -- and its compliance statement REQUIRES that an agent
!    implementing the objects defined in this memo also implement the
!    relevant SONET MIB objects.  That includes all objects required by
!    sonetCompliance2 as well as some that it leaves optional.
  
Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:42:11 -0800 (PST)

> the next version of the Internet-Draft is aimed for WG Last Call.

Here is the fourth of the four open issues and recommendations for
resolution.  It applies to the current ETHER-WIS draft, available at

Issue Summary:  the next MAU-MIB draft should specify what happens
to the ifStackTable if ifMauDefaultType is changed from
dot3MauType10GigBaseR (or any other 10GBASE-R variant) to
dot3MauType10GigBaseW (or any other 10GBASE-W variant) or vice-versa.

Proposed Resolution:  modify the second paragraph of Section 3.5.1
of draft-ietf-hubmib-mau-v3-00.txt and add a reference to the WIS
MIB document as shown below:

*** draft-ietf-hubmib-mau-v3-00.txt	Wed Jun 27 12:13:00 2001
--- draft-ietf-hubmib-mau-v3-XX.txt	Sat Dec 15 14:24:06 2001
***************
*** 286,292 ****
  
     It is REQUIRED that an agent implementing the interface-MAU related
     objects in this MIB will also implement the Ethernet-like Interfaces
!    MIB, [26].
  
     (Note that repeater ports are not represented as interfaces in the
     Interface MIB.)
--- 286,310 ----
  
     It is REQUIRED that an agent implementing the interface-MAU related
     objects in this MIB will also implement the Ethernet-like Interfaces
!    MIB, [26].  Furthermore, when the interface-MAU related objects are
!    used to manage a 10GBASE-W PHY -- i.e., when ifMauType is equal to
!    dot3MauType10GigBaseW or any other 10GBASE-W variant -- then the
!    agent MUST also support the Ethernet WAN Interface Sublayer (WIS) MIB
!    [27] and must follow the interface layering model specified therein.
!    In that case the value of the object ifMauIfIndex is the same as the
!    value of 'ifIndex' for the layer at the top of the stack, i.e., for
!    the ifTable entry that has 'ifType' equal to ethernetCsmacd(6).  If
!    the interface-MAU related objects are used to manage a PHY that
!    allows the MAU type to be changed dynamically, then the agent SHALL
!    create the ifTable, ifStackTable, and ifInvStackTable entries that
!    pertain to the WIS when ifMauDefaultType is changed to a 10GBASE-W
!    variant (i.e., one of dot3MauType10GigBaseW, dot3MauType10GigBaseEW,
!    dot3MauType10GigBaseLW, or dot3MauType10GigBaseSW) from any other
!    type, and shall destroy the WIS-related entries when ifMauDefaultType
!    is changed to a non-10GBASE-W type.  The agent SHALL also change
!    the value of 'ifConnectorPresent' in the ifTable entry indexed by
!    ifMauIfIndex as specified in [26] and [27] when ifMauDefaultType is
!    manipulated in this way but SHALL NOT otherwise alter that entry.
  
     (Note that repeater ports are not represented as interfaces in the
     Interface MIB.)
***************
*** 3017,3022 ****
--- 3035,3044 ----
          the Ethernet-like Interface Types", work in progress,
          draft-ietf-hubmib-etherif-mib-v3-00.txt, June, 2001.
  
+    [27] Ayers, M., Flick, J., Heard, C. M., Lam, K., McDonald, K.,
+         Norseth, K. C. and K. Tesink, "Definitions of Managed Objects
+         for the Ethernet WAN Interface Sublayer", work in progress,
+         draft-ietf-hubmib-wis-mib-01.txt, November, 2001.
  
  8.  Security Considerations
  
Note:  the MAU-MIB editor is encouraged to wordsmith the proposed text
as necessary to make it more readable or to correct technical errors.
In particular, if ifMauDefaultType is deprecated in favor of a different
machanism for changing the MAU type, then the text will need to be
adjusted accordingly.

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:41:57 -0800 (PST)

--- 173,185 ----

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:42:11 -0800 (PST)

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:41:20 -0800 (PST)

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:41:39 -0800 (PST)

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:41:39 -0800 (PST)

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 15 Dec 2001 22:41:57 -0800 (PST)

--- 173,185 ----

Mike