RE: iFCP as an IP Storage Work Item

[Charles Monia <cmonia@NishanSystems.com>]

> -----Original Message-----
> From: Grun, Paul [mailto:paul.grun@intel.com]
> Sent: Thursday, January 04, 2001 2:54 PM
> To: 'Black_David@emc.com'; cmonia@NishanSystems.com; ips@ece.cmu.edu
> Subject: RE: iFCP as an IP Storage Work Item
> 
> 
> Here's the (crude) way I interpreted what Charles wrote:
> an iFCP device has two sides; an FC side and an IP side.  On 
> its FC side, it
> better conform to the applicable FC standards, including 
> interoperability
> with other iFCP devices.  I agree with Charles that 
> interoperability between
> iFCP devices on their "FC side" doesn't seem like an iFCP 
> problem per se;
> rather it is a function of whatever interoperability exists between FC
> devices today.
> Charles?
> 
Hi Paul:

Basically, I agree with the above.

The job of an iFCP gateway is to present FC-side N_PORTs to the IP-side (and
vice-versa).  Everything else behind the gateway is otherwise opaque (as far
as the IP-side is concerned).

The FC side of the gateway may, of course, support interfaces to other kinds
of FC devices or topologies, such as FC switch elements, arbitrated loops,
you-name-it. Although the gateway must comply with the standards or specs
that apply in such cases, these are not within the scope of iFCP since these
interfaces and topologies are not presented on the IP side of the gateway
and are therefore not a factor in gateway-to-gateway interoperability.

Charles


> -paul
> 
> Paul Grun                                              
> Intel Corporation
> Enterprise Platform Group
> Fabric Components Division
> (503) 677-6768
> paul.grun@intel.com <mailto:paul.grun@intel.com> 
> 
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Thursday, January 04, 2001 1:49 PM
> > To: cmonia@NishanSystems.com; ips@ece.cmu.edu
> > Subject: RE: iFCP as an IP Storage Work Item
> > 
> > 
> > Charles,
> > 
> > Sorry to jump on this one, but I must be misinterpreting what 
> > you wrote:
> > 
> > > Anyhow, the behavior on the FC side of the device is, of 
> > course, governed
> > by
> > > the applicable FC standards (or their proprietary 
> > equivalents). It's not
> > > required for iFCP devices to interoperate with one 
> another and hence
> > doesn't
> > > belong in the spec. 
> > 
> > I hope you meant something along the lines of:
> > 
> >   The FC interfaces on iFCP devices are governed by the 
> appropriate FC
> > standards
> >   (which require no modifications for iFCP) and hence must 
> > interoperate to
> > the degree
> >   required by those standards.  This may depend on 
> > implementation choices,
> > for example,
> >   an E port on a iFCP device would not be expected to 
> > communicate with an N
> > port.
> > 
> > If iFCP were to somehow make Fibre Channel interoperability 
> > worse (e.g., an
> > F port
> > that failed to work properly with N ports), that would be a 
> > severe problem.
> > 
> > Thanks,
> > --David
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > 
>