Subject: RE: iFCP as an IP Storage Work Item

From: "Peglar, Robert" <[email-masked]>
Date: Fri, 12 Jan 2001 08:38:50 -0600

As far as FCP stacks go, it is a truism that no OS
(host) has a native FCP stack.

Today.  (Stay tuned, though; Blackcomb AS is going to
be rather interesting)

That's why the HBA rules.  It's the entity performing
all the translation between what the OSes see as a pure
SCSI universe and the real (or virtual) device FC universe.  
Had we native motherboard FC physical interfaces and OS 
FCP stacks, we would not need FC HBAs. 

But, that's hosts.  Consider the world of devices for
a moment.  No one can argue that there are not a
plethora of FC devices today, all with FCP stacks by
definition.  Plus, many FC devices today are not just
one FC port but multiple, with multiple WWPN and one WWNN 
to achieve higher RAS characteristics.

So while your statement 
> iFCP as way to keep your investment in FCP stacks is a very 
> weak argument.
is certainly true for hosts (initiators), it is certainly
not true for devices (targets).  We even have several current
implementations of FC tape devices (viz. the need for FCP-2,
amongst other reasons).  Some marketing-buzzheads say that
for disk, 80% of the bytes placed into enterprise storage
in 2000 were FC.  Seagate alone produces one million (!)
fully assembled disk units per week, a goodly proportion of
which are FC.  FWIW.

In any event, even though your argument is strong for
initiators, it is weak for targets.  That alone is enough
to keep (at least the) debate going over if iFCP is worthy
for discussion.

If the WG wants to keep iFCP on the back burner, that is
one thing, but I must say to quash the debate now and
invoke cloture is surely the wrong thing to do now given
the IETF way of doing things (rough consensus, working code).
There is little doubt that as a draft that iFCP has a long
way to go, but that is to be expected.

To your point that 'can iFCP co-exist with FCIP', there
is no technical reason (or even non-technical) why it
cannot.  After all, we have had BGP and OSPF co-existing
for approaching a decade now.  Also, there is no doubt
that iFCP is a gateway-oriented proposal, just as there is
no doubt that well-written FCP (or FCP-2) device stacks are 
very reliable.  Having said that, I believe that there probably
will be more initial implementations of FCIP than iFCP, but
that is surely not - among reasonable IETF people - a reason
to quash discussion.

Thank you,
Rob

Rob Peglar
Director, Storage Architecture
XIOtech Corporation
(314) 308-6983

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 11, 2001 11:23 PM
> To: [email-masked]
> Subject: RE: iFCP as an IP Storage Work Item
> 
> 
> 
> 
> Josh,
> 
> iFCP as way to keep your investment in FCP stacks is a very 
> weak argument.
> FCP stacks are not that stable neither that prevalent (there 
> is none in the
> most widespread OS family - Windows).
> 
> A gateway for a single device should be the exception rather 
> than the rule.
> 
> I can support it as a work item ONLY if it plays a real 
> gateway role and
> can coexist with FCIP is some synergistic fashion.
> As a end-to-end proposal is has little value IMHO.
> 
> Julo

---

From: "Y P Cheng" <[email-masked]>
Date: Fri, 12 Jan 2001 11:08:34 -0800

> (host) has a native FCP stack. Today.  (Stay tuned, though;
> Blackcomb AS is going to be rather interesting)
>

With native motherboard FC chips, the BIOS has the necessary code to access
the chip. After booting, the OS transition from BIOS to the chip device
driver.  There is no FCP stack.  There is only the device driver code
supplied by the chip manufacturer. (In other words, different FC chips have
different drivers.)

> to achieve higher RAS characteristics.

You are confused between the device driver and TCP stack.  Most RAID
manufacturers use SDK, Software Development Kit, from HBA manufacturers.
The SDK allows RTOS to build device drivers for the ICs.  The ICs generate
FCP packets.  Unlike TCP/IP, the Fibre Channel IC device drivers are not
aware of the format of the FCP packets.  Therefore, they can not be called
the FCP stack.

> not true for devices (targets).

No, Julo is correct.  The argument is very weak.  The statement is
especially weak if an iSCSI adapter uses the same implementation as an FCP
adapter.  In the adapter implementation, the iSCSI header will be added by
the adapter.  There won't be an iSCSI stack in the OS for adding the iSCSI
headers.  Of course, a stack implementation of iSCSI in an OS is likely
although not efficiently.  Most manufacturers with high performance in mind
will choose to put the iSCSI stack inside the adapter, not in the OS.

Y.P. Cheng, Connectcom Solutions.

---

From: "Douglas Otis" <[email-masked]>
Date: Fri, 12 Jan 2001 15:21:23 -0800

Y.P.,

Hardware and software implementations will benefit from a direct use of FCP
rather than those structures undergoing change to better support new
environments which lead to FCIP and iFCP.  An IP network will not permit a
direct boot in the same manner as SCSI as there are no physically captured
devices.  A normal DHCP-MTFTP to obtain boot sectors will likely prevail in
these environments as alternatives remain unstable.  Emulating an existing
system interface will benefit from a transport that adopts the same
underlying structures and behavior.  The strength of the argument may be
found in simplicity with resulting conformity and stability.  A stable
scheme may be years away otherwise and stability represents strength.

Doug