Subject: RE: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as signment-02.txt

From: Tsirtsis George <[email-masked]>
Date: Fri, 12 Dec 2003 05:06:27 -0500

Inline...

-----Original Message-----
From: Kent Leung [mailto:[email-masked]]
Sent: Thursday, December 11, 2003 11:40 PM
To: Tsirtsis George
Cc: 'Henrik Levkowetz'; [email-masked]; Pete McCann
Subject: RE: [Mip4] WG adoption call on
draft-kulkarni-mobileip-dynamic-as signment-02.txt

At 06:26 AM 12/11/2003 -0500, Tsirtsis George wrote:

>  "I support the adoption of this document as a workgroup document"
>
>
>A little bit more thought should be put into redirection from one assigned
>HA to another. This is the case where a MN is registered with HAx and
>potentially has active sessions based on the assigned HoAx. Based on
section
>4.2.2, HAx may for example detect that the MN is moving too far away from
>HAx and closer to HAy. HAx can then reject the next RREQ from the MN with a
>REDIRECTED-HA-ADDRESS Extension pointing to HAy. According to the current
>text the MN has now no choice but dropping HoAx (and all its associated
>sessions) to register with HAy which should provide HoAy. This will cause
>sessions to drop for the benefit of optimizing routing...not ideal IMO.

Right.  The assumption is that the MN is intelligent enough to decide 
exactly when
to re-anchor with a new HA (such as in idle state).  While MN has an active
session, it needs to maintain HoAx by setting the HA Address field to HAx
and not AZOA.

GT> Section 4.2.2 does not seem to say this. Instead, it says that the RREQ
sent by the MN may have HA = (ALL-ZERO-ONE-ADDR  OR unicast address)....see
packet format in step 1&2. In EITHER case the HA is able to reject and
redirect (step 3).

>One way to avoid this is to introduce a flag that specifies the redirection
>as optional or compulsory. If it is optional the MN should be able to stay
>with HAx for a while longer (e.g.: until current sessions stop and MN is
>idle). This may also require the REDIRECTED-HA-ADDRESS Extension (with
>flag=optional) to be attached to positive RREP rather than rejections. If,
>however, flag=compulsory (due to policy or other reasons) then the MN will
>have to register with HAy immediately per current draft and
>REDIRECTED-HA-ADDRESS Extensions will be attached to a reject RREP.
>
>Thoughts?

Redirection is optional or compulsory based on the HA address field being 
set to
HAx or AZOA.  If MN wants to stay with HAx until the active session
terminates, then the HA address field is set to HAx.  If MN don't care which
HA
is being used, and want optimal routing, then AZOA should be used in RRQ.

Does this satisfy your needs?

GT> Almost. Maybe both things should be possible. If the MN wants to
optimize routing then it should be able to send an ALL-ZERO-ONE-ADDR to the
HA. This assumes that the MN has some understanding of the topology which
may be true in some cases. In other cases, however, it might be the HA that
has understanding of the topology, in which case the HA should be able to
send either:
- a *positive* RREP with an *optional* REDIRECTED-HA-ADDRESS extension OR 
- a *negative* RREP with a *compulsory* REDIRECTED-HA-ADDRESS extension.

>Finally, I think the draft would benefit from some clarification about how
>dynamic/static HoA allocation is affected by HA redirection. When HA
>redirection is used for load balancing (i.e.: all HAs are likely to be able
>to handle all HoA prefixes) MNs with static HoAs may be redirect. This can
>not be done if the HA redirection is used to provide a local HA to the MN
in
>which case the assigned HAs are not likely to support all the HoA prefixes.

Right, we should add more content on this topic.  My take on this is that
for
RRQs with static HoAs, the HoA field provides indication to the entity
that's
doing redirection to reach the proper HA (one that has the HoA subnet).

GT> Agreed.

Thanks
George

-- 
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 12 Dec 2003 12:13:15 +0100

George, Kent,

My impression of what this draft sets out to do is to provide a mechanism
for dynamically assigning a HA at the time of initial registration. Assigning
a new HA during an active session for the reasons given in this draft 
(primarily more optimal routing) does not seem like a magnificient idea, 
as there is the assumption of different geographic location, and hence
different home addresses for the two HA assignments, which means that such
a re-assignment during ongoing call will result in disruption of TCP sessions.

_Re_-assignment of HA during an active session for reasons like fail-over
I believe needs a different handling, and hopefully will be covered to
your satisfaction in the dynamic HA re-assignment draft I'm working on,
and hopefully will have out in a few weeks.

So I'm a bit doubtful about building in options in this draft which will
result in session disruption.

	Henrik