RE: iFCP as an IP Storage Work Item

[Wayland Jeong <wayland@troikanetworks.com>]

> Charles and Stephen,
> 
> Considering iFCP as a replacement to iSCSI concerns me as well.  In this
> case I share Stephen's concern that a native iFCP device must always be
> burdened with applying a FCP header into the iFCP frames, as well as other
> issues.  
> 
I'm not sure that anyone has really defined a "native" iFCP device. I would
venture to guess that a "native" iFCP device (or "native" FCIP device for
that matter) would perform encapsulation of FC frames in the HBA rather than
in a physically separate edge device. Thus, the FC HBA and the iFCP gateway
would be collapsed into a single physical realization. With this description
of a "native" iFCP device, I would argue that the overhead in implementing
FCP protocol, which would amount to header manipulations and context
management, is manageable and not entirely different than managing an iSCSI
protocol session. You have many analogous things to deal with like
exchanges, logins, flow-control, etc. So, I don't quite see the extra burden
on such an endpoint product. Now, the issue of replacing iSCSI with iFCP is
an entirely different question and I'm not sure I want to get anywhere near
that one ;-)

> Neither iFCP or FCIP are conducive to HBA's in my opinion.  iFCP as
> a replacement to FCIP is more palatable.   However, in comparing iFCP and
> FCIP, I can't get past iFCP's interoperating issues with non-FCP frames,
> like proprietary FC remote mirroring and clustering protocols and VI/FC.
> 
I'm not sure I understand your comment regarding remote mirroring, but as
far as FC-VI is concerned, a modest extension to the iFCP proposal (support
for FARP) would be all that is necessary to support the transport of VI.

> -Howard 
>
-Wayland