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

["John Hufferd" <hufferd@us.ibm.com>]

Every thing I have seen here, has nothing to do with an issue that is
broken in iSCSI.  I suggest that whomever wants to take it up with T10 do
so, and lets move on.  This is not a issue to be endlessly debated in this
list.

Lets focus on closer of the spec, and items that are really broken.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Robert Grant <Robert.Grant@mcdata.com>@ece.cmu.edu on 04/02/2002 02:41:35
PM

Sent by:    owner-ips@ece.cmu.edu


To:    ips@ece.cmu.edu
cc:
Subject:    RE: iscsi: CRN support not required. [was :Re: [Fwd: iSCSI:
       items       discussed  at WG meeting]]




> -----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