Subject: [Hubmib] Re: WIS ifStack issue

From: "Faye Ly" <[email-masked]>
Date: Tue, 04 Dec 2001 17:51:34 -0800

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

_______________________________________________
Hubmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/hubmib

---

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
> 
> 
> > > not want the publication of 
> draft-ietf-hubmib-wis-mib-01.txt to wait on 
> >it.

---

From: "Faye Ly" <[email-masked]>
Date: Tue, 04 Dec 2001 17:51:34 -0800

-faye

---

From: "Ayers, Mike" <[email-masked]>
Date: Wed, 5 Dec 2001 17:31:09 -0600

Quickly, the problem I see with all this is that using MAU MIB to
determine the payload assumes that a management system will have access to
the original WIS MAU interface.  Consider Bob.  Bob wants to link the two
offices of his company, BobCo.  He gets a good deal from the small operators
in each area (who give him a good price to keep him from going to
BigFatMegaTelco, who is currently trying to muscle them out).  Despite the
local competition, the small operators use BigFatMegaTelco's network to
connect:

	+----------------+
	| BobCo          |
	| Bear Falls, ID |
	| Office         |
	+----------------+
	    ^
          |<---10GBASE-R
	    V
	+-----------+
	|           |
	| SpiffyNet |
	|           |
	+-----------+
	    ^
          |<---OC-384 SONET
	    V
	+------------------+
	| BigFatMegaTelco, |
	| International,   |
	| Incorporated     |
	+------------------+
	    ^
          |<---OC-384 SONET
	    V
	+-------------+
	|             |
	| DotComm.com |
	|             |
	+-------------+
	    ^
          |<---10GBASE-R
	    V
	+-----------------+
	| BobCo           |
	| Black Creek, PA |
	| Office          |
	+-----------------+

	Both operators have OC-384 (translation: fatter than OC-192)
uplinks, so BigFatMegaTelco can't just connect the two ends together - they
must be able to determine which parts of each incoming signal need to be
connected together.  Ideally this can be done without excessive coordination
between DotComm.com and SpiffyNet - they need merely know that the other has
a feed ready and can call BigFatMegaTelco to connect the WIS between the two
of them.  However, neither is going to give their competitor access to their
terminal MAU MIBs, nor will the OC-384 uplinks have the MAU information, but
they would have the ifStack information.

	Okay, that's more detail than I had time for.  Hope it explains what
I'm thinking...

/|/|ike

---

From: "Ayers, Mike" <[email-masked]>
Date: Thu, 6 Dec 2001 11:34:45 -0600

> From: C. M. Heard [mailto:[email-masked]] 
> Sent: Wednesday, December 05, 2001 09:15 PM

> On Wed, 5 Dec 2001, Ayers, Mike wrote:
> > determine the payload assumes that a management system will 
> have access
> > to the original WIS MAU interface.
> 
> But how does having an extra layer between the sonetPath(50) and
> ethernetCsmacd(6) ifStack layers help this?  If a provider's 
> management
> system does not have access to the end system's ifMauTable entry, it
> will not have access to the end system's ifTable and ifStackTable
> entries, either.

	I would expect:

	+----------------+
	| BobCo          |
	| Bear Falls, ID |
	| Office         |
	+----------------+
	    ^
	    |<------ifStack: ethernetCsmacd/WIS/sonetPath/sonet
 	    |
          |<---10GBASE-R
	    |
 	    |<------ifStack: ethernetCsmacd/WIS/sonetPath/sonet
 	    V
	+-----------+
	|           |
	| SpiffyNet |
	|           |
	+-----------+
	    ^
 	    |<------ifStack: WIS/sonetPath/sonet
 	    |
          |<---OC-384 SONET
	    |
	    |<------ifStack: WIS/sonetPath/sonet
 	    V
	+------------------+
	| BigFatMegaTelco, |
	| International,   |
	| Incorporated     |
	+------------------+
	    ^
	    |<------ifStack: WIS/sonetPath/sonet
 	    |
          |<---OC-384 SONET
	    |
	    |<------ifStack: WIS/sonetPath/sonet
 	    V
	+-------------+
	|             |
	| DotComm.com |
	|             |
	+-------------+
	    ^
 	    |<------ifStack: ethernetCsmacd/WIS/sonetPath/sonet
	    |
          |<---10GBASE-R
	    |
	    |<------ifStack: ethernetCsmacd/WIS/sonetPath/sonet
 	    V
	+-----------------+
	| BobCo           |
	| Black Creek, PA |
	| Office          |
	+-----------------+

	So that what goes end to end is not just a SONET path, but a SONET
path carrying WIS encoded data.

/|/|ike