Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3ae] FW: WIS MIB list of open issues and recommendations for resolution

Title: FW: WIS MIB list of open issues and recommendations for resolution

The IETF Ethernet Interfaces and Hub MIB WG met during the IETF Plenary meeting in Salt Lake City in the week of 12/10. One of the items in the WG Charter that was discussed during the meeting was the latest WIS MIB http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-01.txt.

The WG identified a list of four open issues, and recommended solutions for their resolution. It was established during the meeting that it would be appropriate if these issues would also be published on the IEEE 802.3ae reflector, so that interested IEEE participants can provide feedback on the issues and the suggested solutions.

Please note that the open issues are related to the IETF WIS MIB proposal, and do not affect the text of the 802.3ae standard.

Comments are welcome on the 802.3ae reflector and/or on the IETF WG list hubmib@xxxxxxxxx

I intent to ask the Chair of IEEE 802.3ae to allocate a slot at the Raleigh Interim meeting for the presentation and discussions of the status of the WIS MIB work.

Regards,

Dan

Dan Romascanu,
Chair, IETF Ethernet Interfaces and Hub MIB WG
 


Title: WIS MIB ifStack issue summary and proposed resolution

On Fri, 14 Dec 2001, Dan Romascanu wrote:
> 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 [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



Title: WIS MIB mandatory objects issue summary and proposed resolution

On Fri, 14 Dec 2001, Dan Romascanu wrote:
> 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 [no] special problems show up,
> 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

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

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



Title: WIS MIB compliance statement issue summary and proposed resolution

On Fri, 14 Dec 2001, Dan Romascanu wrote:
> 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 [no] special problems show up,
> 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

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

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



Title: WIS MIB - MAU MIB relationship issue summary and proposed resolution

On Fri, 14 Dec 2001, Dan Romascanu wrote:
> 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 [no] special problems show up,
> 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

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

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