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

[Henrik Levkowetz <henrik at levkowetz.com>]

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

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
Mip4 mailing list: Mip4 at ietf.org
    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/