RE: iSCSI CONNECT message

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

John,

As in the past, if you had any difficulty with understanding a point, I was
happy to explain privately.  We have done this before with a resounding
conclusion you wish to promote large controllers.  Again, I do not think a
SCSI transport is limited exclusively to large controllers at the end of a
network.  You do not comprehend or acknowledge this point.  Cache memory
within a controller is wasted if placed as the end point of a MAN or WAN
network and will remain at a serious competitive disadvantage.

No matter how complex this storage controller is made together with its
levels of authentication and naming done in-line with the transport
function, do not loose perspective of a simpler scheme which will work
sufficiently well if not better due to removal of these latency causing
processes.  I would not expect you to view this matter beyond a perspective
of a modified SCSI controller turned into a type of file server with the
ability to tunnel and dynamically map.  As such, I would not expect you to
comprehend my comments.  My efforts to date have been promoting existing
standards and attempting to dissuade re-invention.  I would hope that a
simple bootstrapping can be achieved that remains compliant to both views of
simple and complex and take in practical considerations of mounting drives.

This reflector should be a place to express concerns in a technical manner.
The synergy of efforts will be limited if these concerns are not shared and
understood.  If you simply do not wish to be bothered, filter email.  If you
do not wish to expend effort in supporting your perspective, that too is
your option.  I do not view the iSCSI draft as the only means, and in that
light, I do not think I have taking liberties in pointing to concerns.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> John Hufferd/San Jose/IBM
> Sent: Monday, October 09, 2000 12:05 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI CONNECT message
>
>
>
> Douglan Otis,
> I have no idea what point you are trying to make, I don't even know if I
> disagree with what you intend to say.  I know there is no such thing as a
> SCSI address space.  I know that we need a boot process, that needs to
> depend on establishing a connection to the target Storage Controller, and
> in the iSCSI space this means using the normal IP connection processes.
> Some of those include DHCP, and DNS etc.  So I do not even know what you
> are arguing against.
>
> Many folks are saying that we need additional techniques to get through
> (to) various type of "private" networks, and they are suggesting
> ways to do
> this (such as the "Target:" string on the Login or a separate "Connect"
> iSCSI command).
>
> However, given the above, I do not even know what you are arguing for or
> against.
>
> Perhaps, if you want to discuss this further off the reflector, we can
> reach an understanding.  I hate to keep punishing every else with these
> notes.
>
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403
> Internet address: hufferd@us.ibm.com
>
>
> "Douglas Otis" <dotis@sanlight.net> on 10/09/2000 11:42:22 AM
>
> To:   John Hufferd/San Jose/IBM@IBMUS, <ips@ece.cmu.edu>
> cc:
> Subject:  RE: iSCSI CONNECT message
>
>
>
> John,
>
> You are still stuck with the chicken and the egg problem.  Unless this
> login
> process can expose extensive amounts of information with
> selectors to allow
> a user to prune this information, you are left with a scheme that will not
> scale.  Stop designing a database server within the SCSI transport.  It is
> counter intuitive to use transport to inform the system as how to use
> transport.  Bootstrapping must still be defined.  Should there be a tunnel
> that needs to be navigated, leave that operation to the gateway already on
> the network.  The transport should not need to define every aspect of a
> path
> taken between point two points.  Let gateways and routers make those
> decisions.
>
> There have been years of work at allowing this level of separation between
> a
> connection and routing.  Do not mix routing with what should be a simple
> transport.  Keep SCSI addressing free of embedded IPs.  If there is an IP
> domain that must be transversed beyond the portal, it should be configured
> outside the transport.  It is a mistake to try to mix SCSI address space
> with IP address space.  A SCSI target is not a IP:Port combination.  Once
> within a SCSI domain, only SCSI targets using the real addressing such as
> S_ID or D_ID with a link should be used.  To introduce two levels of
> addressing makes it impossible to provide security.  Each domain
> would have
> a different translation to the eventual target.  Allowing such levels of
> proxy will never scale due to an inability to authenticate or to provide
> meaningful restrictions prior to access.
>
> Doug
>
>
>
>
>
>