Subject: iFCP as an IP Storage Work Item

From: "David Peterson" <[email-masked]>
Date: Wed, 3 Jan 2001 11:42:04 -0600

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: [email-masked]

Bob Snively
Brocade Communications Systems
Principal Engineer
Office:  408 487 8135
e-mail:  [email-masked]

Mark Bakke
Cisco Systems, Inc (SRBU)
Chief Architect

---

From: "Douglas Otis" <[email-masked]>
Date: Wed, 3 Jan 2001 14:50:38 -0800

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

---

From: "Venkat Rangan" <[email-masked]>
Date: Thu, 4 Jan 2001 09:04:43 -0800

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: [email-masked] [mailto:[email-masked]]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

David Peterson

Bob Snively

Mark Bakke

---

From: David Robinson <[email-masked]>
Date: Thu, 04 Jan 2001 11:00:56 -0800

I am throwing in my hat to have the WG support both iFCP and
FCIP.  From a business/customer perspective I find believable
markets for both approaches (both of which are still speculation).
From a technical perspective they are similar enough that having
one standard mechanism and one different defacto mechanism will
cause more problems than it solves.

It is clear that the semantic meaning of the two proposed protocols
cannot be merged as they do not operate in the same plane of
traditional stacks. However, from my reading of the two proposals
the encapsulation mechanisms are remarkably similar even though
their semantics are diverge significantly.  What I have started
(before my two weeks away from work, ahhhh...) but haven't
yet finished, is an investigation on standardizing a common
encapsulation protocol for FC over TCP/IP. The the FCIP vs iFCP
becomes a higher level interpretation of the semantics of the
bits instead of also having two completely different stacks.

	-David

---

From: "Ken Hirata" <[email-masked]>
Date: Thu, 04 Jan 2001 18:47:28 -0800

David,

Why do you want to standardize a common encapsulation protocol
for FCIP and iFCP if their semantics and behavior are completely
different?  Would you want tunneling protocol implementations to
also augment certain ELSs even though it isn't necessary for tunneling
protocol operation?

If a common encapsulation protocol was defined, I believe a
negotiation protocol would be necessary to distinguish between
usage as a gateway or tunneling protocol.  After that behavior
would be completely different; the tunneling protocol doesn't
need to augment ELSs, resolve Fibre Channel Address Identifiers
to IP/N_Port IDs, or do anything else the gateway protocol
would do.

                                         Ken

--
Kenneth Hirata
Vixel Corporation
Irvine, CA 92618
Phone: (949) 450-6100
Email: [email-masked]

---

From: David Robinson <[email-masked]>
Date: Thu, 04 Jan 2001 19:27:42 -0800

> also augment certain ELSs even though it isn't necessary for tunneling

If I were to build hardware that either assisted or completely
processed both iFCP and FCIP, it sure would be easier to do
header parsing and other common processing if there was just
one format.

> usage as a gateway or tunneling protocol.  

Yes, either negotiation of a flag bit in the encapsulating
header used to choose which algorithm to use.

I just don't understand why you would want to make them different.

	-David