RE: iFCP as an IP Storage Work Item

[Charles Monia <cmonia@NishanSystems.com>]

> -----Original Message-----
> From: David Peterson [mailto:dap@cisco.com]
> Sent: Wednesday, January 03, 2001 9:42 AM
> To: Ips@Ece. Cmu. Edu
> Subject: iFCP as an IP Storage Work Item
> 
> 
> The iFCP proposal for encapsulating Fibre Channel frames 
> should not be a
> work item for the IP Storage working group.
> This view is taken by Cisco Systems and Brocade Communications for the
> following technical reasons.
> 

The "technical reasons" given below seem to represent an amalgam of
corporate positioning statements, rather than issues posed for technical
consideration.  In that regard, I don't feel the need to add to Josh's
earlier response other than a few anecdotal remarks.

> 1. FCIP is aligned with the existing FC-BB-2 work in progress.
> 2. FCIP will function with any existing/future FC-4 protocol such as
> FCP/FCP-2, VI, SRP.

For those who don't follow Fibre Channel, VI refers to a mapping of the VI
architecture to Fibre Channel.  SRP , is a mapping of SCSI onto VI (I
believe this is targeted primarily at InfiniBand).  In the context of Fibre
Channel, it is functionally equivalent to FCP.

At any rate, there is no inherent reason why FC/VI (and hence SRP) or any
other upper layer protocol can't be supported by iFCP.

> 3. A native iSCSI device will provide the same functionality 
> as a device
> connected to an iFCP gateway.
> 4. Combining iFCP and FCIP does not make any sense since they are
> implemented using two different routing planes. In addition, FCIP is a
> tunneling protocol and requires minimal processing of the 
> Fibre Channel
> frame. In contrast, iFCP is a gateway protocol and requires much more
> processing such as the reading and modification of the Fibre 
> Channel header,

We don't see a problem.  We expect to keep the wire saturated with
flow-through FC frame traffic at Gb speed.

> augmentation data for specific Fibre Channel Extended Link 
> Services, and
> special handling of specific Fibre Channel Extended Link Services.

From firsthand experience, these are not daunting problems.

> 5. Existing Fibre Channel device addressing capability in 
> conjunction with
> FCIP is viable at this point in time.
> 6. Manipulation of N_Port ID's as specified in iFCP will make
> debugging/analysis extremely difficult.
> 

How did you arrive at that conclusion?  Again, this doesn't jibe with our
experience.

> In summary, FCIP exists today and is well-defined. FCIP 
> provides all of the
> features
> necessary to tunnel Fibre Channel over IP networks.  
> Similarly, iSCSI
> provides the
> capability for executing the SCSI command set over IP 
> networks.  Creating
> yet another
> protocol, such as iFCP, is redundant.
> 

In contrast to approaches which keep FC storage devices at arms length from
IP, iFCP enables such devices to fully exploit the technology.  In that
regard, it is definitely not redundant.

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