RE: fcovertcpip - N_Port support.

[Joshua Tseng <jtseng@NishanSystems.com>]

Hi Venkat,

Sorry about that...I meant 2nd diagram in section 6.1.

I would welcome any of the coauthors of FCIP to step in and
clarify this issue.

Best Regards,
Josh
> 
> Josh,
> 
> > Rather, the 2nd diagram in section 6.2
> 
> We must be reading different documents, because there are no 
> diagrams in
> section 6.2! As I said in my previous email, section 6.2 is 
> not completely
> developed, and since I am not the author of the document, I 
> interpreted
> section 6.2 to include the possibility of connecting direct 
> host-to-storage
> without any intervening BSW switches.
> 
> Are you somehow inferring details presented in section 6.1 as 
> requirements
> for section 6.2?
> 
> Perhaps one of the authors can clarify what section 6.2 is 
> about, and I will
> step out of the way...
> 
> Best Regards,
> 
> Venkat Rangan
> Rhapsody Networks Inc.
> http://www.rhapsodynetworks.com
> 
> 
> 
> -----Original Message-----
> From: Joshua Tseng [mailto:jtseng@NishanSystems.com]
> Sent: Thursday, December 14, 2000 5:39 PM
> To: Venkat Rangan; IP Storage Working Group
> Subject: RE: fcovertcpip - N_Port support.
> 
> 
> Venkat,
> 
> > I think an implementation per fcovertcpip-section 6.2, also
> > requires the
> > mapping of S_ID and D_ID of FC frames at the N_Port entry
> > into routable IP
> 
> I do not read the same thing from section 6.2.  The diagrams in
> the FCIP document do not support your assertion.  There is nothing
> to indicate that FC devices can be directly attached to the FCIP
> gateway, unless an FC switch (i.e., BSW) has also been implemented
> in the FCIP gateway.  Rather, the 2nd diagram in section 6.2 clearly
> indicates that FC traffic must be routed by a BSW before they can
> ingress the tunnel supported by the FCIP gateway.  The BSW is running
> the FSPF routing protocol to determine which tunnel link should be
> used for the next hop.
> 
> > addresses. After this mapping, the FC Frame Encapsulation
> > (section 5.2 of
> > the draft) takes place and these encapsulated frames can be
> > sent out on the
> > link-layer interface of IP address (corresponding to S_ID)
> > directly, without
> > involvement of FSPF or E_Ports/ISLs. The component that does
> > this is very
> > much identical to your iFCP Portal.
> 
> Again, I disagree.  Nothing in the FCIP document indicates that the
> FC frame can be routed without the involvement of FSPF which is
> running on the BSW.  The functionality of the FCIP gateway is
> different and far more limited than that of the iFCP Portal.  FCIP
> is merely a tunnel or conduit, one instantiation of an ISL.  It
> does not do routing.  The FCIP must rely on the FC switch to do
> the routing.
> >
> > There could be other devices whose S_ID and D_ID do not get
> > mapped to IP
> > addresses, and they are routed by FSPF-established
> > E_Port/ISLs. So, both
> > routing planes can coexist. If there is no FC plane routed
> > traffic (i.e.,
> > all name server objects have an IP address mapped to it), it
> > degenerates
> > into an iFCP switch/gateway, as specified in your draft.
> >
> > When we look at the Name Server object in FC-GS-3, it already
> > has provisions
> > to map FC WWN to an IP Address. An implementation can
> > recognize the presence
> > of an IP Address in this object to decide whether they are
> > sent out on the
> > IP routing plane or the FC routing plane. The name server 
> itself is a
> > standard function of all FC-SW-2 switches.
> 
> I believe the IP address object (Object No. 5) you are refering to is
> the IP address used to send and receive IP traffic over the 
> FC network.
> One example of its use is for SNMP messages and traps from 
> the FC interface.
> This object is already in use and it would be inappropriate 
> to attempt to
> use this field to tunnel FC frames originating from the device.
> 
> Regards,
> Josh Tseng
> 
> >
> > Regards,
> >
> > Venkat Rangan
> > Rhapsody Networks Inc.
> > http://www.rhapsodynetworks.com
> >
> > -----Original Message-----
> > From: Joshua Tseng [mailto:jtseng@NishanSystems.com]
> > 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
> > >
> >
>