RE: [802.3ae] FW: WIS MIB list of open issues and recommendations for resolution
Roy,
Could you be more specific and indicate what sections in the WIS MIB
Internet-Draft you refer to, and what needs to be changed in your
opinion?
Thanks and Regards,
Dan
> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> Sent: Thursday, December 27, 2001 8:15 AM
> To: Romascanu, Dan (Dan); HSSG Reflector (E-mail)
> Cc: C. M. Heard
> Subject: 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-mi
> b-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-mi
> b-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-mi
> b-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-mi
> b-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-mi
> b-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
>
>