RE: Agree or Disagree to Merge FCIP and iFCP

[Henry Yang <henry.yang@mcdata.com>]

I disagree with merging FCIP and iFCP.

  Henry Yang
 

-----Original Message-----
From: Murali Rajagopal [mailto:muralir@lightsand.com]
Sent: Saturday, January 06, 2001 12:26 PM
To: ips@ece.cmu.edu
Subject: Agree or Disagree to Merge FCIP and iFCP


All:

The FCIP and iFCP address the FC over IP network transport with entirely two
different objectives.
FCIP is a simple-minded tunnel that wants to see the basic FC connectivity
extended over IP network. Period!!! iFCP's goal is much more than that ....
But that does not mean that we should combine the two just because it
appaers as though FCIP looks like a subset of iFCP.

I am speaking for the authors of FCIP collectively, and in our opinion
mixing the two in a single spec. or a common encapsulation method has little
meaning.Yes we understand that everyone would like to see a single FC Over
IP network solution and not two. But FCIP is really an extender for FC
Switch Fabrics while iFCP is attempting to "replace" the FC Switching
fabric. In this sense, iFCP is not in the best interest of either the FC
Switch vendors or even the T11 FC community at large. So mixing them makes
little business sense. In summary, the FCIP authors would like to keep the
FCIP and the iFCP efforts seperate. I beleive that the iFCP folks are of the
same opinion.

Now with my TC hat on, I would like to propose that we proceed to solve this
debate by getting a collective consensus from all folks on merging the two -
protocol or otherwise.

Please reply with a  simple "Agree to merge" or "Disagree to merge"
statement. No long explanations as to why or why not please!

-Murali Rajagopal


----- Original Message -----
From: "Charles Monia" <cmonia@NishanSystems.com>
To: <Black_David@emc.com>; <dotis@sanlight.net>; "Charles Monia"
<cmonia@NishanSystems.com>; <ips@ece.cmu.edu>
Sent: Friday, January 05, 2001 4:54 PM
Subject: RE: iFCP as an IP Storage Work Item


>
>
> > -----Original Message-----
> > From: Black_David@emc.com [mailto:Black_David@emc.com]
> > Sent: Friday, January 05, 2001 4:15 PM
> > To: dotis@sanlight.net; cmonia@nishansystems.com; ips@ece.cmu.edu
> > Subject: RE: iFCP as an IP Storage Work Item
> >
> >
> > Before this goes any further ... the two of you may be
> > in violent agreement.  Charles objected to a "handshake";
> > I don't think this objection would preclude one end of
> > a connection announcing the protocol that it intends to
> > use so that the other end can cleanly and quickly
> > terminate the connection if it can't or won't use
> > that protocol (ideally with an error code to the
> > other end indicating protocol incompatibility, so
> > the misconfiguration becomes obvious).
> > Doug's
> > suggestion of IANA-allocated numbers for identifying
> > protocols for this purpose is reasonable.
> >
> > As to the virtues of being able to speak more than
> > one protocol on a port, Fibre Channel provides examples
> > of where this sort of thing has been added after the
> > initial specifications were done, so I wouldn't dismiss
> > this out of hand.
> >
> > --David
>
> Hi David:
>
> It seems to me that with or without a common encapsulation method, such
> boxes can be built 'now'.  As I said earlier, a common encapsulation
should
> make it easier, which is a good thing.
>
> So, what we're left with is the question of how such a box would shift
> gears.  If an "in-band" method is easier, the simpler the handshake, the
> better. So an approach based on an IANA-assigned parameter seems
reasonable
> to me.
>
> While this is a fruitful discussion, I'd be interested in hearing from the
> FCIP folks on this issue.
>
> Charles
>
> >
> >
> > > -----Original Message-----
> > > From: Douglas Otis [SMTP:dotis@sanlight.net]
> > > Sent: Friday, January 05, 2001 5:59 PM
> > > To: Charles Monia; Ips@Ece. Cmu. Edu
> > > Subject: RE: iFCP as an IP Storage Work Item
> > >
> > > Charles,
> > >
> > > I disagree with this assumption about rigidity of
> > protocols.  Using a
> > > common
> > > initialization field would allow node handling protocols to
> > be confirmed.
> > > Initialization should also include a version number or
> > option field for
> > > the
> > > encapsulation where this version or option be negotiated.
> > If the node
> > > handling protocol, separate from the encapsulation
> > specification, could be
> > > identified, then there would be fewer strange events if someone
> > > mis-configured IP ports.  I am not a fan of using text
> > strings to do this
> > > function and would prefer IANA defined values for rigid
> > structures.  In
> > > addition to indicating an encapsulation version or options
> > designator,
> > > include the node type designator to signify how the node is
> > handled to
> > > avoid
> > > strange failures.
> > >
> > > As a gateway, tunnel or perhaps as an end device in perhaps
> > the distant
> > > future, the type of node protocols may vary to meet
> > different needs.  The
> > > lion's share of the work however could be covered within
> > the encapsulation
> > > specifications and clever means of handling the node could
> > be isolated
> > > from
> > > these details.  It does not mean that in the end all node
> > protocols will
> > > use
> > > identical encapsulation, but only that, as much as
> > possible, encapsulation
> > > is kept common and the effort to encapsulate is seen as a
> > separate task to
> > > that of handling the frame at the end point.  I would hope that a
> > > transport
> > > could be developed that would not care how the node was
> > handled and where
> > > this node handling function is defined within a separate process.
> > >
> > > It seems like a fairly clean separation of encapsulation
> > and node handling
> > > that would help foster support for these markets especially if a few
> > > devices
> > > allow a wide range of possible node handling scenarios.  I
> > agree that IP
> > > fabric is more extensible to that of FC, however even with that
> > > assumption,
> > > the final goal of fully incorporating IP fabric without
> > altering the FCP
> > > structures has not been achieved by either of these current
> > proposals.
> > > With
> > > that said, I would be in favor of developing a universal FC
> > encapsulation
> > > transport as a WG proposal that would support both iFCP and FCIP.
> > >
> > > Doug
> > >
> > > > > Ken Hirata wrote:
> > > > > > Why do you want to standardize a common encapsulation protocol
> > > > > > for FCIP and iFCP if their semantics and behavior are
> > completely
> > > > > > different?  Would you want tunneling protocol
> > implementations to
> > > > > > also augment certain ELSs even though it isn't necessary
> > > > > for tunneling
> > > > > > protocol operation?
> > > > >
> > > > > If I were to build hardware that either assisted or completely
> > > > > processed both iFCP and FCIP, it sure would be easier to do
> > > > > header parsing and other common processing if there was just
> > > > > one format.
> > > > >
> > > > > > If a common encapsulation protocol was defined, I believe a
> > > > > > negotiation protocol would be necessary to distinguish between
> > > > > > usage as a gateway or tunneling protocol.
> > > > >
> > > > > Yes, either negotiation of a flag bit in the encapsulating
> > > > > header used to choose which algorithm to use.
> > > > >
> > > > Hi David and Ken:
> > > >
> > > > I agree that a common encapsulation may make it marginally easier
> > > > to build a
> > > > multi-protocol box as well as having other benefits.
> > However, from the
> > > > above, I'm concerned that some might infer that
> > multi-protocol support
> > > > should be a requirement.  Just to be clear on this point:  While
> > > > I'm all for
> > > > doing things that encourage commonality (where it makes sense
> > > > technically) I
> > > > feel that a standard ought not to needlessly burden a product with
> > > > supporting both architectures.
> > > >
> > > > With regard to 'negotiation', I believe such a handshake is
> > > > unnecessary and
> > > > undesirable.  In a real system, I can't see a scenario
> > where it buys
> > > > anything to make this dynamic.  As I see it, these
> > choices are cast in
> > > > concrete when the SAN is implemented and aren't going to change
> > > > from day to
> > > > day. Also, for hardwired boxes that only support one
> > protocol, it simply
> > > > adds complexity.  If someone wants to build a multi-protocol box,
> > > > I believe
> > > > they'd be better off making this statically settable.
> > > >
> > > > Charles
> > > >
> >
>