RE: iFCP as an IP Storage Work Item

[Charles Monia <cmonia@NishanSystems.com>]

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