RE: iFCP fabric attachments

[Joshua Tseng <jtseng@NishanSystems.com>]

Venkat,

> 
> Robert,
> 
> I think when we combine the FCIP proposal and iFCP proposal, 
> you would get
> what you are asking for. That would provide connectivity 
> between FC switches
> using the FC B_Port functionality and IP FCP Portal connectivity. The
> integrated proposal needs to work on things such as Principal Switch
> selection, DomainId distribution among the FC switch across 
> islands etc.
> This is a combination of Fabric Controller and Name Server 
> functionality of
> FC-SW-2 and FC-GS-3 proposals. One thing I am curious about 
> is the FC Name
> Server Object's IP address field, carrying the mapping of DAP 
> to IP address.

I'm afraid the prospects of merging iFCP and FCIP are not that
simple.  Saying they belong in the same document because SOME of the
problems that they address are similar, is like saying that NAT and
GRE (Generic Routing Encapsulation) belong in the same RFC because
they can both be used to connect private networks to and through the
Public Internet.  What you will end up with is a single document that
is twice as long, and describe two totally dissimilar techniques.

The comparison between iFCP and FCIP is in fact quite similar to
the comparison between NAT and GRE (or any other tunneling protocol).
iFCP is quite similar to NAT (maps FC addresses to IP addresses) while
FCIP is similar to GRE (tunnels frames unchanged between two separate
networks).  And my reaction to being asked to merge iFCP and FCIP is
the same as if someone asked me to create one protocol that does both
NAT and tunneling.  How and why would do you do that???

> 
> One other area that is needs attention is support for FC 
> Arbitrated Loops -
> they exist in significant numbers, especially at the target side.

The N_PORT object described in the iFCP document is a generic term
that can also be used to refer to NL_PORTs.  iFCP incorporates support
for Arbitrated Loops.

Josh

> 
> Venkat Rangan
> Rhapsody Networks Inc.
> http://www.rhapsodynetworks.com
> 
> 
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Robert B. Harmon
> Sent: Wednesday, December 13, 2000 10:46 AM
> To: cmonia@NishanSystems.com; ips@ece.cmu.edu
> Subject: iFCP fabric attachments
> 
> 
> I think this is a very interesting proposal, storage gateways are
> possible
> at several different levels, great work.
> 
>  Section 3.3 says:
>     The gateway builds the store of N_PORT network addresses for
>     external devices in the IP fabric by:
> 
>     a) Intercepting name service requests issued by directly-attached
>        N_PORTs and redirecting them to the iSNS name server or,
> 
>     b) Intercepting incoming N_PORT login requests from external Fibre
>        Channel devices.
> 
> Could you explain how this would work in the presence of existing
> Fibre Channel SNS and master switch?
> 
> I noticed on your comparison of FCIP and iFCP that the SAN islands
> contain no Switches or Hubs, N_PORTS are connected directly to iFCP
> devices. Is is possible under to have iFCP gateways and FC switches?
>