RE: iFCP: FC-BB exists, why invent something new?

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

See my remarks below.

Charles
> -----Original Message-----
> From: Y P Cheng [mailto:ycheng@advansys.com]
> Sent: Friday, December 15, 2000 12:17 PM
> To: IPS Reflector
> Subject: RE: iFCP: FC-BB exists, why invent something new?
> 
> 
> > > restricted to FCP). What does iFCP bring to the table that
> > > FC-BB does not already provide?
> > > -Matt
> > >
> > iFCP allows routing storage traffic between individual
> > FC devices over an IP network.  FC-BB only bridges SAN islands.
> > As you are aware, there is a very significant difference
> > between bridging and routing.
> >
> > The former (FC-BB) requires the routing to be performed by
> > FC switches.  The latter (iFCP) has the routing performed by IP
> > switches.  Since I work for Nishan, my opinion is the latter is
> > much superior, but I have to admit there may be situations where
> > a simple bridging/tunneling implementation will be sufficient to
> > address a particular requirement.  BUT, I also believe
> > there will be situations, especially with increasing storage
> > networking demands, that the latter will be needed to achieve
> > the required scale of storage networking deployments that will
> > be needed in the near future.
> > Josh
> 
> Taking my technical hat off, as a business person, may be I can say
> something that Josh did not say. Nishan is in business of 
> routing.  They
> wish to connect IP networks directly to FC nodes (N, NL, F, 
> and E) that do
> not have FC-BB functions.  They are in business to replace BSW ports
> Therefore, they propose iFCP, like a NAT device, to map the 
> S-ID and D-ID
> into unique fibre channel addresses in other FC domains.
> 
> On the other hand, by saying an FCIP device being a bridge 
> and tunneling
> device in connecting to the E-port with FC-BB functions, Josh 
> simply says
> that FCIP depends on BSW for routing which is not scalable to 
> IP network.
> There are companies making FCIP devices.  But, the FCIP 
> device is inferior
> to iFCP in its capability of routing.  Nishan certainly is 
> not interested in
> FCIP devices.
> 
> From an end user point's of view, should there be a winner 
> between FCIP and
> iFCP?  I believe they will coexist.  As an HBA manufacture, I 
> would like to
> be able to connect to either iFCP or FCIP device without 
> having two sets of
> microcode.  This is why I believe we should have a single 
> specification for
> iFCP and FCIP.  May be all we need is a common frame format 
> between them.
> The N- or NL-nodes can care less about routing or tunneling. 
> Just make sure
> FLOGI and name services for discovery staying transparent.
> 
> Am I right in this assessment?
> 

In a word, no. With any storage gateway, compatibility at the storage device
interface is orthogonal to the underlying storage network implementation to
which the gateway provides access.

In that regard, iFCP is predicated on the assumption that the Fibre Channel
to iFCP gateway interface, whether it be N_PORT, E_PORT or whatever, is
fully compliant with all applicable FC standards.  An FC adapter, storage
device, or FC switch connecting to such a device will require no change
whatsoever.

Charles