Re: Hari as 10 Gig Fibre Channel
Roy,
I hate to say it (with no intent to start a flame war) but this is
one of the most rediculous emails I've seen on this reflector to date.
Knowing the high-level of integrity you have shown in previous
reflector discussions, I can only assume that this was a judgement
error. Please see my embedded comments below for additional detail
on why I believe this to be the case.
> Rich,
>
> Perhaps the NCITS TC T11 is the correct forum to standardize on Hari.
> Please remove it as a specific functional standard within P802.3ae.
As both NCITS and IEEE standards bodies are authorized by ANSI to
generate their respective work, it MAY be possible to do this
in either committee, or possibly NEITHER committee, depending on how
the described work matches with their charter for standards
development. Since the referenced interface appears to match very
closely to the description of a service level interface between
operating layers, it could be handled by either standards body where
the layers exist.
> Please make it possible for the people working on the PHYs to apply
> the functional implementations that are needed for the specific
> PHYs. According to the 802.3 model the PHY specific coding occurs
> within the PCS, not the PMD. Applying Hari between the PMA and PMD
> violates that model!
Now I'm confused. What part of the HARI desciption hinders in any way
the development of a PHY implementation? Rich has on numerous occasions
explained in vivid detail that HARI is not a PHY (though some may wish
apply it as one under specific conditions).
> Hari is only a requirement for those people that decided on the PHY
> of choice before the HSSG got a chance to vote on it/them, and jumped
> the gun on their ASICs.
Really? I can easily envision HARI being used to communicate to a
single-stream scrambled PHY at 10G, a 4WDM PHY at 3.2G/wavelength,
a Multi-level signaling PHY, a single stream 12.5G 8B/10B coded PHY,
and numerous others. No where does HARI cause one or the other of these
interfaces to be cast in concrete, or give it any specific advantage over
the other. As far as someone jumping the gun on an ASIC, THATS THE
WHOLE IDEA OF A STANDARDIZED INTERCONNECT. It allows someone to implement
one piece of a system before everything else is ready. And, if the
standard DOESN'T happen to go in that direction, well tough luck for that
implemenmter. Thats whats called risk, and it exists in any system
built, to varying levels of degree.
> As far as I am concerned those people can implement anything they want,
> as long as they do not make it part of the P802.3ae standard.
Since there is no P802.3ae standard yet, not even a rough draft, I think
you are jumping the gun significantly on this issue. If HARI, by
concensus, IS adopted as a service-level interface option between interface
layers, no one will force you and/or your company to implement it. you
are more than welcome to go through any level of integration you wish
and bury as many of the internal layers as you wish. Thats what is
so great about a standard. It DOES not require that any of the embedded
interfaces inside your box have ANY resemblence to descriptions in the
standard, it only requires that signals in and out of the PHY external
interface be interoperable.
> Right now several people are upset because I have challenged their
> perceived control of the development of 10GbE. I have brought disorder
> where they thought that they had imposed order, their order. They are
> correct. I challenged their perceived view of Ethernet as a confined
> protocol, when they did not understand how Data Link protocols are used
> and what makes them functionally different. They did not understand that
> the developers of GbE brought the disorder first by crossing the boundary
> between confined LAN application and unconfined WAN application.
Roy, this is where I really think you lost it. What you are saying is
that the HUNDREDS of people who contributed to, and endorsed the final
product of 802.3z, had no idea what they were doing. Considering that
many of these people are also the best respected names in the the
world of networking, I find this highly doubtful. In addition you have
made this accusation without providing any specific details about what
is broken that only your key knowldege (out of the thousands of
implemenmters and users) has so far been able to fathom.
> The application of Fiber Channel technology and functionality helped
> cause that disorder. Most FC applications have response timing
> limitations (100x ms) at the application level, which makes most FC
> implementations Local.
OK, you're losing me again. As a member of both developments, I fail
to see what was carried from Fibre Channel that broke 802.3z. The
only thing that was used was the PHY and encoding. 802.3 has used
optical links before, so I don't believe that extending optical
transmission to GBaud signalling rates could have done this. The
use of encoding is also a requirement of any serial transmission,
so I fail to see how the application of a field-proven encoding
technology could have broken something.
Both 802.3z and Fibre Channel are often operated across very long
distances, often with hubs or repeaters in between. I know of Fibre
Channel links spanning multiple STATES (New Mexico to California)
without problem. The same is true for 802.3z links. Once the concept
of a collision domain goes away, just about any distance can be
handled.
> Putting Fiber Channel under applications that do not have those same
> response timing limitations removes the Local only limitation. FC is
> designed for campus facilities, using privately owned fiber.
Tell that to the national labs. Yes they run campus connetions. But they
also operate across distances much greater than any campus size. Some
of these connections use dark fiber and operate with native FC encoding
and protocols, others use various forms of tunneling and maping through
other protocols.
Yes, there are some PHY variants in Fibre Channel that make use of
OFC (open Fiber Control) that do have specific distance limitations
on the PHY (due to link turn-around times). But this is NOT a limitaion
of the standard. No new optical variants even support OFC anymore.
> The GbE people incorrectly thought that they too were making GbE into
> a Local only protocol. They did not understand that the full duplex
> nature of the original Ethernet, applied through 100mb 802.3 was what
> made it truly Local only. Even the electrical full duplex 100BT can
> be used across a long haul fiber system by putting it into an optical
> transducer.
For those that know better, pleae comment. I always though that is was
the requirement to support specific collision domains that made earlier
implementations of Ethernet a "local" network. Of all the 802.3z
implementations made, I do not know of any that are such that they
have collisions.
> Full duplex 100FX has been used across long distances with wavelength/power
> transducers. GbE is taking off as a leased fiber WAN protocol, without
> service operations support.
>
> I am not the cause of the disorder here. The people that did not
> fully understand the implications and applications of what they were
> doing are the cause of the disorder. Please do not codify that disorder
> within P802.3ae.
To the best of my knowledge, the decisions that went forward to generate
802.3z were based on specific knowledge of the requirements of the
standards development process, and the requirements for the end product.
No where in this process did I find people who "did not fully understand
the implications and applications of what they were doing." Quite
the contrary, I found highly intelligent people who knew EXACTLY what
they were doing any why they were doing it.
Roy, I have tried to hold my tongue on my response, because I know you
would not post something of this nature without having something
specifically in mind that was REALLY bothering you. I, and others I'm
sure, are more than willing to hear you out on this issue. But that
means getting down to specific points and issues. Stating that
"its broken because you are ignroant and don't know what you are doing"
does little to encourage open interaction and work toward a solution.
What is needed are specific details of
1. WHAT is percieved to be broken
2. WHY it is percieved to be broken
3. WHAT could be done to correct it
Everyone is willing to listen. Maybe it is possible that we are all
ignorant. No one knows everything. But we are intelligent. That means
we can learn.
As the one with the percieved understanding of the issues at hand, that
leaves it up to you to convince the rest of us that your way is the
correct way. If this is to be done, it must be done with detailed,
structured, rational, clear, and concise information. Unfortunatly, none
of which was provided in this email that I responded to.
Regards,
Ed Grivna
Cypress Semiconductor
>
> Thank you,
> Roy Bynum
>
>
>