RE: [Mip4] Updated draft for Mobile IPv4 NAI-basedHome AddressAssignment...

["Tsirtsis, George" <tsirtsis at qualcomm.com>]

Hi Naveen, comments inline....look for "GT>"

-----Original Message-----
From: Naveen Paulkandasamy [mailto:naveenpk at cisco.com] 
Sent: Monday, March 13, 2006 8:56 PM
To: Tsirtsis, George
Cc: Kent Leung; mip4 at ietf.org
Subject: Re: [Mip4] Updated draft for Mobile IPv4 NAI-basedHome
AddressAssignment...

Hi George,

appreciate your comments on the draft!

please see inline at [NAV]...

Tsirtsis, George wrote:

>Hi Naveen/Kent, 
>
>This is a good and well overdue draft...we have been dancing around
>these issues in the field for long time and it will be good to have at
>last some clarity.
>
>In section 7.1.2 you require that the MN includes the Dynamic-HoA
>extension in all re-registrations. Why is that? This makes it hard for
>the HA to differentiate between the MN requesting address allocation
>with a preferred address from the case where the MN has already been
>allocated an address.
>
>
>For example consider Case 2 of Section 6.1:
>
>"    Scenario    : HA reboots after a MN successfully registered and 
>                  then receives a re-registration from the MN and the 
>                  HA is unable to assign the RRQ(HoA) to the MN.."
>
>In this case you say:
>
>"    HA Behavior : The HA MUST try to assign an alternative address and

>                  if successful, it MUST create a new binding entry and

>                  MUST return a RRP with HoA containing the alternative

>                  address. If the HA is unable to assign an alternative

>                  address, it MUST return a RRP with the code 
>                  ADDR_ALLOC_FAILED and RRP(HoA) set to 0.0.0.0.   "
>
>Changing the address of the MN when the MN has not explicitly requested
>such action sounds like a bad idea to me.  
>
>Have you considered immediately returning a RRP with a different error
>code, say something like "ADDR_UNAVAILABLE", instead of attempting to
>reallocate an address? If the HA indicates what happened, the MN is
then
>free to do as it sees fit, including going through another registration
>in which it includes the Dynamic-HoA extension leading to the desired
>result. 
>
>  
>
[NAV] the idea behind including the Dynamic-HoA extension in all 
re-registrations is
 as follows. basically in the HA reboot case, there are two possible 
actions that the MN can take,
when the HA informs the MN that it cannot support the MN's old HoA
anymore:

(i) the MN can request a new HoA from the HA using Dynamic-HoA as per 
this draft.
(ii) the MN can resort to some other means and prefers not to get its 
HoA from the HA immediately ?

we felt that, case (i) might be more common than (ii) and so, we 
preferred to optimize case (i)


GT> It is not always a good or necessary to optimize error cases
especially if it obfuscates what happened. The MN may have other choices
e.g, it may have other HAs it can use or who knows what else. We should
not assume we are aware of all possible scenarios here. The e2e
principle says that you do not take decisions on behalf of the end node.
Tell the end node what happened and it will figure it out. This is
always a more robust solution.


to avoid the extra RRQ round trip by just letting the HA allocate the 
address if the old HoA
is not available. and in the case where the MN received a new HoA but 
wants to follow case (ii),
it can deregister the new HoA with an additional deregistration, which 
we felt was okay, if this
does not happen to be in the majority of the cases.

so, we think, it would be helpful to know more opinions from you and the

group on
- what are the possible other actions that the MN can resort to, in the 
case (ii) scenario ? and,
-  which scenario (case (i) or (ii)) would be the most common scenario 
so that we can optimize
or default to it?

also, if there is a consensus that, we want the MN to choose  the HA 
behavior and make
case (ii) as the default , then we can  change the MN behavior  to :

(i) can include the Dynamic-HoA extn in the RRQ, if it wants it address 
reassigned whenever
 the HA cannot support the MN's old HoA.

(ii) can exclude the Dynamic-HoA extn in the RRQ and follow the default 
RFC 3344 behavior,
if it wants the HA  to reject the  RRQ with a error code (as per rfc 
3344 for downward
compatibility since the HA would not know if the MN is compliant with 
this draft, if it
has lost its previous binding ?) and the MN can then send a RRQ again
with
Dynamic-HoA if  needed ?


GT> Yes, this is better than my suggestion of a new code for backward
compatibility reason.

please let us know what you think...

thanks,
naveen.

>Thoughts?
>
>George
>
>-----Original Message-----
>From: Naveen Paulkandasamy [mailto:naveenpk at cisco.com] 
>Sent: Wednesday, March 08, 2006 5:14 PM
>To: mip4 at ietf.org
>Cc: Kent Leung
>Subject: [Mip4] Updated draft for Mobile IPv4 NAI-based Home
>AddressAssignment...
>
>Hi All,
>
>we have submitted the updated draft for Mobile IPv4 NAI-based Home 
>Address Assignment
>based on the comments received for the last version... please let us 
>know your comments...
>
>http://www.ietf.org/internet-drafts/draft-paulkandasamy-mobileip-nai-ba
s
>ed-home-addres-01.txt
>
>Abstract 
>  
>    With the introduction of NAIs for identifying Mobile Nodes, RFC 
>    2794 also enabled the Home Agents to be able to assign IP addresses

>    to Mobile Nodes during their initial registration. Though the 
>    concept of NAI-based home address assignment is referenced in both 
>    RFC 2794 and RFC 3344, a comprehensive procedure for achieving such

>    a NAI-based home address assignment has not been outlined. More 
>    particularly, the Home Agent and Mobile Node behaviors including 
>    the error recovery mechanisms for various scenarios related to NAI-
>    based home address assignment have not yet been specified. This 
>    document specifies a procedure that the Mobile IP entities should 
>    follow in order to facilitate NAI-based home address assignment 
>    under various circumstances. 
>
>thanks,
>naveen.
>
>  
>

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

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