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 12:29:16 -0500

Ack, lets wait for Henrik.
 
Henrik, no pressure mate....we are all just shitting on our hands waiting
for you :-)
 
George

-----Original Message-----
From: Alpesh [mailto:[email-masked]]
Sent: Friday, December 12, 2003 5:15 PM
To: Tsirtsis George
Cc: 'Kent Leung'; Henrik Levkowetz; [email-masked]
Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as
signment-02.txt

George -

Oh, don't get me wrong - I totally agree with both the suggestions and
understand them. We had been thinking
of a revision on similar sort a little before last IETF, but are holding for
Henrik's draft to come out :)

Alpesh

Tsirtsis George wrote:

I am suggesting two things:
 
1) Allow the HA to send a positive RREP with an optional HA redirection
extensions. This will allow a MN to change to the new HA at a time that is
convenient to it i.e.: when it is idle and thus sessions will not be
interrupted
 
2) Allow the HA to send a negative RREP with a compulsory HA redirection
extensions. This will allow an HA to offload a MN for whatever reason to
another HA (with which it may or may not share state)
 
Suggestion (1) above does not cause any session interruption and I sense
that you guys are ok with? Suggestion (2) may cause session interruption and
at least Henrik was not a big fan of this.
 
Henrik's draft, if I understand this correctly, allows HA redirection at any
time but only between HAs that *share* state.
 
The kulkarni draft also allows for HA redirection during initial
registration as it has already been stated
 
Is this making any sense? :-)
 
George

-----Original Message-----
From: Alpesh [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Friday, December 12, 2003 4:26 PM
To: Tsirtsis George
Cc: 'Kent Leung'; Henrik Levkowetz; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Mip4] WG adoption call on draft-kulkarni-mobileip-dynamic-as
signment-02.txt

George -

Yes, but the 'redirection' was intended to happen during the initial
registration. With little extension/
expansion of interpretation of the text we can accomodate the 'in-session'
redirection/reanchoring
that you suggest. But that would break the session. Henrik's draft would
achieve reanchoring without
losing session - probably both methods can be supported?? 

Alpesh

Tsirtsis George wrote:

But the draft clearly *also* talks about redirection for the purpose of

routing optimality....mind you I think this is a good thing :-)

George

-----Original Message-----

From: Kent Leung [ mailto:[email-masked] <mailto:[email-masked]> ]

Sent: Friday, December 12, 2003 3:57 PM

To: Henrik Levkowetz

Cc: Tsirtsis George; Tsirtsis George;  [email-masked] <mailto:[email-masked]> 

Subject: Re: [Mip4] WG adoption call on

draft-kulkarni-mobileip-dynamic-as signment-02.txt

Right, the solution provided in this draft is for dynamically assigning

an HA for initial registration.  The mechanism allows the network to

choose an HA when MN request with AZOA or notify the MN the assigned

HA when MN request an administratively prohibited HA in RRQ.

Kent

At 04:40 PM 12/12/2003 +0100, Henrik Levkowetz wrote:

On Friday, 12 Dec 2003, George Tsirtsis wrote:

The discussion was, however, about redirection to an HA that does not

necessarily share any state with the current HA.

<chair hat off>

  Ok. It wasn't clear to me at first that this was what you desired,

  rather than what you thought you at best could get...

</chair hat off>

The question is whether

such redirection should only be optional or whether optional and

compulsory

redirection should be allowed....(I prefer the latter).

<chair hat on>

  From the viewpoint of the problem the dyn-assignment draft originally

  aimed to solve, only dynamic assignment at the start of a session was

  considered and seemed to make sense.

  If we are now talking about extending this to a mechanism which will

  break off a session, but include a next-ha in the RRP refusal, I think

  we need to make sure we have a constituency which needs such a thing,

  and we have to weigh the benefits against the drawbacks of having

  a re-assignment mechanism which breaks off the current session.

</chair hat on>

<chair hat off>

  If we're going to have a mechanism to refuse a re-registration with

  a pointer to another HA, I'd prefer to be able to have it both

  optional and compulsory, as you seem to prefer too. But I'm not

  quite sure if the benefits in reduced round-trips of such a solution

  outweigh the simplicity of the HA simply refusing a registration, and

  the MN subsequently trying to register a new session and at that time

  be assigned a new HA, according to the mechanism of the current draft.

  Possibly it does.

</chair hat off>

Non of this seems to me to be affecting your draft as you describe 

below but

I will wait for it to come out so I can get the full picture of what is

being proposed.

<chair hat off>

  Fair enough.

</chair hat off>

        Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 12 Dec 2003 19:05:03 +0100

Hi Guys,

<chair hat off>

    It's Friday evening here, and I should have gone home an hour ago :)
but was held up in a coupld of other discussions.

As I mentioned in an earlier post, the mechanism is to let a HA signal
an MN that it is taking over responsibility for an ongoing session from
another HA. To me this has only made sense if the HA's can serve the
MN with the same home address; otherwise you'd get a broken session.

The HA's would be situated physically close, but with different routes
to the internet, to provide a greater redundancy than what you could
get with a pure VRRP or CARP solution.

I didn't intend at all to go into the area of HAs providing different
home addresses, as I felt that if that should be done at all (it's a
break against one of the fundamentals of Mobile IP that you're not at
a fixed well known home address any more) it should be done at session
start, not in the middle of a session.

But now it seems that we're potentially extending the area of interest
for both drafts to the point where they may overlap:

  * The dyn-assignment draft might be extended to send redirection
    RRPs back not only at session start, but also during an ongoing
    session

  * The upcoming re-assignment or redundancy draft could be extended
    to let an backup HA initiate a message not only when it serves
    the same home network, but also in the case where it would
    provide a new home address, and session disruption would follow
    but service could be maintained (after the disruption)

Do we need this? 

Do we need both mechanisms? 

It seems to me that the major difference between these convergent
functions is that in one case (good if you want to offload MNs to sister
HA's) the signal comes from the old serving HA, while in the other case
(good if you want to take over if a sister HA has failed) the signal
comes from the new HA.

	Henrik

</chair hat off>

---

From: Pete McCann <[email-masked]>
Date: Fri, 12 Dec 2003 12:56:07 -0600

George, I'm sure you didn't mean that exactly. :)

Anyway, I wonder why the HA is in a good position to do a redirect to
a "more local" HA, especially because the two HAs are by definition
not local to each other and are likely to be in different
administrative domains.

Instead, it seems like the MN could implement some policy for shifting
its HA, based on information about the domain to which it is connected
(FA NAI?) and the existence of any local sessions.  Note that "local
sessions" may include low-traffic TCP connections (terminal shells)
which it may be difficult or impossible for the HA to detect.

When no local sessions exist, the MN could request the assignment of a
new HA based on the existing draft.  It could even leave its existing
registration in place for a period of time if it wanted to overlap the
two registrations.

Load balancing/failover (within the same location/administrative
domain) might be a better motivation for redirecting an in-progress
session.  However, it is possible to solve at least some aspects of
this problem without any new protocol changes to Mobile IP, see, e.g.:

  http://www.cs.wustl.edu/cs/techreports/1998/wucs-98-11.ps.Z

-Pete

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

---

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

> not local to each other and are likely to be in different 

I have the same doubt, among others.

> http://www.cs.wustl.edu/cs/techreports/1998/wucs-98-11.ps.Z

Thanks for the reference.

I think it is also possible to achieve a certain degree of load
balancing by assigning two HA's on the same link the same IP address, at
least with CARP.  I do not think there is any problem in achieving load
balancing for HA in this way.

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 12 Dec 2003 21:45:56 +0100

> balancing for HA in this way.

Not a problem, but remember you still have to arrange to have registration
requests to be forwarded between the two HA's, but only replied to by one
of them. CARP (or VRRP) won't take care of that for you.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 12 Dec 2003 21:56:51 +0100

Friday 12 December 2003, Alexandru wrote:
> Henrik Levkowetz wrote:
> > The HA's would be situated physically close, but with different 
> > routes to the internet, to provide a greater redundancy than what you
> >  could get with a pure VRRP or CARP solution.
> 
> I don't think that CARP requires the HA's to have same unique route to
> the Internet.  In my understanding it's just required the two hosts to
> have a common link such that ARP works on that common link.

VRRP and CARP lets one box take over and operate on the address of the
other box, catching remote and local registrations at that address. If
the MN is going to route it's RRQs to a completely different address, 
which is routed through other paths, you'll need something in addition
to - or instead of - CARP. 

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Dec 2003 21:10:35 +0100

Alex

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 12 Dec 2003 21:57:24 +0100

>   http://www.cs.wustl.edu/cs/techreports/1998/wucs-98-11.ps.Z

Yes, this is an implementation with the same characteristics as the
VRRP / CARP based solutions I was talking about earlier. I didn't
know of this particular reference, but have looked at HARP earlier.

	Henrik

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Dec 2003 22:16:13 +0100

Henrik Levkowetz wrote:
>>> domain) might be a better motivation for redirecting an 
>>> in-progress session.  However, it is possible to solve at least 
>>> some aspects of this problem without any new protocol changes to 
>>> Mobile IP, see, e.g.:
>>> 
>> balancing by assigning two HA's on the same link the same IP 
>> address, at least with CARP.  I do not think there is any problem 
>> in achieving load balancing for HA in this way.
> 
> Not a problem, but remember you still have to arrange to have 
> registration requests to be forwarded between the two HA's, but only 
> replied to by one of them.

Ah yes, that is right.  I only thought about fault tolerance in fact,
where if one HA goes down (so not sending any more replies) there will
be one other HA staying up.  The way those two HA's have their data
synchronized is by "disk mirroring" I've seen.

With HA off-loading an MH to another HA, it is indeed different and new
registrations would be needed.

Alex