RE: Request to exclude FC over IP from storage over IP working group charter

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

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> somesh_gupta@hp.com
> Sent: Thursday, August 10, 2000 6:28 PM
> To: somesh_gupta@hp.com; sob@harvard.edu
> Cc: ips@ece.cmu.edu
> Subject: RE: Request to exclude FC over IP from storage over IP working
> group charter
>
>
> Why would they do that and not just do a native implementation?
> This would require them to pay the price of two seperate protocols,
> and the bridging between them to get one (and having to deal with
> all loop issues etc).

Encapsulation would be a translation which then becomes native to the
device.  At least you would have a defined environment where their code
already habitats.

> Also what you are mentioning is still a bridge (in a seperate
> device or in a chip in the drive). The Lucent proposal was
> for a tunnel.

A tunnel over IP however.  It is nothing more than a protocol.

> Storage over IP should not be looked as a bridge between TCP/IP
> and FC or parallel SCSI domains. It is a native transport for SCSI
> commands. There will exist bridges (externel or for some reason
> embedded) to bridge these 3 different transport protocols.

There should be a move in that direction, but unless this interface moves to
the device, removing state information from the middle, as not done for
iSCSI, is the proper means for creating this gateway which is really the
intent of iSCSI.  I see only disaster trying to extricate error situations
where there are three or more locations of state information along the path
that do not agree.  How to signal a problem with combined sessions by means
of a LUN field for multiple drives?  Generate gateway state information and
error handling?  Stateless encapsulation is the proper approach for
combining transports as iSCSI intends and so FC over IP is a superior
solution.

Doug