RE: iFCP as an IP Storage Work Item

[Charles Monia <cmonia@NishanSystems.com>]

Hi David:

Thanks for the feedback.

To avoid losing sight of the forest for the trees, I'd like to step back and
look at the broader picture.

Our basic position is that the combination of features provided by iFCP,
taken in totality, provide unique and useful capabilities.  Yes, there is
overlap to some degree with other proposals.  iSCSI is a new paradigm for
storage and FCIP will provide users with the ability to use IP in a limited
role to integrate existing FC infrastructures.

As we've stated before in some detail, to the extent that iFCP fully
leverages IP technology as the basis for a FC storage solution, we believe
it offers unique intrinsic value.  Obviously, others may not see it that
way.  At this point, I can't think of what more to say that might change
their perception.  So be it.

As to the technical difficulty of debugging such systems, we've had a lot of
hands on experience here and haven't found it to be a problem.  What's more,
the experts tell me there are network black boxes that do similar kinds of
address mapping, so I assume the problem (if there is one) is manageable. In
any event, I believe reasonable people can disagree on this point.

Charles

> -----Original Message-----
> From: David Peterson [mailto:dap@cisco.com]
> Sent: Monday, January 08, 2001 10:55 AM
> To: Joshua Tseng; ips@ece.cmu.edu
> Subject: RE: iFCP as an IP Storage Work Item
> 
> 
> See comments below [dap]:
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Joshua Tseng
> Sent: Wednesday, January 03, 2001 6:22 PM
> To: ips@ece.cmu.edu
> Subject: RE: iFCP as an IP Storage Work Item
> 
> 
> I believe iFCP should be an IPS work item for the following
> technical reasons:
> 
> 1)  iFCP allows leverage of existing FCP-based driver stacks and
> preservation of the $$$ and @#$!!% that have been invested in them
> by vendor companies and their customers.
> 
> [dap]: Maybe I'm mistaken but I believe connecting an 
> existing FCP-based
> driver stack to an iSCSI gateway or FCIP implementation would preserve
> the investment.
> 
> 2)  IP switching and routing technology is far more mature,
> stable, and scalable than the Fibre Channel equivalent.  iFCP
> leverages this aspect of IP technology, while FCIP does not.
> 
> [dap]: The IP switching and routing technology may also be used
> in a FCIP implementation that is FC-BB-2 capable.
> 
> With regard to your reasons why iFCP should not be permitted:
> >
> > 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.
> >
> > 1. FCIP is aligned with the existing FC-BB-2 work in progress.
> 
> We support independent development of the FCIP separate from iFCP, but
> this point has nothing to do with iFCP.
> 
> > 2. FCIP will function with any existing/future FC-4 protocol such as
> > FCP/FCP-2, VI, SRP.
> 
> Again, this point says nothing about the technical 
> feasibility of iFCP.
> Regardless, iFCP can encapsulate any protocol that FCIP does.
> 
> > 3. A native iSCSI device will provide the same functionality
> > as a device
> > connected to an iFCP gateway.
> 
> Just because iSCSI is an official IPS WG item doesn't mean that
> FC devices will disappear from the face of the earth.  There is still
> a market need to internetwork FC devices over IP networks.
> 
> [dap]: Correct, this is what FCIP and FC-BB-2 are all about.
> 
> > 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 mimimal 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,
> > augmentation data for specific Fibre Channel Extended Link
> > Services, and
> > special handling of specific Fibre Channel Extended Link Services.
> 
> I disagree that the amount of processing is prohibitive in any
> way.  I would like to understand why you feel this way.  As iFCP is
> a gateway protocol, a gateway device typically has more resources
> available to perform these types of operations than an end device.
> 
> > 5. Existing Fibre Channel device addressing capability in
> > conjunction with
> > FCIP is viable at this point in time.
> 
> Again, this says nothing about iFCP.
> 
> [dap]: You are missing the point. Collectively these are the technical
> reasons
> we believe yet another protocol is not required to achieve the same
> functionality
> that iSCSI and FCIP already provide.
> 
> > 6. Manipulation of N_Port ID's as specified in iFCP will make
> > debugging/analysis extremely difficult.
> 
> I am confused as to why you think debugging/analysis will be
> difficult.  Please explain.  I don't think this is true, but even
> if it is, the same can be said of many technologies that are described
> in RFC's.  Take NAT for example.  I and my former network buddies have
> had a #@!&% of a time working with NAT.  Does that mean NAT should be
> outlawed in the IETF?  No, of course not!  It is needed to 
> internetwork
> subnets numbered under the "old" IPv4 regime.  Until we reach the
> promised land of IPv6 everywhere, we will continue to see a 
> lot of NAT.
> Even after IPv6, I still think there will be a lot NAT 
> around, probably
> until the year 2654.  Same thing for iSCSI.  I believe iFCP and iSCSI
> will coexist into the forseeable future.
> 
> [dap]: An always-current translation table will be required 
> to debug and
> analyze the iFCP protocol.
> 
> >
> > 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
> 
> Of course FCIP allows tunneling--it IS a tunneling protocol.  iFCP
> is NOT a tunneling protocol.  iFCP does NOT tunnel Fibre 
> Channel frames.
> Rather, it allows FC devices to be natively internetworked over an IP
> fabric.  You can't do that with FCIP. You can't do that with 
> iSCSI.  iFCP
> is NOT redundant.
> 
> Regards,
> Josh
> 
> > provides the
> > capability for executing the SCSI command set over IP
> > networks.  Creating
> > yet another
> > protocol, such as iFCP, is redundant.
> >
> > David Peterson
> > Cisco Systems, Inc (SRBU)
> > Lead Architect - Standards Development
> > Office: 763-398-1007
> > Cell: 612-802-3299
> > e-mail: dap@cisco.com
> >
> > Bob Snively
> > Brocade Communications Systems
> > Principal Engineer
> > Office:  408 487 8135
> > e-mail:  rsnively@brocade.com
> >
> > Mark Bakke
> > Cisco Systems, Inc (SRBU)
> > Chief Architect
> >
>