RE: iFCP as an IP Storage Work Item

[Charles Monia <cmonia@NishanSystems.com>]

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