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 08:06:51 -0500

Henrik,

I think the point of my suggestion below is to make sure that session
disruption does not take place in the normal case:
- MN sends ALL-AERO-ONE-ADDR when idle or 
- HA sends an HA-Redirect in a positive RREP, in which case MN initiates
redirect as soon as idle). 

I think, however, that it is worth letting the HA redirect a mobile in a
compulsory way (HA sends HA redirect in negative RREP) if that is what needs
to be done from network perspective (e.g.: topology reasons, overloading
etc).

Note that MIP already allows session disruptions since an HA can always
reject a RREQ in which case sessions will be dropped. HA redirection
improves on that by allowing an HA to redirect an MN to another HA rather
than dropping it altogether.

George
P.S: So, does your draft compete with this one? or it solves a different
problem?
-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]]
Sent: Friday, December 12, 2003 11:13 AM
To: Tsirtsis George
Cc: 'Kent Leung'; [email-masked]
Subject: Re: [Mip4] WG adoption call on
draft-kulkarni-mobileip-dynamic-as signment-02.txt

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

On Friday, 12 Dec 2003, George wrote:

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

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

---

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

> redirect as soon as idle). 

Ok so far,

> to be done from network perspective (e.g.: topology reasons, overloading

Yes, but I'm not sure whether it belongs in this draft or in the other.

> than dropping it altogether.

Right, but see below.

> P.S: So, does your draft compete with this one? or it solves a different

The intention is to _not_ compete. The charter says:

  Home agent assignment at the time of mobile-ip registration, rather
  than preconfigured for the mobile node, has been proposed in
  draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will
  take on the task of completing this. The ability to switch the home
  agent assigned to a mobile node while registered will also be
  considered as part of this task. 

So the draft I'm working on will propose a message which can be originated
by the HA, saying in essence "from now on, the registration you had with
HA so-and-so will insead be handled by me"; the intention being to support
failover, overload etc.  One prerequisite for this mechanism is that the
two HA's have some way to share state - the most straightforward way being
to forward registration request and reply messages from the active HA to
the standby HA.

So I guess the dividing line would be whether the circumstances were such
that you could continue a session, or whether you anyhow would need to
break and re-establish. In the latter case, it seems reasonable to make
it part of dyn-assignment, in the other case it seems to belong with
the upcoming draft (reg-reassignment? failover? xxxx?).

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Dec 2003 20:55:56 +0100

Tsirtsis George wrote:
> I think, however, that it is worth letting the HA redirect a mobile
> in a compulsory way (HA sends HA redirect in negative RREP) if that
> is what needs to be done from network perspective (e.g.: topology
> reasons, overloading etc).

If it is worth considering that the network indicates the MH what to do
and how to do it, then there are some other additional proposals,
draft-lach-nac-* being one and there were many others in the past.

Alex