Re: WIS OH
Rich,
Sorry for my late response to your 'headless chicken' fable.
I needed almost a week to cook it well; please enjoy my seasoning. :-)
Once again, be sure that we are not discussing the general
requirement to the PHY. My concern is whether the specific
implementation 'stand-alone PHY' could be allowed in the Ethernet
standard or not. I hope the answer is 'yes', but if not, please
let me know your issues.
As I understand, PHY can be working stand-alone when the Control
register bit 0.10 (Isolate) has been set 1 (electrically Isolate
PHY from GMII). In Clause 22 (22.2.4.1.6), it is noted that the
standard neither requires nor assumes any specific behavior at the
MDI resulting from PHY 'Isolate'.
As for 'headless chicken', please find my comments below.
At 2:20 PM -0700 00.6.15, Rich Taborek wrote:
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02723.html
> Osamu ISHIDA wrote:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02657.html
>> 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:
>> > 2) Separate operation of the 10 GbE MAC and PHY;
>> > 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.
I agree with you that many inexpensive MAC/PHY can be modeled with
your headless chicken analogy; a dead MAC (head) generates no CLK
and hence PHY (chicken body) had better be shot out.
However in the 40km serial PHY, I think you do not necessarily shoot
the headless chicken since it may still be able to run on the track
with his own clock for SERDES. Using another analogy, a serial PHY
attached to MAC via XAUI is analogous to a taxi. The chicken (MAC
with XAUI) can take a taxi (PCS,PMA,PMD) for 40 km trip. The chicken
will not drive the car by himself but order a taxi driver to go.
Even if the chicken lose his head, I think we don't need to shoot
the taxi driver. He know how to drive his car safely while he will
not be ordered anything. Yes, what he should do is just lighting up
the 'Vacancy' (Break Link) until he catches another passenger,
or until the chicken get another fresh (re-booted) head. :-).
In my sense, 40+km optics is a deluxe limousine and hence I like
to have an obedient professional driver rather than driving it by
myself.
Best Regards,
Osamu
> Best Regards,
> Rich
>
> --
>> > 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