Re: [802.3ae] FW: WIS MIB list of open issues and recommendations for resolution
Dan
As one of the people that participated in obtaining the payload label "C2
set to '00011010'b", it was my belief that this label was specific to the
IEEE definition of the Ethernet WAN PHY, which takes the entire "SONET/SDH"
concatenated payload. All other so called mappings do not carry that
definition. "X.86" is specifically "Ethernet over LAPS". It already has a
different C2 label code. "g.GFP" is specifically "Generic Framing
Procedure" which is defined as also being able to provide mapping for
protocols other than Ethernet. What the C2 label for this is going to be,
I have no idea.
Thank you,
Roy Bynum
Orbital View LLC
At 05:36 PM 12/26/2001 +0200, Romascanu, Dan (Dan) wrote:
>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>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
>
>X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
>content-class: urn:content-classes:message
>MIME-Version: 1.0
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_003_01C185FC.AB94E800"
>Subject: WIS MIB ifStack issue summary and proposed resolution
>Date: Sun, 16 Dec 2001 08:41:20 +0200
>Message-ID: <Pine.LNX.4.10.10112131942251.23280-100000@xxxxxxxxxxxxxxxxxx>
>X-MS-Has-Attach:
>X-MS-TNEF-Correlator:
>From: "C. M. Heard" <heard@xxxxxxxxx>
>To: "Hubmib Mailing List" <hubmib@xxxxxxxx>,
> "AToMMIB Mailing List" <atommib@xxxxxxxxxxxxxxxxxxxxxx>
>
>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>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
>X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
>content-class: urn:content-classes:message
>MIME-Version: 1.0
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_004_01C185FC.B6E81380"
>Subject: WIS MIB mandatory objects issue summary and proposed resolution
>Date: Sun, 16 Dec 2001 08:41:39 +0200
>Message-ID: <Pine.LNX.4.10.10112131942252.23280-100000@xxxxxxxxxxxxxxxxxx>
>X-MS-Has-Attach:
>X-MS-TNEF-Correlator:
>From: "C. M. Heard" <heard@xxxxxxxxx>
>To: "Hubmib Mailing List" <hubmib@xxxxxxxx>,
> "AToMMIB Mailing List" <atommib@xxxxxxxxxxxxxxxxxxxxxx>
>
>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>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
>X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
>content-class: urn:content-classes:message
>MIME-Version: 1.0
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_005_01C185FC.C1A2A880"
>Subject: WIS MIB compliance statement issue summary and proposed resolution
>Date: Sun, 16 Dec 2001 08:41:57 +0200
>Message-ID: <Pine.LNX.4.10.10112131942253.23280-100000@xxxxxxxxxxxxxxxxxx>
>X-MS-Has-Attach:
>X-MS-TNEF-Correlator:
>From: "C. M. Heard" <heard@xxxxxxxxx>
>To: "Hubmib Mailing List" <hubmib@xxxxxxxx>,
> "AToMMIB Mailing List" <atommib@xxxxxxxxxxxxxxxxxxxxxx>
>
>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>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
>X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
>content-class: urn:content-classes:message
>MIME-Version: 1.0
>Content-Type: multipart/alternative;
> boundary="----_=_NextPart_006_01C185FC.C9FAE380"
>Subject: WIS MIB - MAU MIB relationship issue summary and proposed resolution
>Date: Sun, 16 Dec 2001 08:42:11 +0200
>Message-ID: <Pine.LNX.4.10.10112131942254.23280-100000@xxxxxxxxxxxxxxxxxx>
>X-MS-Has-Attach:
>X-MS-TNEF-Correlator:
>From: "C. M. Heard" <heard@xxxxxxxxx>
>To: "Hubmib Mailing List" <hubmib@xxxxxxxx>,
> "AToMMIB Mailing List" <atommib@xxxxxxxxxxxxxxxxxxxxxx>
>
>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>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