RE: iFCP as an IP Storage Work Item

[Black_David@emc.com]

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
 

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