Subject: [Mip6] Re: Re: Home Agent Reliability and (Home Agent Selection?)]

From: "Jahanzeb Faizan" <[email-masked]>
Date: Tue, 10 Feb 2004 09:56:29 -0600

Hi Vijay,

I am glad to hear from you about the progress in the WG. Also thanks for
your comments and suggestions regarding the modifications in our draft
(http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-00.txt ) .
Please find my comments below followed by "Jahanzeb->"

> hi all,
>
> I was asked by the MIP6 WG chairs to refine the problem
> statement draft for HA reliability and use it as a basis
> for the work in the MIP6 WG.
>
> I read through your draft and have a few comments.
>
> I would like the problem statement to be expanded to
> include the case when the home link fails. if the home
> link (or a router upstream) fails, then having multiple
> Home Agents on the same link is not going to help HA
> reliability. it would be nice if the HAs can be in
> phyically separate locations. the problem statement draft
> does not have to make this the default case, but should
> allow for Home Agents to be placed in the physically
> different locations.
>

Jahanzeb->

Yes you are right in making this point of link failure, but allowing the HA
to spread around different links

1. will cause MN to perform multiple home registrations on different HAs
which will increase burden on air bandwidth and MN itself.
2. Also MN has to establish IPsec Security Associations with all its HAs
which is again a big overhead.
3. Moreover this will not solve the problem of "Delayed Failure Detection"
as we have discussed in our draft.

So I think if we want to take link failure into consideration then we should
come up with some thing else , other than allowing HAs to exists on
different links.

> section 3 now covers Failure Detection and configuring
> security associations with the new HA. I think it should
> be expanded to include HA switching. HA switching has
> two parts to it. the first, how does the MN switch to
> another HA? relying on failed BUs and MPSs will take too

Jahanzeb-> 

In our draft we have included the discussion about how MN will
switch to another HA on the basis of current specifications
of Mobile-IPv6. Please refer to the following para in sec 3.2 of our draft

" Once the failure is detected, MN will try to register its Care of
   Address with any other Home Agent on the subnet. For this MN must
   know which other Home Agents are available on the subnet. MN MAY
   start Dynamic Home Agent Discovery(DHAD)[1] protocol and as the
   result will get list of available Home Agents on the subnet. MN could
   then select HA_x (in our scenario) on the list as its potential
   serving Home Agent. MN will send BU message to HA_x setting Home
   Registration(H) bit. "

> long. the second part, how does one HA take over from a
> failed HA? was there some shared state between the HAs
> which made it possible for one HA to take over from the
> failed HA?
>

Jahanzeb->

 We have included this point in the "Solution Guidelines" section
instead of putting it in the "Problem Statement"  section. Actually
according to current specifications of Mobile-Ipv6 failure of any HA on the
subnet does not drive any other HA to do any kind of recovery work , except
updating their HA Status Lists and deleting the entry for the failed HA. All
the recovery load is on MN itself i.e MN after failure of its working HA has
to register with a new HA on the subnet. So there is no such thing or even
need of having this kind of recovery work (a new HA take overs the failed
HA) on the basis of current Mobile-IPv6 specificatios. That's why we didn't
consider it as a problem rather took it as a "Solution Requirement"

> there is also the issue of load balancing. if a HA wants
> to reduce its load, it should be able to force a
> particular MN to start using another HA.
>

Jahanzeb->
Yes you are right. We should inlcude it in the problem statement.

> I dont agree with 4.3 (Seamless failure) and 4.4 (Mobile
> Node functionality). infact section 4.2 conflicts with
> both 4.3 and 4.4. I prefer the MN to know about the HA
> switch rather than put in hacks (generally dirty) to make
> the HA switch transparent to the MN. actuallty, I would
> like to see section 4 deleted from the draft. it is
> sufficient to define the problem. I see Solution Guidelines
> as a fancy term for requirements. :) requirements always
> lead to never-ending discussions.

Jahanzeb->

 Actually I don't see requirement 4.2 conflicting with 4.3 and 4.4.
MN could remain ignorant about the HA failure and recovery process and at
the same time could have IPsec SAs with the new HA. I take 4.2 as a seperate requirement
than 4.3 and 4.4.
The aim over here is to keep the burden on MN, service interruption and
performance degradation as low as possible and at the same time maintaining
the required security as well. Moreover 4.3(seamless failure) requirement is
not MUST. We have kept it "Strongly Recommended" which implies "Should".
If people can come up with  a solution fulfilling this requirement then it
is plus point otherwise it is ok too.

>
> we should try to produce version 01 for the draft before
> the ID submission deadline next Monday.
>
> Vijay
>
>

Jahanzeb->

I think that we should also hear from rest of our MIP6 WG community before
we submit any changes in the draft.
Thanks for your time.
have a nice day.
Jahanzeb Faizan
Southern Methodist University
Dallas,TX,USA

> -------- Original Message --------
> Subject: Re: Home Agent Reliability and (Home Agent Selection?)
> Date: Tue, 03 Feb 2004 14:12:50 -0800
> From: Gopal Dommety <[email-masked]>
> To: Vijay Devarapalli <[email-masked]>
> CC: [email-masked] <[email-masked]>,        Vijay
> Devarapalli <[email-masked]>, [email-masked]
> References: <[email-masked]>
> <[email-masked]>
> <[email-masked]>
>
>
> Vijay,
>
> could you coodrinate with the SMU folks and get the ball rolling..
>
> -Gopal
>
> At 02:16 PM 2/3/2004 -0800, Vijay Devarapalli wrote:
> >Gopal, Raj,
> >
> >What do you want us to do about this?
> >
> >Vijay
> >
> >Vijay Devarapalli wrote:
> >>hi Gopal,
> >>Gopal Dommety wrote:
> >>
> >>>
> >>>Hello Vijay and Ryuji,
> >>>
> >>>     Hope you are doing well. HA reliability is in the MIP6 roadmap.
> >>>  Short term goals is to have a problem statement and and define the
current
> >>>  scope. Wanted to find out if you are interested in defining this
> >>> (based on your draft). Let me know...
> >>
> >>definitely. I would be interested in that. we tried to narrow
> >>the scope and describe the problem at the last IETF meeting
> >>itself, but I dont think we succeeded.
> >>after the last IETF meeting, there was draft put out by some
> >>folks from Southern Methodist University. it talks about
> >>problem statement for HA reliability.
>
>>http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-00.
txt
> >>
> >>I havent yet read this draft. we could use this draft as a
> >>base. if needed, I could work with these folks refining the
> >>problem statement draft.
> >>let me know what you think about this.
> >>Vijay
> >
>
>
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 10 Feb 2004 10:32:12 -0800

Hi Jahanzeb,

> come up with some thing else , other than allowing HAs to exists on

the idea is to document the problem completely. not look at
the solution or how the problem can be solved. Home Link
failure is something that needs to be documented in the problem
statement. it is upto the WG later to figure out if that is
something that we need to solve.

>    serving Home Agent. MN will send BU message to HA_x setting Home

sure this will work. but as I said earlier, document
the problem and then look at the solutions.

> to register with a new HA on the subnet. 

we dont yet know if this is the way to go. infact this again
conflicts with your "solution guideline" of keeping this
transparent to the MN.

> So there is no such thing or even

> Yes you are right. We should inlcude it in the problem statement.

great.

> the same time could have IPsec SAs with the new HA. I take 4.2 as a seperate requirement

then, why did it setup SAs with the new HA, if the HA switch
can be kept transparent to the MN?

Vijay

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

---

From: "Jahanzeb Faizan" <[email-masked]>
Date: Tue, 10 Feb 2004 12:48:27 -0600

Hi Vijay,

It is good that things are progressing. Few more comments please find below.

Jahanzeb
----- Original Message -----
From: "Vijay Devarapalli" <[email-masked]>
To: "Jahanzeb Faizan" <[email-masked]>
Cc: "Ryuji Wakikawa" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Hesham El-Rewini"
<[email-masked]>; "Mohamed Khalil" <[email-masked]>
Sent: Tuesday, February 10, 2004 12:32 PM
Subject: Re: [Mip6] Re: Re: Home Agent Reliability and (Home Agent
Selection?)]

> > your comments and suggestions regarding the modifications in our draft
(http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-00.t
xt ) .

Jahanzeb->

I agree with you. We can include link failure problem also.

Jahanzeb->

agreed.

Jahanzeb->

This is the way current Mobile-IPv6 responds to HA failure. This is not our
proposed solution
and sure it conflicts with the requirement of keeping failure transparent to
MN. That's why we
discussed this thing in the problem statement.
I think there is no harm in clearly stating this point also in the problem
statement.

Jahanzeb->

The requirement 4.2,4.3 does not mean that MN has to establish its SAs with
the new HA by himself.
That's what the whole idea is.MN should remain ignorant about what's going
on on the subnet but at the same time
the SAs between the MN and new HA should get established by some method.

Thanks
Jahanzeb