Message-ID: <3F170F14.90503@intransa.com>
Date: Thu, 17 Jul 2003 14:03:16 -0700
From: Bob Gilligan <gilligan@intransa.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: Caitlin Bestler <cait@asomi.com>
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: Login Redirect
References: <r02000000-1026-0375BA08B7BE11D7838C003065D48EE0@[192.168.0.2]>
Content-Type: multipart/alternative;
 boundary="------------000601070101090607070806"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk


--------------000601070101090607070806
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Caitlin Bestler wrote:

>On Wednesday, July 16, 2003, hufferd@us.ibm.com wrote:
>
>  
>
>>Extending my own note... I also believe it would be wrong to
>>set a minimum number of guaranteed redirects.  This is because,
>>I expect several system vendors to use iSCSI as a DAS
>>technology as well as SAN technology. (Similar to the way a
>>number of vendors "Racked" their FC external Raid controllers
>>together with the server as a Direct Connection.)  When used in
>>this manner the customer does not even need to think about the
>>system being on a SAN.  Yet the Storage/System Vendor could use
>>the very same Raid controller, which they use in a SAN, as a
>>direct attachment to the Server in a RACK.  In this environment
>>if any redirect occur, it might be considered a error.
>>
>>So in the above DAS environment having a minimum is, IMHO, not 
>>approprate.
>>
>>    
>>
>Very good point. Any minimum needs to be expressed relative to
>a deployment profile, and definitely be no stronger than a SHOULD.
>Some guidance on what a *typical* initiator deployed in a general
>environment should support would still be a good idea to state.
>  
>
I think that the iSCSI spec as it is written now implies that an 
initiator, by default, MUST accept at least one redirect since 
redirection is a MUST feature.  Of course, to support the "iSCSI as DAS" 
application, an initiator may well want to provide the option to allow 
the administrator to configure it so as to fail *any* redirect attempts.

To support the "fault tolerant iSCSI" application that we describe in 
our I-D (draft-gilligan-iscsi-fault-tolerance-00.txt), an initiator 
definitely would need to support more than one (the 100 redirect limit 
that Windriver implements sounds like more than enough).  We cast our 
I-D as "implementation guidelines" because we recognized that, due to 
the wide variety of applications that iSCSI will be deployed in, the 
behaviors we recommend for this particular application might not be 
universally applicable.  So you could view this document as a 
"deployment profile."  We can add a discussion of the need to support 
multiple redirects to our document.

Bob.


--------------000601070101090607070806
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
<br>
<br>
Caitlin Bestler wrote:<br>
<blockquote type="cite"
 cite="midr02000000-1026-0375BA08B7BE11D7838C003065D48EE0@%5B192.168.0.2%5D">
  <pre wrap="">On Wednesday, July 16, 2003, <a class="moz-txt-link-abbreviated" href="mailto:hufferd@us.ibm.com">hufferd@us.ibm.com</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Extending my own note... I also believe it would be wrong to
set a minimum number of guaranteed redirects.  This is because,
I expect several system vendors to use iSCSI as a DAS
technology as well as SAN technology. (Similar to the way a
number of vendors "Racked" their FC external Raid controllers
together with the server as a Direct Connection.)  When used in
this manner the customer does not even need to think about the
system being on a SAN.  Yet the Storage/System Vendor could use
the very same Raid controller, which they use in a SAN, as a
direct attachment to the Server in a RACK.  In this environment
if any redirect occur, it might be considered a error.

So in the above DAS environment having a minimum is, IMHO, not 
approprate.

    </pre>
  </blockquote>
  <pre wrap=""><!---->Very good point. Any minimum needs to be expressed relative to
a deployment profile, and definitely be no stronger than a SHOULD.
Some guidance on what a *typical* initiator deployed in a general
environment should support would still be a good idea to state.
  </pre>
</blockquote>
I think that the iSCSI spec as it is written now implies that an initiator,
by default, MUST accept at least one redirect since redirection is a MUST
feature. &nbsp;Of course, to support the "iSCSI as DAS" application, an initiator
may well want to provide the option to allow the administrator to configure
it so as to fail *any* redirect attempts.<br>
<br>
To support the "fault tolerant iSCSI" application that we describe in our
I-D (draft-gilligan-iscsi-fault-tolerance-00.txt), an initiator definitely
would need to support more than one (the 100 redirect limit that Windriver
implements sounds like more than enough). &nbsp;We cast our I-D as "implementation
guidelines" because we recognized that, due to the wide variety of applications
that iSCSI will be deployed in, the behaviors we recommend for this particular
application might not be universally applicable. &nbsp;So you could view this
document as a "deployment profile."&nbsp; We can add a discussion of the need
to support multiple redirects to our document.<br>
<br>
Bob.<br>
<br>
</body>
</html>

--------------000601070101090607070806--