RE: iscsi: CRN support not required. [was :Re: [Fwd: iSCSI: items discussed at WG meeting]]

[Robert Grant <Robert.Grant@mcdata.com>]

Whether modepages are an addition or not depends on your perspective. If you
view the "network" as beginning and ending with IP, then modepages are an
addition. I believe this is the view that led to the previous consensus
around iSCSI supporting CRN but not needing to have modepages to communicate
that.

If you view the "network" (or perhaps the "fabric"?) as an interconnection
of end nodes (or initiators and targets) - and that those endnodes may be
FCP or FCP-2 devices - then modepages are already there in some endnodes.
This is a stretch hypothesis and falls down in some places (I see no reason
for iSCSI initiators to deal with truly transport-specific parts of the
transport-specific mode pages like the loop parameters of FCP-2). But I
believe the hypothesis has merit in some of the "end-to-end" and
"heterogeneous" networking philosophies (OK - so I just read RFC1958 and am
a bit of a kid with a new toy). It also has commercial merit since
connecting iSCSI to FC devices seems a market of interest to at least a few.
To make this iSCSI/FC environment work best, it will need the participation
of ALL players - there may be times when issues arising in this environment
are best addressed in something other than the bridge. So - does the WG
accept that making iSCSI work well with FC is part of iSCSI and not just
iSCSI/FC bridges? (Not iSCSI alone, of course - FC and SCSI have roles to
play, too). Before you answer - I suggest that believing that making the
fabric work well is solely the responsibility of fabric devices led to some
of the shortcomings in FC fabrics (i.e. the reliance on the SCSI layer for
end-to-end flow control in FC does make things hard sometimes). 

If you accept that making FC and iSCSI work well is not just the work of the
fabric devices (dare I call them "boxes in the middle"?) then where is the
best place to deal with the CRN mode pages? Does having the bridge deal with
this make sense? It strikes me that CRN is a function between the initiator
and target and as such is best left (as near as can be obtained) as
negotiated between the two. So Dave's suggestion of iSCSI mode pages makes
the most sense to me.

Also - and this is as much a question as a statement because I honestly
don't know - but are there other aspects of mode pages where having iSCSI
mode pages is the best answer? For example, will the use of confirmed
completions never make sense in an iSCSI environment? If there's ever a use
for confirmed completions, then the setting of the equivalent to REC_TOV in
an iSCSI mode page might make sense, too. So Dave's suggestion of adding a
mode page can also be viewed as a more general solution than just addressing
CRN.

Regards,
Rob
 
Rob Grant
McDATA Corporation


> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Monday, April 01, 2002 2:15 PM
> To: dap@cisco.com
> Cc: ips@ece.cmu.edu
> Subject: RE: iscsi: CRN support not required. [was :Re: [Fwd: iSCSI:
> items discussed at WG meeting]]
> 
> 
> I find it interesting that SAM-2 mentions CRN but doesn't seem to give
> it any semantics, leaving it to one particular transport to choose
> semantics that it likes.
> 
> If the semantics are transport-specific, then cross-transport bridges
> will have to be prepared to do appropriate work to handle what each
> side expects.
> 
> From what I can see, minimally iSCSI could omit the CRN entirely,
> since it is not necessary in iSCSI.  It currently carries it without
> specifying any use for it.  (I believe this is the point that Santosh
> made.)  Perhaps the intent was for it to be carried to iSCSI/FC
> bridges so those bridges can just pass it on, rather than having to
> make one up locally?  If so, that seems innocuous, but would be worth
> stating explicitly.
> 
> I'm puzzled about what else iSCSI could do.  We could invent semantics
> for this currently-unneeded thing, but to what purpose?  As for
> protocol specific LUN modepages, I thought that iSCSI doesn't have any
> protocol specific modepages.  It seems a stretch to add a whole new
> mechanism (modepages) to iSCSI solely in order to say something about
> a field that iSCSI isn't even using.
> 
>     paul
>