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

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 27 Jun 2006 10:34:58 +0200

Hi Hui, 

> -----Original Message-----
> From: "DENG, HUI -HCHBJ" [mailto:[email-masked]] 
> Sent: Freitag, 23. Juni 2006 15:20
> To: Kilian Weniger; Brian Haley
> Cc: [email-masked]
> Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt
> 
> Hi, Kilian,
> 
> I start to understood what you mean here,
> You would like to do geographical different home prefix load balance,
> I am a little thinking about this usage in the real word.

For example if all HAs on the link are almost overloaded or if the home link itself is almost overloaded, it would be good to support load balancing between HAs on different links. Another usage scenario would be optimized routing: another HA on a different link (e.g., a more local HA) may provide a shorter route.

> 
> but one thing interested me is that
> your session is still kept in the previous home agent, is it 
> called load balance?

The load caused by new sessions is shifted from one HA to another, so I would call it load balancing (even though the load for existing sessions remains at the old HA for the time the sessions are active)

> 
> Secondly, how could MN notify CN about its HoA changing.

By DNS updates (see draft-ietf-mip6-bootstrapping-split-02.txt) or by some application-level signaling (e.g., SIP)

> 
> I suggest that if possible you could write up your solution.
> Then we could figure out its applicability.

I probably won't have enough time in the next days. Do you need more information than provided in the mails to decide about the applicability?

-Kilian

> 
> Thanks
> 
> -Hui
> 
> 
> 
> > -----Original Message-----
> > From: Kilian Weniger [mailto:[email-masked]] 
> > Sent: 2006年6月23日 16:04
> > To: DENG, HUI -HCHBJ; Kilian Weniger; Brian Haley
> > Cc: [email-masked]
> > Subject: RE: [Mip6] RE: I-D ACTION:draft-ietf-mip6-ha-switch-00.txt
> > 
> > 
> > Hi Hui,
> > 
> > The MN would setup Ipsec SAs using IKE with the second HA 
> > (which is located on a different link than the first HA). The 
> > new Ipsec Sas would be based on the new HoA (whose prefix is 
> > not served by the first HA). The IPSec Sas with the first 
> > (old) HA are still setup based on the old HoA. Can you 
> > elaborate what would be the issue with that?
> > 
> > -Kilian
> > 
> > > -----Original Message-----
> > > From: "DENG, HUI -HCHBJ" [mailto:[email-masked]]
> > > Sent: Freitag, 23. Juni 2006 09:41
> > > To: Kilian Weniger; Brian Haley
> > > Cc: [email-masked]
> > > Subject: RE: [Mip6] RE: I-D 
> ACTION:draft-ietf-mip6-ha-switch-00.txt
> > > 
> > > 
> > > Could you help to elaborate how IKE/IPsec SA could work in
> > > this scenario?
> > > is that session based or address based?
> > > 
> > > -Hui
> > > 
> > > > -----Original Message-----
> > > > From: Kilian Weniger [mailto:[email-masked]]
> > > > Sent: 2006年6月23日 15:34
> > > > To: Brian Haley
> > > > Cc: [email-masked]
> > > > Subject: RE: [Mip6] RE: I-D 
> > ACTION:draft-ietf-mip6-ha-switch-00.txt
> > > > 
> > > > 
> > > > 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
> > > > > 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 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.
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Mip6 mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/mip6
> > > > 
> > > Disclaimer:
> > > The contents of this e-mail, and its attachments, if any, are
> > > confidential and may be protected
> > > by law against any unauthorized use.  If you have received 
> > > this e-mail by mistake or have
> > > reason to believe that you are not the intended recipient, 
> > > please notify the sender by reply
> > > e-mail as soon as possible and delete it from your computer 
> > > system immediately thereafter.
> > > If you are not the intended recipient, you must not copy this 
> > > e-mail or attachment or disclose
> > > the contents to any other person.  While we have made every 
> > > effort to keep our network virus free,
> > > we take no responsibility for any computer virus which might 
> > > be transferred by way of this e-mail.
> > > 
> > > 
> > 
> > 
> Disclaimer:
> The contents of this e-mail, and its attachments, if any, are 
> confidential and may be protected
> by law against any unauthorized use.  If you have received 
> this e-mail by mistake or have
> reason to believe that you are not the intended recipient, 
> please notify the sender by reply
> e-mail as soon as possible and delete it from your computer 
> system immediately thereafter.
> If you are not the intended recipient, you must not copy this 
> e-mail or attachment or disclose
> the contents to any other person.  While we have made every 
> effort to keep our network virus free,
> we take no responsibility for any computer virus which might 
> be transferred by way of this e-mail.
> 
> 

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