Mobile IPv4 Dynamic Home Agent (HA) Assignment
draft-ietf-mip4-dynamic-assignment-07

[Note]: '12/1/05:  Holding a discuss while the WG figures out what they want to say about the possibility of loops.  See full discuss text for details.' added by Amy Vezza

[Note]: '12/1/05:  Holding a discuss while the WG figures out what they want to say about the possibility of loops.  See full discuss text for details.' added by Michelle Cotton

IANA Comments:
Upon approval the IANA will assign the following error codes:
NONZERO-HA-REQD (in range 64-127)
REDIRECT-HA-REQ (in range 128-192)
These registrations will take place in the following registry:
http://www.iana.org/assignments/mobileip-numbers
There is also a registration for the Dynamic HA Extension.  IANA needs clarification regarding exactly where this assignment should go.  In section 3.4 it also describes subtypes 1 an 2.  Do these need to be registered?

[Ballot discuss]
Holding a discuss while we determine what to do based on the discussion below.  Not clear yet if the changes will be substantial enough to require a re-review by the IESG or not.

Also waiting for IANA comments.

Hi Ted,

on 2005-11-30 23:25 Ted Hardie said the following:
> As you'll see from the state changes in the tracker, I dropped my
> DISCUSS on this document based on Kent's statement, which I read as
> saying that there was no desire to standardize loop detection.  Seeing
> the thread on this after that point, my take is:
>
> 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.
>
> If this is a fair summary, it seems reasonable that the working group
> take this document back on board to craft those text additions and to
> decide exactly what advice to give.

This seems to me to be an excellent summary.

> I am willing to hold a further DISCUSS on this, but I suspect I am not
> the ideal person to track the changes.  Possibly Margaret is willing
> or can suggest someone?  Or, if preferred, the working group can
> simply do this and then return the document to the IESG (treating this
> as a late last call comment?).

We will have a go at simply proposing text on the WG list, ensuring we have consensus, and return the document to the IESG.

Kent, will you suggest some text for the list?  Meanwhile, I'll extract the discussion comments of this thread to the summary above and send to the list.


Regards,

Henrik

[Note]: '12/1/05:  Holding a discuss while the WG figures out what they want to say about the possibility of loops.  See full discuss text for details.' added by Margaret Wasserman

[Ballot discuss]
Holding a discuss while we determine what to do based on the discussion below.  Not clear yet if the changes will be substantial enough to require a re-review by the IESG or not.

Hi Ted,

on 2005-11-30 23:25 Ted Hardie said the following:
> As you'll see from the state changes in the tracker, I dropped my
> DISCUSS on this document based on Kent's statement, which I read as
> saying that there was no desire to standardize loop detection.  Seeing
> the thread on this after that point, my take is:
>
> 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.
>
> If this is a fair summary, it seems reasonable that the working group
> take this document back on board to craft those text additions and to
> decide exactly what advice to give.

This seems to me to be an excellent summary.

> I am willing to hold a further DISCUSS on this, but I suspect I am not
> the ideal person to track the changes.  Possibly Margaret is willing
> or can suggest someone?  Or, if preferred, the working group can
> simply do this and then return the document to the IESG (treating this
> as a late last call comment?).

We will have a go at simply proposing text on the WG list, ensuring we have consensus, and return the document to the IESG.

Kent, will you suggest some text for the list?  Meanwhile, I'll extract the discussion comments of this thread to the summary above and send to the list.


Regards,

Henrik

[Ballot comment]
From MIB DOctor Mike Heard:
>  o draft-ietf-mip4-dynamic-assignment-06.txt
>    Mobile IPv4 Dynamic Home Agent Assignment (Proposed Standard) - 6 of 22
>    Token: Margaret Wasserman

No real competence to comment on technical content.  As far as I can tell, the
existing MIB modules (RFC 2002) provides no support for this extension (or the
related ones in RFC 2794) but can still be used -- there is just no visibilty
into the workings of dynamic home agent assignment.

[Ballot comment]
Shepherds indicate the statement referenced below will be removed:

(original discuss text)
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.

[Ballot discuss]
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.

[Ballot comment]
Section 3.4: the picture shows the "Length" field having two octets.  The text says "Length is always 4 bytes".  The text and the picture should match.  It would also be better to use "octets" instead of "bytes" to describe an 8-bit data structure.

From: Thomas Narten
To: Pete McCann
cc: "Margaret Wasserman" ,
    "Henrik Levkowetz" , mkulkarn@cisco.com,
    alpesh@cisco.com, kleung@cisco.com
Date: Tue, 04 Jan 2005 15:31:32 -0500
Subject: Re: Request to advance draft-ietf-mip4-dynamic-assignment-03.txt

Hi Pete.

Sorry for being so long on this one. It turns out I did review it back
in October, but then when I went back to my notes, I had so few
comments on the draft (and I couldn't remember the details), I wasn't
sure I had actually reviewed it. :-) But it seems I did (now that I've
reread it), but the document is just in really good shape. My only
question/comments are:

2004-10-11: review of 03 (WG says advance)

There are references in abstract

>    Legacy Foreign Agent:
>   
>    Legacy foreign agents may forward a Registration Request with home
>    agent field set to ALL-ZERO-ONE-ADDR by setting the destination IP
>    address to ALL-ZERO-ONE-ADDR.  This will result packet being dropped
>    or incidentally handled by a next hop HA, adjacent to the FA.   

hmm. how does one distinguish network connectivity problems from "not
implemented"? I.e, what recovery action does a MN take in this
situation?

If the answer to the last one is straightforward (i.e., this is
covered elsewhere in the draft), I'll go ahead and start the LC.

Thomas