RE: iFCP as an IP Storage Work Item

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

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
>