RE: fcovertcpip - N_Port support.

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

One coda to my last note:

> I beleive iFCP's goal is to bypass FC 
> switched networks altogether and it really does not deal with FC based
SANs.

As discussed earlier, one may interface an FC SAN to an iFCP gateway.  So,
in fact, iFCP does deal with FC-based SANs.

As to the complexity of replacing the infrastructure, iFCP leverages
capabilities already implemented in existing ip hardware. The level of
complexity involved is obviously a matter of opinion and best assesed by
those actively doing implementations.

That said, I restate my agreement with the substance of Murali's note
regarding the differences in design goals and feasibility of merging the two
specs.

Charles
> -----Original Message-----
> From: Murali Rajagopal [mailto:muralir@lightsand.com]
> Sent: Saturday, January 13, 2001 6:49 PM
> To: Joshua Tseng; Venkat Rangan; IP Storage Working Group
> Subject: RE: fcovertcpip - N_Port support.
> 
> 
> Venkat/Josh: (With my TC hat off)
> 
> The FCIP as it is written today specifically deals with 
> E_Ports. In other
> words, the FCIP device connects to a FC Switch like any FC Switch.This
> appraoch in theory could be extended to include N_Port connectivity.
> Tunneling FC data frames in this case is the trivial part. 
> The complex part
> surfaces when attempting to "replace" the functions and infrastructure
> provided by the Fibre Channel Network.
> 
> I am NOT in favor of mixing the two specifications for one 
> good reason - the
> goals are very different. FCIP's goal is to allow FC Switched 
> networks to be
> extended over the IP Network and therefor enhances the 
> existing FC-based SAN
> island connectivity. I beleive iFCP's goal is to bypass FC 
> switched networks
> altogether and it really does not deal with FC based SANs.
> 
> For the above reasons the FCIP specification tends to be 
> relatively simple
> compared to iFCP.
> 
> Regards,
> 
> Murali Rajagopal
> LightSand Communications
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Joshua Tseng
> Sent: Thursday, December 14, 2000 3:57 PM
> To: Venkat Rangan; IP Storage Working Group
> Subject: RE: fcovertcpip - N_Port support.
> 
> 
> Venkat,
> 
> I believe you have a good starting point.  I will offer a
> second area of consolidation--that iFCP and FCIP can adopt
> a common encapsulation and framing method.  This shouldn't
> be too hard--a common encapsulation over TCP that can
> support both FCIP and iFCP should be easy to work out.
> 
> However, the biggest difference between iFCP and FCIP is
> in the addressing and routing mechanisms.  iFCP maps FC
> addresses to IP addresses, which allows IP switches and
> IP routing protocols to route the encapsulated frames to the
> destination FCP Portal over the IP network.  FCIP on the
> other hand relies on the FC switch and FSPF routing protocol
> to route traffic to the final destination, with the role of
> the IP network only to connect tunnel endpoints within the
> FC network.  This is the difference which I am having a hard
> time reconciling.
> 
> Maybe it might be possible to create a common framework,
> (rather than a common protocol), under which both of these
> separate and unrelated mechanisms can be specified.  The
> framework would allow for address translation of FC addresses
> into IP addresses & N_PORT ID's, as well as for tunneling of
> the frames unchanged over the IP network.
> 
> How does this suit everyone???
> 
> Josh
> 
> >
> > In looking at the latest draft-ietf-ips-fcovertcpip-01.txt
> > document, it
> > looks like Section 6.2 (below) could cover the ability to provide
> > connectivity between N_Ports (the area that iFCP covers in
> > great detail).
> > May be it needs some additional work to diagram and explain
> > how this is
> > possible, but if that is the case, what additional
> > capabilities does iFCP
> > proposal provide? Would this not be a natual way to 
> integrate the two?
> >
> > From draft-ietf-ips-fcovertcpip-01.txt:
> > >   6.2 FC Device
> > >
> > >      The protocol encapsulation and mapping of the FC frame
> > described
> > >      in earlier sections applies equally to any pair of FC devices
> > >      (e.g. switch-to-switch or host-to-storage subsystem) 
> wishing to
> > >      tunnel FC frames across an IP-based network.  Any FC routing
> > >      protocol exchanges may still occur transparently to the FCIP
> > >      devices.  It should be noted that Fibre Channel Primitive
> > >      Sequences and Primitives are not exchanged between
> > FCIP devices.
> >
> > Regards,
> >
> > Venkat Rangan
> > Rhapsody Networks Inc.
> > http://www.rhapsodynetworks.com
> >
> 
>