Subject: RE: iFCP as an IP Storage Work Item

From: Joshua Tseng <[email-masked]>
Date: Sat, 13 Jan 2001 22:09:00 -0800

YP,

I think we are losing sight of the original topic.  The objective is
not to preserve ALL of the existing investment in the SAN environment.
Indeed, if everything in Fibre Channel worked great and met everyone's
needs, then there would be no need for the IPS WG, iSCSI, and iFCP.
Rather, the FC storage transport has unresolved issues that can be
addressed with IP, and so we are here to figure out how to transport
block storage data over TCP/IP.

IMO, iFCP is very consistent with the IPS WG's objectives in this
regard.  One day, iSCSI will solve all of our problems by integrating
all components of block-level storage networking natively on to TCP/IP.
But until that day, iFCP is an attractive solution that fixes the
"squeaky wheel" (i.e., Fibre Channel networking) by replacing it with
a working wheel (i.e., IP networking).  And it does it in a way without
the need to buy a brand-new car (i.e., iSCSI).  And even after iSCSI
becomes a reality, there will still be a huge installed base of FC devices
that will benefit by utilizing iFCP.

See below for responses to your comments:

> Yes, we are now talking the right area.  However, I don't see 
> how iFCP will
> help preserve the software and hardware investment of SAN 
> environment made
> by customers.  Here is my understanding of the investment 
> made by customers
> in SAN environment.  (Experts of SAN can certainly correct me.)
> 
> 1. Software from Oracle, Veritas, and Logato running in block address
> instead of file system address.  I am pretty sure none of 
> those software is
> specifically programmed for FCP devices.  In fact, they treat 
> everything
> like "hard disks or tapes" whether they are ATA, SCSI, FCP, 
> or RAID. Shark
> and Symmetrix mentioned by you appear to the application software as
> reliable hard disk devices.
> 
> 2. SAN management and configuration software.  These are 
> typically provided
> by storage device manufacturers.  The software talks to the 
> storage devices
> through a separate Ethernet connection.  Most storage boxes 
> use SNMP to send
> and get Management Information Blocks (MIBs).  Again, iFCP is not
> particularly helpful in saving the investment in this area.
> 
> 3. Hardware investment like routers and switches.  The Name 
> Server inside
> the switches provides target device discovery function.  With 
> Java support,
> the switches provide customers the comfort at home using a 
> browser to log
> into the switches to check connectivity and do zone and 
> domain management.
> In such case, FCIP is in a better candidate to preserve the existing
> investment.

Preserving FC switches is not the objective of iFCP.  Fibre Channel's
limited networking capabilities is THE issue that needs to be resolved.

> 
> 4. Finally, the HBA's inside the servers and storage devices. 
>  I can assure
> you, every HBA manufacturer will have device driver to do 
> FCP, iSCSI, iFCP,
> or FCIP stack processing, whatever protocol chosen by the 
> customers.  The
> protocol stack processing are done inside the IC by microcode, not the
> device driver.  Even MicroSoft Winsock Direct and TCP Remote 
> DMA will be
> implemented in the microcode of the IC to offload the host 
> protocol stack
> processing. No software investment is made by customers.  
> (The drivers are
> free with the HBA.)
> 
> In all, if I may summarize, the strongest argument iFCP has 
> is the OSPF
> routing and scalability.  But, FCIP gets OSPF routing in the 
> IP plane too.

iFCP and FCIP have nothing to do with OSPF.  I think your statements
show that you do not understand iFCP and its objectives.  I would
have hoped that those critical of iFCP would have at least a minimal
understanding of it.

> For the scalability, storage-device attachment to servers is 
> somewhat static
> and confined, unlike the HTTP which requires huge amount of 
> connectivity and
> IPv6.  No Internet or dot com companies would need 16 million 
> block-device
> addresses allowed by the 24-bit D_ID of FCIP at one time.  :-)

In case you missed Charles' e-mail, he already answered your address
space issue.  However, there are other ways in which iFCP facilitates
the scalability of a storage network.

For example, SSP's need to be able to manage storage traffic flow
between many different independent autonomous network systems, as they
will need to separate their own network from their many customers'
networks, and their customers' networks from each other.  IP has
this capability through the combination of OSPF and BGP routing;
Fibre Channel does not have the equivalent to BGP.  Therefore, using
a Fibre Channel fabric and FCIP alone, the SSP will need to set up
a large number of small, independent, and non-interoperable SANs.
IMO, this will be difficult to manage and scale.

Furthermore, as Wayland pointed out earlier, a single large FC fabric
stretched over multiple WAN links by FCIP is vulnerable to temporary
disruptions in the IP network which may trigger reconfigurations in
the FC fabric, such as reallocations of DOMAIN_ID's.  iFCP addresses
this issue by assigning N_PORT ID's locally, eliminating the dependence
on a central addressing authority and the need for any "Class F" traffic.
The stability and scalability of a large storage network is thus improved.

Josh
> 
> Y.P. Cheng, ConnectCom Solutions.
>

---

From: "Y P Cheng" <[email-masked]>
Date: Mon, 15 Jan 2001 08:40:41 -0800

> have hoped that those critical of iFCP would have at least a minimal

Josh,

Had I stayed with the topic of "saving the customers' investment in FCP
stack" I would have done better and not invited the above statement.  :-) I
have no doubt that you are a very good and wonderful network engineer.  But,
I am afraid, iFCP simply is a better mouse trap solving the same problem as
that by iSCSI.

After reading the iFCP draft carefully, I can't help but conclude that by
connecting N-Port to IP directly iFCP usurps the fibre channel Extended Link
Services and replaces class F traffic by all the wonderful stuff like EGP,
BGP, OSPF, etc., offered by the Big Internet.  I found the iFCP effort
overlaps with iSCSI and it provides no additional benefit.  As you have
indicated that iFCP provides a transition into the iSCSI world of the
future.  We must agree that initially even iSCSI storage devices will have
FCP or SCSI devices "inside the box".  This is because the storage industry
will take some time to change its infrastructure to produce iSCSI drives.
On the other hand, the iSCSI HBAs will be available quickly -- I hope you do
give me more credit in knowing the HBA world. :-)  Therefore, it is very
easy for the Network Storage Industry to have an iSCSI target adapter inside
its box to communicate with the iSCSI hosts and clients.  If iFCP is a
viable solution, the HBA industry can produce iFCP target and host adapters
just as quickly as the iSCSI adapters.  Trust me, if we can implement the
Fibre Channel and InfiniBand specifications, we can do iFCP.  I do hope you
see my logic now.

Therefore, while iFCP may be a better mouse trap than FCIP, IMHO, it is
providing the same solution as that of iSCSI.

By the way, lets hear from other folks on this topic, please!

---

From: "Douglas Otis" <[email-masked]>
Date: Mon, 15 Jan 2001 11:22:56 -0800

Y.P.

A company's success with ST-506 leveraged off an inappropriately simple
interface, floppy, and has now monopolized drive interfaces where SCSI
enjoyed a 10 year lead.  iFCP has potential in that it attempts to make
fewer changes to a complex but stable interface (some may argue not stable
enough).  I encourage those working on both FCIP and iFCP to share a common
encapsulation and define node handling in a separate proposal.  There is
significant differences between iSCSI and iFCP.  Problems in iSCSI proposals
have already been solved with FCP so unless there is a problem, what is
being fixed?  What limitations with FCP merit iSCSI?  Let the marketplace
decide as SCTP may obsolete choices made in iSCSI.  The IPS WG should
attempt to minimize variants of a common theme.  In that respect, iFCP seems
to be more in line than does iSCSI but, there are many wishing to make a
career out of iSCSI.  One wonders if they will have time should iFCP provide
a stable solution first.

Doug

---

From: "Ken Hirata" <[email-masked]>
Date: Mon, 15 Jan 2001 10:48:52 -0800

Just a nit, see embedded comment.  Ken

Joshua Tseng wrote:

> the FC fabric, such as reallocations of DOMAIN_ID's.

Reallocations of Domain IDs will not occur without administrative
intervention if the switches in the Fibre Channel Fabric comply with
the Methodologies for Interconnects (FC-MI) specification.

>  iFCP addresses

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