RE: iSCSI: T10 meeting

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

David,

The FCoverIP specification has already defined FC encapsulation.  Should
there be  additional information required to transport an FC frame over IP,
that should become a header prefix rather than a redefinition of structures.
From that point, changes can be determined within a narrower perspective.
The present solution is less than satisfactory in the basic aspect of
control.  Solutions already exist within FC.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Black_David@emc.com
> Sent: Wednesday, September 13, 2000 10:36 PM
> To: ips@ece.cmu.edu
> Subject: iSCSI: T10 meeting
>
>
> I spent today at the T10 meeting, despite United Airlines'
> best attempts to keep me out of the Pacific time zone :-).
> I did quite a bit of explaining about IETF and ips
> logistics, procedures, and status, but did manage
> to squeeze in some technical discussion.
>
> Here are a few items of relevance to iSCSI:
>
> - As indicated earlier, T10 would like to see iSCSI
> (and other encapsulations of SCSI) follow the data
> formats used by FCP to the extent possible and
> reasonable.  Departures for good functional reasons
> are ok (e.g., iSCSI separates out task management
> in a way that FCP does not, and there may be good
> reasons to do that), even though they complicate
> bridges.  OTOH, format differences that lack a
> functional reason should be avoided.  The recent
> proposal by Charles Monia to harmonize iSCSI and
> FCP packet formats deserves serious attention.
>
> - There has been some discussion of stateless bridges
> or gateways on this list in the past.  T10's view of
> this area is that such devices tend to be inherently
> stateful because they usually have to keep state
> related to proxying multiple initiators accessing them
> onto a single initiator that accesses the actual
> target.  Mapping command tags as part of this is not
> a big deal, and hence T10 does not attempt to mandate
> a single SCSI tag format -- in fact a 64 bit tag for
> SCSI over VI was recommended as part of today's meeting.
> The rationale for that tag may be worth considering for
> iSCSI - an initiator running a 64 bit OS can stick a
> memory address in the tag, which makes it easier to
> handle responses.  In any case, it's not important
> to match FCP's tag structure exactly.
>
> - I want to reinforce Steve Byan's earlier email on
> multiple ordered commands and resource exhaustion.
> As indicated by words in our (still draft) charter,
> this sort of issue expressible entirely in SCSI
> w/o reference to TCP or any other transport is in
> T10's domain.  That means that not only is it T10's
> responsibility to deal with this issue, it is also
> T10's responsibility to determine whether the issue
> is serious enough to merit any changes.  This IETF
> WG should be cautious about redesigning things like
> ACA - it would be undesirable for ACA to behave
> differently in iSCSI than in other SCSI transports.
>
> >From my viewpoint, a good working relationship
> with T10 is well underway.
>
> --David
>
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>