Subject: [Mip4] RE: [Fwd: RE: DISCUSS: draft-ietf-mip4-dynamic-assignment-06.txt]

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Wed, 30 Nov 2005 19:28:00 -0800

Here's a suggestion for new text:

  5. If the error code is set to REDIRECT-HA-REQ, MN obtains the HA 
     address from Redirected HA Extension.  The MN then sends a 
     Registration Request to Redirected HA.  The MN may choose to add
Requested HA 
     extension in this new Registration Request.  If a registration loop
occurs, the
     case when the Redirected HA is an HA that had already directed the
MN to
     register elsewhere, then the MN stops sending any further
Registration Request
     and provide an indication that the loop event was detected.  The
number of 
     consecutive Redirected HAs remembered by MN for loop detection is
an 
     implementation parameter.       

Kent 

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Wednesday, November 30, 2005 3:26 PM
> To: Mobile IPv4 Mailing List
> Cc: Alpesh Patel (alpesh); Henrik Levkowetz; Kent Leung 
> (kleung); Pete McCann; Milind Kulkarni (mkulkarn); Ted Hardie
> Subject: [Fwd: RE: DISCUSS: draft-ietf-mip4-dynamic-assignment-06.txt]
> 
> Hi,
> 
>   We have received a DISCUSS comment from the IESG related to 
> the dynamic HA assignment draft, 
> draft-ietf-mip4-dynamic-assignment-06.txt.
> 
> During the responses from the authors and the WG chairs to 
> the comment and question from Ted Hardie, it became clear 
> that some corrections and / or clarifications of the draft 
> text is needed.
> 
> Text will be proposed to the list to handle this.  Meanwhile, 
> here is the comments leading up to this understanding.
> 
> Below I first quote Ted's summary of the discussion, and then 
> an excerpt of the thread of messages resulting from Ted's 
> initial DISCUSS comment, in chronological order from first to last:
> 
> 
> On Wed, 30 Nov 2005 14:25:21 -0800, Ted Hardie wrote:
> 
> [snip]
> 
> > 1) There is a risk of misconfiguration creating a loop if there are 
> > multiple redirects.
> > 
> > 2) Given this design, the appropriate entity to detect that loop is 
> > the client.
> > 
> > 3) If detected, a client will not be able to affect the loop, but 
> > would be able to conserve resources (network and battery, 
> primarily) 
> > by ceasing to traverse it. If there is an operator, the 
> client would 
> > also be able to inform the operator that out-of-band 
> resolution of the 
> > problem is needed.
> > 
> > 4) At least some folks believe it would be valuable to add 
> language to 
> > the text describing the loop possibility and client's role in 
> > detection, This might be augmented by advice on how many HA 
> > redirections the client should be able to track in order to 
> detect a loop.
> 
> 
> 
> This is an excerpt of the thread leading up to this:
> 
> [Ted]
> > In section 4.2, bullet 5, the document says:
> > 
> >      If the error code is set to REDIRECT-HA-REQ, MN obtains the HA 
> >      address from Redirected HA Extension.  The MN then sends a 
> >      Registration Request to Redirected HA, unless it has already 
> >      received a redirection response from this HA while 
> processing this 
> >      Registration Request.  The MN may choose to add Requested HA 
> >      extension in this new Registration Request. 
> > 
> > I'm not sure if the statement "unless it has already received a 
> > redirection response from this HA while processing this 
> Registration 
> > Request" is meant to be a form of loop detection.  If it is, this 
> > seems like something that needs to be called out more 
> explicitly; if 
> > it is not, then some clarifying text on what this means may 
> be needed.
> 
> [Kent]
> > Hi Ted.  We couldn't figure out the intent of the 
> identified statement.
> > Looks like it may be some residual of some previous 
> versions.  There 
> > is no loop condition since the HA receiving the request 
> always respond 
> > to the MN, which needs to send request to new HA when Redirected HA 
> > Extension is in the response.
> > 
> > We will take out the "unless..." part of the sentence unless anyone 
> > objects.  Thanks.
> > 
> 
> [Henrik]
> > Umm...  How is this case to be handled, then:
> > 
> > MN sends a request to HA1 as requested HA.  HA1 rejects 
> registration, 
> > but supplies HA2 as redirected HA.  MN then sends a request to HA2, 
> > but
> > HA2 also rejects, with HA3 as redirected HA.  MN continues 
> to HA3, but
> > HA3 unfortunately sends a reject with HA1 (!) as redirected HA...
> > 
> > A misconfiguration of the HAs, sure, and how they choose the 
> > redirected HA is outside the scope of the specification, but how 
> > should the MN handle this?
> > 
> > If the MN started out with a plain ZERO addr, and HA1 was 
> assigned by 
> > an FA, the MN will not be able to detect the loop until it gets HA2 
> > back from HA1 the second time, but at that point it should 
> again react.
> > 
> > I agree with Ted, this would benefit from better description; 
> > including how many HAs is an MN required to remember, for 
> loop detection purposes?
> > I'd say 3 is too few, and 101 too many.  Pick a favourite 
> prime number?
> > (No, there's no special reason why I say prime ,;-)
> 
> 
> [Kent]
> > Hi Henrik.  If there is a logic error in the dynamic HA assignment 
> > algorithm/methodology, what can MN do to recover?  In your example, 
> > should MN stop registration if it detects this type of 
> loop?  And then 
> > how does MN recover without user intervention?
> > 
> > My thought is that MN follows the instructions of the network (i.e. 
> > HA) and sends registration request to the redirected HA 
> obediently.  
> > If there is some misconfiguration/assignment error that 
> ping pongs the 
> > MN between 2 or more HAs, then MN will never be able to register 
> > successfully.  Which is the same result as if MN stopped 
> registration 
> > after detection.  However, if a service call is made to the mobile 
> > operator support, then the network can fix the 
> misconfiguration/error 
> > and the MN would automatically recover with the next registration 
> > request.
> > 
> 
> 
> [Henrik]
> > I assume that on a received redirect, the MN tries the next 
> HA without 
> > delay.  If you just let the MN cycle, it will be sending 
> continuously, 
> > and if this is e.g. a cell-phone, it will swiftly run down its 
> > batteries.
> >
> > It makes more sense to me to break the loop, wait for a while (X 
> > seconds or minutes) and try again from the very beginning.
> >  This has the added advantage of presenting the service technician 
> > with a complete set of events, rather than him being able 
> to observe 
> > only the looping.
> 
> 
> [Pete]
> > As I recall, we decided on an end-to-end version of dynamic 
> assignment 
> > (where the MN is responsible for re-sending the RRQ) mainly so that 
> > things like loop detection could be performed in the MN.  I 
> personally 
> > think that if the MN detects such a loop it should give up 
> and report 
> > the error to the user as a way to prevent further wasting of air 
> > interface resources.
> > 
> 
> 
> [Alpesh]
> >Henrik:
> >
> >I hear your argument. I think picking a number like 8 or 10 and then 
> >Giving up (asking for operator intervention) may be good.
> >
> >Why 8 or 10 - this is too high anyway - this many round trips and 
> >redirections will frustrate the user (delay).
> >
> >I am fine with anything between 5-7 too.  Note that this now 
> puts The 
> >onus on the client to detect loops or bailing out when the number Of 
> >redirection attempts exceed.
> 
> 
> 
> 				--30--
> 
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/