Subject: Re: [Mip4] AD review of draft-ietf-mip4-dynamic-assignment-03.txt

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 06 Feb 2005 02:45:36 +0100

Hi,

We still do not have a resolution text in response to the following
comment by Thomas.  After a discussion of this between Thomas, Pete
and myself, I promised to write up one particular suggestion for a
resolution of this.  Please read below, and comment. 

On 2005-01-12 5:52 pm Pete McCann said the following:
> Hello,
> 
> Thomas Narten has agreed to start IETF last call for
> draft-ietf-mip4-dynamic-assignment-03.txt.  However, he did have one
> substantive comment during his review that we should discuss on the
> list.
> 
> Here is his review:
> 
>> 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
> 
> So the question is, do we need to add some text to the draft to cover
> this backwards-compatibility question?  If so, what should it say?

The proposal is this: Rather than forcing the MN in this particular case
to wait for possibly several re-sends and time-outs, and then fall back
to base Mobile-IP behaviour, we define an alternative method for the MN
to send the same signal as it would otherwise signal by setting the home
agent field to ALL-ZERO-ONE-ADDR; and do this in such a manner that the
alternative signalling will be passed through a legacy FA back to the
requested HA.

When we set the home agent field to ALL-ZERO-ONE-ADDR, we are in effect
using the address field as a flag.  One alternative way of signalling the
same thing is to place this flag in an extension instead of as a special
value of the home agent field.  Doing the signalling in an extension, as
opposed to doing it in the special value of the home agent field, has the
property that it will be able to pass through legacy foreign agents where
registration requests with the ha field set to ALL-ZERO-ONE-ADDR will not.

Compared to falling back to base Mobile-IP as an alternative, this will
let the MN signal to a compliant HA that it indeed desires dynamic HA
assignment; and as there is no penalty in the form of loss of functionality,
the MN may fall back to this signalling after a very brief delay.  The
reasons not to use the alternative signalling in the first place would be
to permit interworking with existing FAs which only understand the 
ALL-ZERO-ONE-ADDR signalling.

As for the exact form of signalling this with an extension, I can see 3
possible options - I'm not sure which one would be optimal of these:

    1)  Re-define the presence of a Requested HA extension as a flag
	which indicates the request for a dynamically assigned HA,
	also when the HA field is not set to the ALL-ZERO-ONE-ADDR.
	If the MN does not wish to request a particular HA, fill the
	address field in this extension with all zeroes.

    2)	Define a new sub-type of the Dynamic HA Extension as a flag
	extension, so that the significance of this new subtype is
	exactly the same as having the ALL-ZERO-ONE-ADDR in the HA field.

    3)	Specify that a Requested HA Extension with the address field set
	to ALL-ZERO-ONE-ADDR is equivalent to setting the HA field to
	ALL-ZERO-ONE-ADDR.  This means that if the MN wants to request one
	particular HA, it could send 2 Requested HA Extensions; one with
	ALL-ZERO-ONE-ADDR, and one with the Requested HA address.

Personally, I find alternative 1) the nicest, but I don't know if that
comes into conflict with already deployed implementations.

The fallback strategy for MNs requesting FA registration, which operate
in part in networks which require the ALL-ZERO-ONE-ADDR would then be to
first send a registration request with ALL-ZERO-ONE-ADDR in the HA field,
and then after a short time (enough for the FA to have responded, but not
necessarily for the HA to have responded) to send a registration request
with the HA field set to the requested HA address, but still containing
the extension which signals a request for dynamic address assignment.

HAs and FAs which comply with the current document should handle both of
these in the same manner; HAs and FAs which only understand the 
ALL-ZERO-ONE-ADDR will handle the first request dynamically and the second
request as a base Mobile-IP request, and legacy FAs will drop the first
request or forward it to ALL-ZERO-ONE-ADDR, which will result in it being
dropped, but handle the second as a base Mobile-IP request.

MNs which do not expect to operate in networks using the ALL-ZERO-ONE-ADDR
may choose to only use the extension to signal a request for dynamic
address allocation, rather than first sending a request with 
ALL-ZERO-ONE-ADDR in the HA field.

Comments?

	Henrik

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

---

From: Milind Kulkarni <[email-masked]>
Date: Wed, 16 Feb 2005 14:03:21 -0800

Henrik,

Thanks for summarizing your thoughts.

First of all, I beg to differ but I'm not convinced that
the legacy FA issue is so serious that it warrants
re-designing of extensions. I'm concerned that the discussions
about technical solutions and optimizations might pose a danger
of losing the scope of legacy FA "issue" at hand.

I'll save some typing and cite an earlier email from Kent on
this thread:

-------------------------------------------------------------
The procedure in this draft happens when MN needs to be anchored
to an HA.  Typically, this is first time MN boots up.  There's no rule
against re-anchoring to a new HA when MN knows there are no active
sessions.  But each time can be perceived by the user as a bootup
of a new home address (to the dynamically assigned HA). Applications
would need to register themselves using the new address for
example.

As for Mobile IPv4 deployments with FA, CDMA2000 and iDEN
operators dominate in numbers.  CDMA2000 already support
dynamic HA based on IS-835.  IDEN will not support this feature.
Outside of these networks, MN works mostly in collocated
CoA mode.

Personally, I don't think this is a big issue since there is almost
no case in real world that this scenario actually happens. We added
the legacy FA section for completeness. I think having the MN
detect the legacy FA by falling back to base MIP operation is
sufficient.
-------------------------------------------------------------

In short, it is a corner case. But even if it happens, the only
down side is few msec delay on boot-up of the MN. Is this really
a big enough problem, something that requires retrofitting
the draft?

Please see below for more comments on your suggestions...

Henrik Levkowetz wrote:

> to base Mobile-IP behaviour, we define an alternative method 

I'm in total agreement about the goal here. But I didn't understand
how the mechanisms given below achieve that.

 > for the MN
> the MN may fall back to this signalling after a very brief delay.  

How did the MN know to fall back to legacy behavior here? How did the
MN find out the FA positively doesn't support ALL-ZERO-ALL-ONE-ADDR?

 > The

I'm still not clear on above 3 choices, how does the MN decide to use
old or new behavior.

Thanks,
Milind

---

From: Kent Leung <[email-masked]>
Date: Wed, 16 Feb 2005 14:41:23 -0800

Hi Henrik.  Thanks for your feedback.

In the new proposal, I don't see what value is set in the Home Agent
field in the RRQ from MN?  For dynamic HA case, MN will not know
which HA address to use.  So what value does MN set that will be
backward compatible?

Kent

At 02:03 PM 2/16/2005 -0800, Milind Kulkarni wrote:
>>>>>   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.
>>>>

--
      |           |                   Kent Leung
     :|:         :|:                  IP Mobility Development
    :|||:       :|||:                 Internet Technologies Division
   :|||||||:   :|||||||:              Voice: 408.526.5030
.:|||||||||:.:|||||||||:.             Fax:   408.525.1653
  c i s c o S y s t e m s             Email: [email-masked]