RE: iFCP as an IP Storage Work Item

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

Hi Charles,

Thanks for offering your perspective. I respect your opinions and I'm sure
my responses would be exactly the same as yours if I were in your position.

> That aside, the general thrust of this note seems
> to reflect business rather than technical concerns.

I am not sure if we can separate the overall market viability from
technical. From our perspective, we do not want the IPS Working Group to
endorse multiple technologies to address same or relatively close solutions.
While it is easy to say that as a vendor it should be possible for them to
support iSCSI, iFCP and FCIP protocols, the cost of developing a solution
that addresses all three (which includes not just product development but
testing, certifying and validating interoperable solutions) is something
that we as a vendor would not like to be drawn into. If you think this is a
business reason, and should be ignored, we disagree with that opinion.

> Such confusion, if it exists, is best sorted out in the marketplace.  In
my
> opinion, it's not the business of standards organizations to anoint any
one
> technology by picking winners and losers (as some would apparently wish).

The standards organizations often pick something and others are forced to
support that. We could let the marketplace decide, but that can be an
expensive option for the market and can be detrimental to all vendors. As an
example, while we are arguing about iFCP, FCIP and iSCSI, InfiniBand may
enter the market and with a coherent proposal, may make this irrelevant.

I assume that you agree that the combination of iSCSI, FCIP and iFCP has
redundant technology elements. We believe the IP Storage Working Group needs
to address the redundant parts which may mean picking something. When it
does, we expect vendors to adopt and support what is picked. Do you not see
a role in standards bodies to pick some technology? If you do not, why is
iFCP being brought to the IP Storage Working Group as a work item?

> Such assertions about processing overhead are totally without
> foundation or substance.

I do not think so. To perform cut-through routing, we only need to examine
the first 8 bits of a frame (the domain id part of D_ID) to send it to an
E_Port. If it is within the switch, you can do so by examining the first 24
bits of the frame (D_ID). Typically, most switches can do this by adding
less than two to five microseconds to the latency. To perform a lookup to
establish the From and To of both S_ID and D_ID and substitute the addresses
and recompute a new CRC or digest would, in my opinion, take more cycles.
Evidently, you seem to disagree, which is fine.

Regards,

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
Charles Monia
Sent: Thursday, January 04, 2001 12:46 PM
To: Ips@Ece. Cmu. Edu
Cc: Venkat Rangan
Subject: RE: iFCP as an IP Storage Work Item


Hi Venkat:

The issues you raise have been discussed at length before (but apparently
not to your satisfaction). That aside, the general thrust of this note seems
to reflect business rather than technical concerns.

Within the parameters of the WG charter and IETF ground rules, it's my view
that the ips wg needs to be a vehicle for bringing high-quality solutions to
the marketplace, not obstructing technologies because they are inconvenient
or conflict with someone's business model.

See other responses below.

Charles

> -----Original Message-----
> From: Venkat Rangan [mailto:venkat@rhapsodynetworks.com]
> Sent: Thursday, January 04, 2001 9:05 AM
> To: David Peterson; Ips@Ece. Cmu. Edu
> Subject: RE: iFCP as an IP Storage Work Item
>
>
>
> 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.
>

Such confusion, if it exists, is best sorted out in the marketplace.  In my
opinion, it's not the business of standards organizations to anoint any one
technology by picking winners and losers (as some would apparently wish).

> 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.
>

To the contrary, the iFCP gateway model dovetails nicely with existing FC
infrastuctures.  iFCP's strong point is that the interface to existing FC
networks becomes a gateway implementation issue.

> 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.
>

Whether or not such support is trivial is, of course, a matter of opinion.
Nonetheless, you seem to have missed the point. iFCP enables the gateway
implementation to conceal the FC infrastructure.  Given Fibre Channel's
historic interoperability problems, some would consider that a benefit.

Anyhow, the behavior on the FC side of the device is, of course, governed by
the applicable FC standards (or their proprietary equivalents). It's not
required for iFCP devices to interoperate with one another and hence doesn't
belong in the spec.

Since this issue has been mentioned a number of times, an informational
appendix giving such implementation examples would apparently be useful.

> 4. iFCP adds cost to deployment
>
> End nodes may be forced to support both FC N_Port and iSCSI.

Forced by whom? Presumably, such concerns reflect market pressures and are
irrelevant as such.

> It is easier
> for end nodes to just support iSCSI when storage network is
> based on an IP
> network.

I assume that's a product development choice.

>.............There is also an additional cost in testing a pure
> iSCSI end node
> with a bridged FC-iFCP end node.
>

Then, I'd suggest that you don't build such products.

> 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.

Such assertions about processing overhead are totally without foundation or
substance.

> 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.
>
>

That's nothing more than unsubstantiated opinion and contrary to our
experience. Apparently, earlier postings on this matter have gone unread.

<other stuff deleted>


Charles
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385