Re: Hari as 10 Gig Fibre Channel
Bradley,
As a standards participant, you know that specific processes are defined
at
specific locations within the standard. It is imperative that people
think
about the defined processes of the different functional layers of a
PHY. There
is a reason for their being there. My technical argument is that Hari
violates
the relationship of the PCS, PMA and PMD for non block 8B10B encoded
PHYs as
defined in previous versions of 802.3.
As far as Hari being a proposal, I was not concerned, until it was
proposed as
being universal for all PHYs. In reality Hari is predatory to PHYs that
are not
8B10B encoded, increasing the cost of other PHYs, reducing their
economic
competitiveness, creating a potential market lock. Until the actual
PHYs are
defined, using the label "optional" actually makes it the sole
alternative.
The SERDES, interface that was codified by another standards body, has
been
adopted by most, if not all, of the exiting 10G transmission equipment
vendors.
SERDES uses more pins than Hari. It does not have the reach of Hari.
(Hari can
be used as a backplane interface.) From what I have seen of the SERDES
implementations, it is more universal for different PHY encoding schemes
than is
Hari, maintaining the PCS/PMA/PMD defined relationship. I however am
not making
a recommendation for SERDES, because the PHYs themselves have not been
fully
defined. I can not make a technical recommendation because the PHY
technical
functional issues have not been defined.
I understand that Hari is already being implemented in ASICs for 10GbE,
specific
to the 8B10B PHY. I think that is great for some of the LAN PHY
people. As
such, Hari is a LAN PHY specific implementation. It will allow early
customers
to evaluate the network architectures for 10GbE within that limited
scope.
Thank you,
Roy Bynum
"Booth, Bradley" wrote:
> Roy,
>
> I read your email and as someone who has worked on IEEE 802.3 standards
> developments in the past and is looking forward to working on more in the
> future, I felt a bit insulted. If you don't like the Hari proposal, that is
> fine but don't make non-technical arguments and accusations in hopes of
> having it thrown out.
>
> As a system architect and a silicon designer, I like that Hari is being
> proposed. I like having standardized interfaces, as it allows me to
> partition my design as I see fit. If I should decide to interface to a PMD
> device, I would like the PMD to use the same interface protocol as I do.
> That may end up being Hari for a LAN PMD or something else for a WAN PMD. I
> also like that it is an interface that may see a broad spectrum of
> applications (FC, Infiniband, etc.) as this helps to increase the
> availability and reduce the cost.
>
> As for Hari, it is just a proposal that's on the table. It may not be the
> final solution that we standardize. Anyone designing a product prior to the
> standardization of 802.3ae understands that the product may not be standards
> compliant. Such was the case with 802.3z, and such will be the case with
> 802.3ae. There will be companies that are able to show products first,
> because they've participated in the standards development and hedged their
> bets. The advantage to the HSSG is that will enable a proof of concept and
> show the market that 10 GbE is viable. It will also help us develop the
> standard, much like the early 802.3z products helped develop the 802.3z
> standard.
>
> I would respectfully request that you apologize to those that have made the
> Hari proposal.
>
> Sincerely,
> Brad Booth
>
> -----Original Message-----
> From: Roy Bynum [SMTP:rabynum@xxxxxxxxxxx]
> Sent: Sunday, November 28, 1999 10:32 PM
> To: rtaborek@xxxxxxxxxx; rtaborek@xxxxxxxxxxxxx
> Cc: HSSG
> Subject: Re: Hari as 10 Gig Fibre Channel
>
> 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. 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!
>
> 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. 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.
>
> 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.
>
> 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. 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. 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. 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.
>
> Thank you,
> Roy Bynum
>
>