RE: Agree or Disagree to Merge FCIP and iFCP Encapsulation

["Douglas Otis" <dotis@sanlight.net>]

Henry,

A question can greatly influence an answer.  There should not be a concern
about protecting iSCSI with respect to iFCP.  Julian was the first to
suggest efforts to merge aspects of iFCP and FCIP.  I would not expect these
efforts however will merge into a single document and so a question of
merger should look at a larger picture.  In general, you will find a more
stable environment if specifications isolate independent functions combined
by higher uses.

I can agree with your comment that FCIP and iFCP not merge without agreeing
this lack of merger should also influence a decision to merge encapsulation.
Such consideration will improve the likelihood of common support ASICs as
well as leveraging common practices.  This transforms both proposals into a
simple encapsulation transport combined with various frame handling
conventions.  Keeping node handling aspects separate from encapsulation also
allows encapsulation specifications to stabilize sooner and yet allow
changes with respect to the way frames are handled at the end nodes.

You have not answered a meaningful question.

Merge FCIP with iFCP, NO.

Merge FCIP and iFCP encapsulation, YES.

(I would also hope for a bit more justification that a simple yes or no.)

Doug



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