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

[Douglas Otis <dotis@sanlight.net>]

Charles,

Assurances are made with the fabric timeout but you do not offer a
time-stamp to keep this promise.  TCP will try well beyond a FC fabric
timeout.  A cable swap as example could exceed nominal delays.

Would you see it possible to make a separate proposal to cover just
encapsulation and another proposal to include iFCP specific link services?
For those wishing just a tunnel, the encapsulation proposal, with a small
(perhaps optional) iFCP specific field, could serve both purposes.

Doug


> 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
>