RE: Agree or Disagree to Merge FCIP and iFCP

[Charles Monia <cmonia@NishanSystems.com>]

Hi Murali:

Thanks for bringing this matter to a head.

Here's my .02:

1. Merging the iFCP and FCIP specifications --  No, not feasible on
technical grounds.    Anyhow, I think this is one decision that can't be
made by fiat.

2. Definition of a common encapsulation protocol --  Technically possible,
practically not feasible. From my perspective, it's risky and difficult to
manage as the client specs evolve over time.  Besides, I assume the FCIP
encapsulation is a done deal. Bottom line: I vote no (but would grudgingly
try to accommodate the WG consensus on this matter).

Charles
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385


> -----Original Message-----
> From: Murali Rajagopal [mailto:muralir@lightsand.com]
> Sent: Saturday, January 06, 2001 11:26 AM
> 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
> > > > >
> > >
> >
>