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

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

> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Tuesday, April 02, 2002 3:26 PM
> To: Robert.Grant@mcdata.com
> Cc: ips@ece.cmu.edu
> Subject: RE: iscsi: CRN support not required. [was :Re: [Fwd: iSCSI:
> items discussed at WG meeting]]
> 
> 
> Excerpt of message (sent 2 April 2002) by Robert Grant:
> > ...
> > 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.
> 
> For something to be "end to end" it has to be transport-independent.
> Conversely, if something is transport-dependent, it cannot possibly be
> end to end when you have mixed transports and bridges.
> 
> It seems to me the problem is that CRN is clearly defined as transport
> dependent, 

We agree here - this is the problem. I view the definition as wrong (I don't
see much relevance of CRN to FC as a transport, only in the mapping of SCSI
onto FC).

> but in spite of that people are trying to assign end to end
> semantics to it across transport converting bridges.  This is an
> effort akin to squaring the circle.  

Or ... to righting a wrong.

> 
> I don't see that hypothetical iSCSI modepages have anything to offer
> to solve this problem.  Until and unless T10 decides to make CRN a
> transport INdependent thing with consistenly defined semantics across
> all transports, it is inescapable that bridges have to get directly
> involved -- and CRN will not be end to end.

If T10 were to make CRN transport INdependent that worked across all
transports (FC as well as iSCSI), that'd be great. In the mean time, we
could choose to have "consistently defined semantics across" at least FC and
iSCSI (through iSCSI mode pages). We could choose not to, of course, and
leave it to the bridges. It is a choice, though - it's not an inescapable
truth. 

Santosh's suggestion is even more ambitious - that the whole mode page thing
should be re-looked at. I don't know whether this is a good idea or not -
but I hope that devices that are trying to bridge transports (a tough enough
thing to begin with) aren't also going to be saddled with trying to right a
whole lot of wrongs that occurred in the upper layers as well.

> 
> 	 paul
> 
> 


Regards,
Rob