RE: iFCP as an IP Storage Work Item

[Charles Monia <cmonia@NishanSystems.com>]

> -----Original Message-----
> From: David Robinson [mailto:David.Robinson@EBay.Sun.COM]
> Sent: Thursday, January 04, 2001 7:28 PM
> To: Ips@Ece. Cmu. Edu
> Subject: Re: iFCP as an IP Storage Work Item
> 
> 
> 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