Subject: RE: WIS ifStack issue

From: [email-masked]
Date: Wed, 5 Dec 2001 15:04:57 +0100

Hi all,

I would like to add some bits of information.

There are many ways to map Ethernet MAC frames over SONET/SDH:
- using LAPS (EoS)
- using PPP (PoS)
- using GFP

In all those cases, the interfaces are stacked and I actually do not 
see the need of the MAU-MIB objects.

When PoS is used, we have the ppp interface in between the 
ethernetCsmaCd and the sonetPath interfaces.

Regards, Italo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 2:52 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: WIS ifStack issue
> 
> 
> If EoS is a adaptation layer and does NOT require trend/fault
> counters (in/out/error bytes/frames) nor configuration.
> I agree that additional objects such as ifMauType is
> a better approach.
> 
> -faye
> 
> 
> >From: "C. M. Heard" <[email-masked]>
> >To: Hubmib Mailing List <[email-masked]>,   AToMMIB Mailing List 
> ><[email-masked]>
> >Subject: WIS ifStack issue
> >Date: Mon, 3 Dec 2001 15:09:53 -0800 (PST)
> >
> >On Fri, 2 Nov 2001, Ayers, Mike wrote:
> > >  I have an issue, which I shall call "the ifStack 
> issue", but I do
> > > not want the publication of 
> draft-ietf-hubmib-wis-mib-01.txt to wait on 
> >it.
> > > The changes to the draft that may ensue due to the 
> resolution of this 
> >issue
> > > are relatively minor in both a relative and an absoulute 
> sense, and it 
> >is
> > > best to have the discussion in reference to the current work.
> > >
> > >  The only reason for this delay is my current level of activity.
> > > I'll get the overview of the issue out ASAP.
> >
> >Mike's workload is still rather high, and he's asked me to 
> help out.  The
> >issue in question was first raised in an e-mail message from 
> Mike to the
> >WIS MIB design team mailing list on Wed, 17 Oct 2001:
> >
> > >  The current interface stacking model does not have a 
> layer between
> > > ethernetCsmacd and sonetPath.  This implies that the 
> current WIS is the 
> >only
> > > way that ethernet will be sent over SONET.  This 
> implication is already
> > > wrong (EoS).  I think we need a new ifType, say 
> ethernet64-66bWIS, to
> > > indicate the adaptation layer in use.
> >
> >Here EoS refers to the Ethernet over SONET mappings being 
> standardized
> >in T1X1.5 and similar proposals in the ITU for SDH.  The 
> concern is not
> >that we need to deal with these alternative payload mappings in the
> >WIS MIB -- we don't -- but rather that the ETHER-WIS layering model
> >should not be designed to exclude such mappings.
> >
> >It was my contention that alternative Ethernet over SONET payload
> >could be accomodated without changing the layering model by using
> >ifMauType/ifMauDefaultType values _other than_ dot3MauType10GigBaseW,
> >dot3MauType10GigBaseEW, dot3MauType10GigBaseLW, and
> >dot3MauType10GigBaseSW to represent them.
> >
> >The design team decided to let the WGs at large debate this issue,
> >and it's one of the items we hope to discuss at the joint Hubmib
> >and AToMMIB meeting.  Relevant e-mail messages that appeared on the
> >design team mailing list are attached to provide some background for
> >the general discussion.
> >
> >Regards,
> >
> >Mike H.
> ><< MESSAGE3.txt >>
> ><< MESSAGE5.txt >>
> ><< MESSAGE7.txt >>
> ><< MESSAGE9.txt >>
> ><< MESSAGE11.txt >>
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at 
http://explorer.msn.com/intl.asp

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 5 Dec 2001 09:09:37 -0800 (PST)

> see the need of the MAU-MIB objects.

I have assumed that the MAU-MIB objects would be implemented for
any ethernetCsmaCd(6) interface because the document that defines
the media-specific MIB module for this ifType (the Ethernetlike-MIB)
specifically requires it.  See RFC 2665 Section 3.3:

   Support for the mauModIfCompl2 compliance statement of the MAU-MIB
   [27] is REQUIRED for Ethernet-like interfaces.  This MIB is needed
   in order to allow applications to determine the current MAU type
   in use by the interface, and to control autonegotiation and duplex
   mode for the interface.  Implementing this MIB module without
   implementing the MAU-MIB would leave applications with no standard
   way to determine the media type in use, and no standard way to
   control the duplex mode of the interface.

It is true, however, that auto-negotiation and duplex type are fixed
when using any of the Ethernet-over-SONET mappings.

> ethernetCsmaCd and the sonetPath interfaces.

Interesting.  I hadn't thought of it, but I guess it that one could
use the ifStack in this way for bridged MAC frames.  When the PPP
link also carries routed frames, one has the curious situation that
the top layer of the ifStack may vary by PDU.  For routed PDUs it
would be the ppp layer;  for bridged MAC frames it would be the layer
above ppp.

Question:  do you have an interface layer in between the
ethernetCsmaCd(6) and sonetPath(5) interfaces when using LAPS
or GFP, and if so, what ifType is used and what statistics are
maintained (i.e. which IF-MIB object groups are implemented)?

Mike