Re: WIS OH
Osamu,
My comments below. This thread is best dealt with in this fashion to keep it in
context.
Osamu ISHIDA wrote:
>
> Rich,
>
> At 10:43 PM -0700 00.6.10, Rich Taborek wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02652.html
> > It seems that there are a couple of issues within this thread:
> >
> > 1) SONET "remote fault" indication to an Ethernet PHY;
> > 2) Separate operation of the 10 GbE MAC and PHY;
> > 3) Others?
>
> Thanks for your clarification of my issues.
> Yes, that's it and no others :-).
>
> Please find my considerations below.
>
> > For issue (1) it seems that the WIS and Ethernet PHY should react as follows:
> > a) Convert the SONET Line/Path AIS into an Ethernet remote fault indication;
> > b) Convert the received data into an error indication. This can be done through
> > the generation of 64B/66B error frames as well as error codes over XAUI and the
> > XGMII.
> >
> > I don't recommend disabling the 64B/66B CODEC due to a SONET side fault. Doing
> > so would compromise fault isolation.
>
> I agree with you that we reccomend not disabling the 64B/66B CODEC
> when WIS detects AIS. Also converting SONET AIS into an Ethernet
> remote fault indication might be fine. However, I think we can
> convert the received data (nothing!) into just idles, not into an
> error indication. Or will you define another EMI randomization
> pattern for your error codes over XAUI?
Good point! However, this link is broken and should be removed from the
configuration. The quickest way to do this seems to be turning a SONET AIS into
an Ethernet remote fault and have the receiving device take the link down
(break link). I see no reason to optimize EMI over XAUI for this scenario.
> > For issue (2) I don't recommend separating the operation of the Ethernet MAC and
> > PHY. The operational state of the MAC should match that of it's associated PHY.
> > Device management should coordinate layer operation stated to ensure
> > consistency. If the PHY goes down, the link, including the MAC should be shut
> > down. This means that an Ethernet PHY should not remain operational if its
> > associated MAC, or XAUI, or XGMII is broke.
>
> I know that my implementation is NOT a traditional Ethernet way.
> Also I never say that 802.3ae should operate MAC and PHY separately.
> I just want to know what might be the problem if I or some other Carrier
> guys should implement them separately.
>
> In my sense, Ethernet MAC and PHY are Computer Application Software and OS.
> The first part of your description is correct; if the Windows 95 (PHY)
> goes down, your PowerPoint (MAC) should be shut down. However, why Win95 (PHY)
> should not remain operational if its associated PowerPoint (MAC) is broke?
> Is it because Microsoft?
>
> What I want to have here is more robust implementation like Linux PHY.
> I don't say all the 802.3ae should be Linux. I think Win95 & PowerPoint
> is worth for the most part of the users.
>
> What I want to know here is what would happen if we try to implement
> PowerPoint on the Linux OS :-). Is it impossible?
The OS/Application analogy is not applicable because of the level of integration
typically associated with Ethernet MAC/PHY elements. At 10 Gbps, all physical
elements containing the MAC and PHY will likely be managed, ensuring that the
left hand knows what the right hand is doing. Using another analogy, a dead MAC
and an operating PHY is analogous to a headless chicken. Would you trust a
headless chicken? I'd shoot the chicken.
Best Regards,
Rich
--
> Best Regards,
> Osamu
>
> > Osamu ISHIDA wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02648.html
>
> -----------------------------------------
> Osamu ISHIDA
> NTT Network Innovation Laboratories
> TEL +81-468-59-3263 FAX +81-468-55-1282
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com