Subject: [Mip6] I-D ACTION:draft-ietf-mip6-ha-switch-00.txt

From: [email-masked]
Date: Wed, 14 Jun 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobility for IPv6 Working Group of the IETF.

	Title		: Mobility Header Home Agent Switch Message
	Author(s)	: B. Haley, et al.
	Filename	: draft-ietf-mip6-ha-switch-00.txt
	Pages		: 11
	Date		: 2006-6-14
	
   This document specifies a new Mobility Header message type that can
   be used between a home agent and mobile node to signal a mobile node
   that it should acquire a new home agent.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mip6-ha-switch-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mip6-ha-switch-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 19 Jun 2006 17:38:04 +0200

Hi,

it seems that the draft does not support switching to a HA serving a
different than the current home link, i.e., switching to a new primary
HoA at the same time. At least the draft prevents the MN from keeping
the registration with the old HA, which IMHO would be neccessary in this
case in order to keep existing sessions (using the old HoA) alive. The
renumbering scenario mentioned in the draft seems to consider
renumbering of HA addresses only, not HoAs. 

Is there any reason for excluding such scenarios?

Regards,

Kilian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Mittwoch, 14. Juni 2006 21:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt 
> 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Brian Haley <[email-masked]>
Date: Mon, 19 Jun 2006 14:21:07 -0400

Hi Kilian,

Kilian Weniger wrote:
> HoA at the same time.

I think we just need to remove or replace sections of the draft that 
mention the "home link" with something more appropriate, limiting all 
the HA's to the same link was not the intention.

> At least the draft prevents the MN from keeping
> case in order to keep existing sessions (using the old HoA) alive.

The MN should be able to keep it's HoA as long as there is another 
available HA to switch to that's serving that prefix.

> The

The renumbering for the home link can be done with just RFC 3775 
messages - Mobile Prefix Solicitation and Advertisement.

-Brian

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 20 Jun 2006 10:00:08 +0200

Hi Brian,

> From: Brian Haley [mailto:[email-masked]] 
> Sent: Montag, 19. Juni 2006 20:21
> To: Kilian Weniger
> Cc: [email-masked]
> Subject: Re: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt
> 
> Hi Kilian,
> 
> Kilian Weniger wrote:
> > Hi,
> > 

good

> available HA to switch to that's serving that prefix.

The scenario I was talking about is that the switch message sent by the
HA directs the MN to a new HA serving a different link, resulting in a
new HoA for the MN after bootstrapping with this HA. Section 5.1 (MN
operation) says

"Upon receipt of a Home Agent Switch message, the mobile node MUST
   stop using its current home agent for services and MUST delete its
   home binding by sending a Binding Update message as described in [2].
   This acts as an acknowledgement of the Home Agent Switch message."

When strictly following the procedure described in the draft, I don't
see how the MN can keep its old HoA. The MN must send a BU to delete the
binding for the old HoA and cannot skip that, since the BU acts as ack
for the switch message.

To support the scenario, it should IMHO be possible to keep the
registration with the old HA (at least for a certain period of time) if
the bootstrapping with the new HA results in a new HoA. The switch
message could indicate (e.g., by a flag) whether the old HA is able to
keep serving the MN as secondary HA for some time (to keep existing
session alive and to keep IP reachability until the new HoA is
published). When receiving a switch message with this flag set, the MN
would not be required to delete the binding at the old HA immediately
(note that strictly speaking this would not be a HA switch, since the
registration with the old HA would not be deleted).

> messages - Mobile Prefix Solicitation and Advertisement.

yes, but if the above scenario is supported, renumbering of certain HoAs
would also be possible with the switch mechanism only. If the switch
mechanism is needed for renumbering is of course another question.

-Kilian

---

From: Brian Haley <[email-masked]>
Date: Tue, 20 Jun 2006 15:35:34 -0400

Hi Kilian,

>> available HA to switch to that's serving that prefix.

The HA being switched-to should be serving the same set of prefixes as 
the current HA, we'll need to add some text to say that SHOULD be the 
default, else there will be loss of connectivity to the HoA.

> binding for the old HoA and cannot skip that, since the BU acts as ack

As I said above, the intention is the new HA should support the HoA.

> registration with the old HA would not be deleted).

The HA is sending the switch message because it can't continue to act as 
the HA for this MN, so keeping the binding around is not an option.

> mechanism is needed for renumbering is of course another question.

I don't want to burden HA switch with network renumbering, Section 10.6 
and 11.4.3 of RFC 3775 already cover this.

-Brian

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 21 Jun 2006 09:41:41 +0200

Hi Brian,

> Sent: Dienstag, 20. Juni 2006 21:36
> To: Kilian Weniger
> Cc: [email-masked]

ok, now I understand your intention.
 
Note that there would not necessarily be a loss of connectivity if the
MN would be allowed to keep the registration with the old HA (which I
was proposing). The old HA could indicate (by a flag in the switch
message) if it is able to continue to serve as HA for the MN. Scenarios
I have in mind are that the network (i.e., HA) can direct the MN to
another HA on a different link (e.g., to a more local HA), which is
better with respect to optimized routing or for load balancing between
HAs on different links. 

> the HA for this MN, so keeping the binding around is not an option.

First of all note that in some cases in the current draft, the old HA
would probably be able to continue to acts as HA to some extent (e.g.,
load balancing).

But if the old HA cannot continue to act as HA (e.g., because it will be
shut down), keeping the binding in this HA is of course not an option.
The modification I had in mind just extends the applicability of the
switch mechanism by allowing the HA to send switch messages to direct
the MN to a HA serving a different link and continue to serve as
secondary HA (e.g., for the scenarios I mentioned above). 

> and 11.4.3 of RFC 3775 already cover this.

My intention was not to support HoA renumbering with the switch
mechanism, it would just be a side-effect of the modification I
proposed...

-Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 23 Jun 2006 09:33:54 +0200

Brian,

In my last mail I described scenarios that the current draft does not
support (see snippet below) and sketched an extension to support such
scenarios. What do you and the authors of the draft think about this?
For instance, shouldn't load balancing between HAs serving different
links be supported? MN could obtain a new HoA from the new HA and keep
the old HA/HoA as secondary for existing sessions only (e.g., old IPv6
HoA is moved to deprecated state, new one to preferred state)? 

- Kilian

> Scenarios
> ...
> secondary HA.