RE: iFCP as an IP Storage Work Item

["Venkat Rangan" <venkat@rhapsodynetworks.com>]

We are also not in support of picking up iFCP as a IP Storage Work Item. As
we indicated in earlier posts (FC-BB-2 exists thread and the FCIP support
for N_Port etc.) we would not be in support of multiple ways (i.e., FCIP and
iFCP) in which FC and IP networks/devices are made to coexist.

In particular, our reasons for not supporting iFCP as a work item are the
following.

1. Confusion in market place

The overall goal of iFCP appears to be to leverage investment in IP
networking technology for networking storage. In this respect, it is closer
in the goal of iSCSI. In a storage network based on IP networking
technology, we see iSCSI as a better alternative. It would be confusing to
present both iSCSI and iFCP as two technologies for using the IP network for
storage. Since the IP Storage Working Group and its members have already
invested heavily in standardizing iSCSI, we do not see much value in
diluting the efforts on multiple technologies towards the same end goal.

2. Support for existing FC networks

FCIP and its coordinated effort with FC-BB-2 supports existing FC networks
better. The interoperability issues between FC and IP networks are
restricted to the border switches. Other infrastructure needs such as FC
Name Server, Fabric Controller etc. are leveraged from standards work
already done in T11 working groups. The argument that iFCP is useful in a
world of FC devices is not very strong, since FCIP is a solution that not
only preserves investment in FC end nodes but also in FC switches.

3. iFCP does not support FC loops and FC E_Port

The drafts as submitted do not handle FC loops and FC switches. There were
some email discussions where authors indicated that these are trivial to add
to iFCP. We do not think it would be trivial to add E_Port support and work
through the interoperability issues between iFCP gateways and FC switches.
Adding FC loop support and E_Port support to an iFCP gateway would make that
gateway device closer to an FC switch, so one could simply use FC switches
with B_Port support and FCIP as the tunneling protocol.

4. iFCP adds cost to deployment

End nodes may be forced to support both FC N_Port and iSCSI. It is easier
for end nodes to just support iSCSI when storage network is based on an IP
network. There is also an additional cost in testing a pure iSCSI end node
with a bridged FC-iFCP end node.

5. FCIP has broader coverage

iFCP implies that it is only useful for translating FCP traffic. FCIP is
able to tunnel all FC traffic through its border switches. It is also
possible to add N_Port connectivity using FCIP, although such an attempt
would also compete with the goals of iSCSI.

6. iFCP addds processing overhead to frames

In contrast to iSCSI, iFCP requires examination of every frame and
substitution of addresses at both iFCP Portals. This has the potential to
add unwanted latencies as well as consume processing overhead on gateways.
Given this, it would be hard to compete with cut-through routing based
products in a pure FC or IP based storage network. We also do not believe
the NAT like function should really be the top priority for the working
group to address. As an example, the first NAT RFC was RFC 1631 (which was
an Informational RFC from the one vendor), well after several other higher
priority items were addressed. We do not believe that FC networks (when
deployed in the context of back-end storage) are running out of address
space to warrant this to be addressed immediately.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
David Peterson
Sent: Wednesday, January 03, 2001 9:42 AM
To: Ips@Ece. Cmu. Edu
Subject: iFCP as an IP Storage Work Item


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