RE: iFCP as an IP Storage Work Item

["Douglas Otis" <dotis@sanlight.net>]

David,

Your objections stem from added capabilities of iFCP.  I would not agree
that iSCSI is a replacement for something that is roughly an enhanced
tunneling protocol for FC.  The question I raised was whether FCIP and iFCP
group could agree on an encapsulation structure that would provide needed
extensibility to allow both schemes to function.  Finding such common ground
would be a productive and provide for future developments now excluded by a
narrower view of what should be allowed within encapsulation.  I would be
willing to bet 90% of the transport problems of FCIP and iFCP are shared.
iSCSI does not offer even a facsimile of the same structures and would enjoy
virtually no commonality to either FCIP or iFCP.

How a recovered frame is routed can be considered subject to a different
proposal.  You should view proposals as transport combined with routing
management.  In the case of FCIP, the routing will be just a simple physical
connector.  iFCP expanses this possibility.  If you envision being able to
cope with optional fields, both proposals can live within the same
encapsulation proposal combined with separate definitions of B or N ports
and their requisite routing.  Finding the ability to cooperate at the
encapsulation level of each proposal would allow both groups to share
developing a sound structure that allows the extensibility required by both.
Think of it as FCE-BB or FCE-NT or something similar where FCE is the
encapsulation proposal and BB or NT would be the node definition of the end
point.

Doug

> The iFCP proposal for encapsulating Fibre Channel frames should not be a
> work item for the IP Storage working group.
> This view is taken by Cisco Systems and Brocade Communications for the
> following technical reasons.
>
> 1. FCIP is aligned with the existing FC-BB-2 work in progress.
> 2. FCIP will function with any existing/future FC-4 protocol such as
> FCP/FCP-2, VI, SRP.
> 3. A native iSCSI device will provide the same functionality as a device
> connected to an iFCP gateway.
> 4. Combining iFCP and FCIP does not make any sense since they are
> implemented using two different routing planes. In addition, FCIP is a
> tunneling protocol and requires mimimal processing of the Fibre Channel
> frame. In contrast, iFCP is a gateway protocol and requires much more
> processing such as the reading and modification of the Fibre
> Channel header,
> augmentation data for specific Fibre Channel Extended Link Services, and
> special handling of specific Fibre Channel Extended Link Services.
> 5. Existing Fibre Channel device addressing capability in conjunction with
> FCIP is viable at this point in time.
> 6. Manipulation of N_Port ID's as specified in iFCP will make
> debugging/analysis extremely difficult.
>
> In summary, FCIP exists today and is well-defined. FCIP provides
> all of the
> features
> necessary to tunnel Fibre Channel over IP networks.  Similarly, iSCSI
> provides the
> capability for executing the SCSI command set over IP networks.  Creating
> yet another
> protocol, such as iFCP, is redundant.
>
> David Peterson
> Cisco Systems, Inc (SRBU)
> Lead Architect - Standards Development
> Office: 763-398-1007
> Cell: 612-802-3299
> e-mail: dap@cisco.com
>
> Bob Snively
> Brocade Communications Systems
> Principal Engineer
> Office:  408 487 8135
> e-mail:  rsnively@brocade.com
>
> Mark Bakke
> Cisco Systems, Inc (SRBU)
> Chief Architect
>