RE: iFCP as an IP Storage Work Item

[Wayland Jeong <wayland@troikanetworks.com>]

I am in support of having iFCP as a IP Storage Work Item for the following
two technical reasons.

1. FCIP is currently not fully specified.

As it stands today, FCIP relies on the concepts of Autonomous Regions (AR's)
and Border Switches (BSW's). The role of a BSW and the structure of AR's in
a FC fabric are not currently well defined in FC-SW-2 (btw, I am willing to
be educated here). A new effort within T11, FC-BB-2, has the charter for
encompassing connectivity to IP networks, but the current BB specification
only addresses ATM and SONET. I have no doubt that T11 can solve these
problems, but without seeing a proposal, it is difficult for me to support
FCIP in its current form.

2. iFCP is a more robust way of connecting SAN islands.

As I understand it, an FCIP connected wide area SAN is virtually a
contiguous fabric (maybe not from a routing perspective, but at least from a
naming perspective). I believe that the Achilles heel of FC fabrics is its
use of a single coherent name space and its reliance on distributed services
(i.e. fabric SNS). When two remote SAN's are connected together,
re-configurations in one SAN will impose a re-configuration in the other
SAN. SSP's for example, have to jump through hoops to avoid these issues
(they don't like the idea of having their customer networks have the ability
to re-configure their data center). Furthermore, when AR's with conflicting
domains are connected, those domains become isolated until the global domain
assignments can be made. I don't see this as a very scalable solution. The
iFCP gateway definition will more effectively isolate FC SAN island's
allowing for connectivity over legacy IP networks, without tightly coupling
the remote storage devices. 

I would like to put one caveat on my position. I want to see iFCP extended,
fully embracing connectivity to existing FC fabrics (i.e. E-ports) and fully
supporting multi-protocol SAN's (IP, VI, etc.).

-Wayland