Subject: [Mip6] about HA switch message

From: <[email-masked]>
Date: Wed, 25 Oct 2006 13:10:37 +0200

Hi,

After reading this draft again I got few questions. Maybe these
have been asked earlier already, in which case I have missed
them.

I guess the home agent switch message could also be used for general
signaling from HA to MN? I.e. setting # addresses to 1 and giving the
address of the current HA as the alternative HA address. Then using
Mobility Options to carry whatever an operator wants to sporadically
send from the HA to the MN. This would also have some side effects
on the retransmission logic I guess.

Also the security considerations state that the message must be
protected using the IPSec SAs between the HA and the MN. What
about RFC4285 auth option?

Cheers,
	Jouni

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Brian Haley <[email-masked]>
Date: Wed, 25 Oct 2006 11:53:01 -0400

Hi Jouni,

Thanks for reading the draft.

> on the retransmission logic I guess.

I guess it could do that, although it was not the intention, also the 
draft doesn't define any valid options.  I have an expired draft that is 
probably in need of an update - draft-haley-mip6-mh-signaling-01 that 
proposes that solution.

> about RFC4285 auth option?

Yes, I guess RFC 4285 auth option should be supported, I can add that in 
the next revision.

Thanks,

-Brian

---

From: "Fritsche Wolfgang" <[email-masked]>
Date: Wed, 25 Oct 2006 19:06:49 +0200

BTW, has there be a specific reason for not specifying a kind of "Home Agent Swick Acknowledgement/Reply" message?

Cheers,

Wolfgang

>-----Ursprüngliche Nachricht-----
>Von: Brian Haley [mailto:[email-masked]] 
>Gesendet: Mittwoch, 25. Oktober 2006 17:53
>An: [email-masked]
>Cc: [email-masked]
>Betreff: Re: [Mip6] about HA switch message
>
>Hi Jouni,
>
>> send from the HA to the MN. This would also have some side 
>effects on 
>> the retransmission logic I guess.
>
>I guess it could do that, although it was not the intention, 
>also the draft doesn't define any valid options.  I have an 
>expired draft that is probably in need of an update - 
>draft-haley-mip6-mh-signaling-01 that proposes that solution.
>
>> protected using the IPSec SAs between the HA and the MN. What about 
>> RFC4285 auth option?
>
>Yes, I guess RFC 4285 auth option should be supported, I can 
>add that in the next revision.
>
>Thanks,
>
>-Brian
>

---

From: Brian Haley <[email-masked]>
Date: Wed, 25 Oct 2006 13:12:45 -0400

> BTW, has there be a specific reason for not specifying a kind of "Home Agent Swick Acknowledgement/Reply" message?

The Binding Update the MN sends serves as the Ack, so there was no need 
for another message.

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Oct 2006 10:28:28 -0700

Hi Jouni,

> on the retransmission logic I guess.

the only use-case we could nail down was the HA
Switch. thats why we decided to standardize it.
if there are more cases, I guess we could
standardize a generic notification message.

Vijay

---

From: "Fritsche Wolfgang" <[email-masked]>
Date: Wed, 25 Oct 2006 19:35:51 +0200

I read this in draft-ietf-mip6-ha-switch-01.txt and also partly in draft-ietf-mip6-hareliability-00.txt, however, chapter 8.3 of draft-ietf-mip6-hareliability-00.txt also says

   "However, in this specification, the binding cache
   information is already synchronized among the redundant home agent
   set, the mobile node can skip this binding re-registration to the new
   active home agent.  In this case, the mobile node only updates the
   Home Agent address of all the binding update list, MIP6 tunnel end
   points, etc."

This seems to indicate that sending a BU to the new active HA is left as optional to the MN, that is, in this case also the Ack for the HA Switch will be optional, right?

Wolfgang

>Gesendet: Mittwoch, 25. Oktober 2006 19:13
>An: Fritsche Wolfgang
>Cc: [email-masked]; [email-masked]
>Betreff: Re: AW: [Mip6] about HA switch message
>
>Fritsche Wolfgang wrote:
>> BTW, has there be a specific reason for not specifying a 
>kind of "Home Agent Swick Acknowledgement/Reply" message?
>
>The Binding Update the MN sends serves as the Ack, so there 
>was no need for another message.
>
>-Brian
>

---

From: "Fritsche Wolfgang" <[email-masked]>
Date: Wed, 25 Oct 2006 19:58:04 +0200

Vijay,

I think there are scenarios requiring an immediate HA Switch (e.g. HA failure) and scenarios allowing for some more time to stay with the current HA (e.g. upcoming maintenance). For the latter category one could allow established sessions to stay for a certain time with the current HA, and force new sessions to make use of the new HA. This would allow established connections to survive for a certain time after receiving the HA Switch, which could be long enough to have these established sessions ended anyway. Such a time period could be one of the mobility options carried by a HA Switch message. What do you think?

Wolfgang

>Von: Vijay Devarapalli [mailto:[email-masked]] 
>Gesendet: Mittwoch, 25. Oktober 2006 19:28
>> After reading this draft again I got few questions. Maybe these have 
>> been asked earlier already, in which case I have missed them.
>> 
>the only use-case we could nail down was the HA Switch. thats 
>why we decided to standardize it.
>if there are more cases, I guess we could standardize a 
>generic notification message.
>
>Vijay
>
>>

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 26 Oct 2006 02:47:19 +0900

Hi all

BU is the best choice for the current purpose of HA switch.
HA can confirm correct tunnel setup and IPsec by receiving a BU.

regards,
ryuji

---

From: Brian Haley <[email-masked]>
Date: Wed, 25 Oct 2006 13:46:41 -0400

> This seems to indicate that sending a BU to the new active HA is left as optional to the MN, that is, in this case also the Ack for the HA Switch will be optional, right?

I think we're going to remove that text from the ha-reliability draft.

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Oct 2006 11:07:20 -0700

> I think there are scenarios requiring an immediate HA Switch (e.g. HA failure) and scenarios allowing for some more time to stay with the current HA (e.g. upcoming maintenance). For the latter cate…

sounds good to me. we can add a mobility option to
say how much time (in seconds) the MN has before
it has to pick another HA.

Vijay

---

From: Brian Haley <[email-masked]>
Date: Wed, 25 Oct 2006 15:03:29 -0400

> I think there are scenarios requiring an immediate HA Switch (e.g. HA failure) and scenarios allowing for some more time to stay with the current HA (e.g. upcoming maintenance). For the latter cate…

There was also a suggestion to put a Lifetime field in the Switch 
message, replacing the reserved field.  Would that be an option?  I 
didn't make that change in the -01 version.

-Brian

---

From: "Fritsche Wolfgang" <[email-masked]>
Date: Wed, 25 Oct 2006 22:44:19 +0200

>Gesendet: Mittwoch, 25. Oktober 2006 21:03
>An: Fritsche Wolfgang
>Cc: Vijay Devarapalli; [email-masked]; [email-masked]
>> I think there are scenarios requiring an immediate HA Switch 
>(e.g. HA failure) and scenarios allowing for some more time to 
>stay with the current HA (e.g. upcoming maintenance). For the 
>latter category one could allow established sessions to stay 
>for a certain time with the current HA, and force new sessions 
>to make use of the new HA. This would allow established 
>connections to survive for a certain time after receiving the 
>HA Switch, which could be long enough to have these 
>established sessions ended anyway. Such a time period could be 
>one of the mobility options carried by a HA Switch message. 
>What do you think?
>
>There was also a suggestion to put a Lifetime field in the 
>Switch message, replacing the reserved field.  Would that be 
>an option?  I didn't make that change in the -01 version.
>
>-Brian
>

If this lifetime will indicate how long the MN is allowed to continue to use the HA, which sent the HA switch message, for already established sessions, it would be an option.

Cheers,

Wolfgang

---

From: Brian Haley <[email-masked]>
Date: Thu, 26 Oct 2006 11:23:50 -0400

> If this lifetime will indicate how long the MN is allowed to continue to use the HA, which sent the HA switch message, for already established sessions, it would be an option.

This is what I'd put in a -02 draft:

Lifetime

A 16-bit unsigned integer indicating the number of seconds the home 
agent will continue to honor the home binding.  If set to zero, the 
mobile node MUST stop using its current home agent following the rules 
in Section 5.1.

Sound good?

-Brian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Oct 2006 09:30:34 -0700

Hello folks,

Shouldn't the time unit for lifetimes be 4 seconds (instead of
one second), to be like RFC 3775?

Regards,
Charlie P.

ext Brian Haley wrote:
> Fritsche Wolfgang wrote:
>> If this lifetime will indicate how long the MN is allowed to continue 
>> to use the HA, which sent the HA switch message, for already 
>> established sessions, it would be an option.
>

-- 
Please address return e-mail to [email-masked]

---

From: Brian Haley <[email-masked]>
Date: Thu, 26 Oct 2006 13:30:22 -0400

> one second), to be like RFC 3775?

You're right Charlie, thanks.

A 16-bit unsigned integer indicating the number of time units remaining 
before the mobile node MUST stop using its current home agent and choose 
another home agent, following the rules in Section 5.1.  A value of zero 
indicates that the mobile node MUST do this immediately.  One time unit 
is 4 seconds.

There's a bunch of other edits to make this happen, they'll all be in -02.

-Brian

---

From: "Fritsche Wolfgang" <[email-masked]>
Date: Thu, 26 Oct 2006 19:59:48 +0200

This reads fine for me, considering also the hint from Charlie concerning the time unit to be used.

Wolfgang 

>Gesendet: Donnerstag, 26. Oktober 2006 17:24
>An: Fritsche Wolfgang
>Betreff: Re: AW: AW: [Mip6] about HA switch message
>
>Fritsche Wolfgang wrote:
>> If this lifetime will indicate how long the MN is allowed to 
>continue to use the HA, which sent the HA switch message, for 
>already established sessions, it would be an option.
>
>A 16-bit unsigned integer indicating the number of seconds the 
>home agent will continue to honor the home binding.  If set to 
>zero, the mobile node MUST stop using its current home agent 
>following the rules in Section 5.1.
>
>Sound good?
>
>-Brian
>