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

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
> 
>