Message-ID: <3F149165.70900@intransa.com>
Date: Tue, 15 Jul 2003 16:42:29 -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: "Mallikarjun C." <cbm@rose.hp.com>
Cc: ips@ece.cmu.edu
Subject: Re: iSCSI: Login Redirect
References: <DDE1793D7266AD488BB4F5E8D38EACB801CA89C1@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <013e01c34af4$807f5510$1eeda051@rose.hp.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

Hi - If you are using redirect to implement fault tolerance/load 
balancing as we sketched out in 
draft-gilligan-iscsi-fault-tolerance-00.txt, there may be transients 
when an initiator gets  redirected multiple times.  For example, say A 
redirects the initiator to B.  But say B has more recent information 
about the actual location of the target, so it redirects the initiator 
to C.  Eventually A learns the same information as B and then redirects 
initiators directly to C.  So the initiator should be prepared to accept 
some number of consecutive redirects.

Of course, if the redirection goes on indefinitely or loops - say A 
redirects to B, which redirects to C, which redirects to A, etc. - that 
probably does represent either a configuration error or a bug.  So the 
initiator may wish to detect a redirection loop or an excessive number 
of  redirections.

But, as you point out, what represents "excessive redirection" is in the 
eye of the initiator.  So, I don't think that the main iSCSI spec needs 
to call out a specific hard limit.

Bob.


Mallikarjun C. wrote:

>If this mis-direction is going on to different portals within
>the same target node, I would think that it implies a serious
>configuration issue within the target node because it either
>does not have a global node-level view of the iSCSI service
>it offers, or the situation is changing too rapidly to be correct.
>
>If on the other hand, this mis-direction is forcing an 
>initiator to shuttle to different target nodes, it usually implies a
>lack of a consistent SAN-level view among the target nodes
>that are supposed to be doing cooperative redirection (which
>is what the feature was meant for).
>
>In either case, I tend to think that the issue is one of implementation/
>configuration and placing hard limits on the # of redirections in
>the spec is neither reasonable nor enforceable.   I believe that the 
>spec doesn't preclude implementations from having a limit (for ex., the 
>initiator iSCSI may decide to give up the chase after X attempts and 
>report a failure to its ULP).
>--
>Mallikarjun
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions
>Hewlett-Packard MS 5668 
>Roseville CA 95747
>cbm@rose.hp.com
>
>----- Original Message ----- 
>From: "Lakshmi Ramasubramanian" <nramas@windows.microsoft.com>
>To: <ips@ece.cmu.edu>
>Sent: Tuesday, July 15, 2003 8:51 AM
>Subject: iSCSI: Login Redirect
>
>
>When a target is moved (Temporary or Permanent), target
>sends an appropriate status code and gives the new target
>address. Is there a limit on the number of times a target
>can redirect login? If not, should we have one?
> 
>    Initiator logs into Portal A. 
>    Target redirects to Portal B.
>    Initiator logs into Portal B. 
>    Target now redirects to Portal C.
>    And so on...
> 
>Should we have an upper limit on the number of times a target
>can redirect the login?
> 
>thanks!
> -lakshmi
>
>
>  
>