Subject: RE: [mobile-ip] Reverse tunneling issues

From: George Tsirtsis <[email-masked]>
Date: Tue, 2 Apr 2002 12:52:46 -0500

James,

The draft talks about a few ways of handling the state removal at the
HA...you obviously still have not read it :-)
The two options that do not require configuration change are i) fixed timer
(say 5sec) that the HA will keep the old binding after a new binding is
received or ii) the HA could just keep the old binding until its lifetime
expires...which is for lazy implementers that do not want to implement yet
another timer in their system, present company excluded of course :-).

How does that sound?

George

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Tuesday, April 02, 2002 5:53 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mobile-ip] Reverse tunneling issues

George,

While I support this, I'd like to ask you the same question that was
asked about BETH: what causes the old tunnel state to get cleaned up?
People seemed to feel that cleaning up tunnel state in ARs was important
for BETH, and I believe the same argument can be made for the HA.

            jak

----- Original Message -----
From: "George Tsirtsis" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 02, 2002 1:28 AM
Subject: RE: [mobile-ip] Reverse tunneling issues

> Jari,
>
> Here is the deal...
>
> draft-oneill-mip-revtun-ho-00.txt in section 6. "IPv6 Considerations"
> currently suggest:
> "The IPv6 HA should support the automatic invocation of a fan-in
binding if
> reverse tunneling is requested."
>
> "Fan-in bindings" are explained earlier in the document
> This essentially says that when reverse tunneling is used the HA has
to
> maintain at least 2 bindings for the MN, at least for a short time
during
> handoff.
>
> So for example,
> - Assume a MN that uses reverse tunneling
> - After the MN hands off to a new CoA it sends the appropriate BU to
the HA
> - The HA registers the new binding to the newCoA and immediately uses
it for
> all downlink traffic.
> - The HA also keeps the oldCoA binding for a while but only uses it so
that
> it can accept in-flight packets from that oldCoA
> - The old binding is removed if/when the MN moves to yet another
(third) CoA
> or after a default timeout.
>
> The above works for both MIPv4 and MIPv6 and does not require any
signaling
> changes, but only behavior changes at the HA i.e.: currently a new
Binding
> REPLACES the old Binding. The text needs to be revised to say that the
new
> Binding REPLACES the old Binding for downlink traffic but it is ADDED
to the
> old Binding for reverse tunneled traffic.
>
> Also note that while the above helps, it does not solve the problem
> completely for reasons explained in the draft. To solve all problems
with
> reverse tunneling we need signaling changes/extensions which I guess
could
> be described in a new draft.
>
> Does this make sense?
>
> Regards
> George
>
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Saturday, March 30, 2002 2:09 PM
> To: [email-masked]
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: [mobile-ip] Reverse tunneling issues
>
>
> George Tsirtsis wrote:
>
>
> > GT> No problem...have a look at the draft and do not let the too
many
> > options of how to solve the problem confuse you ...this is not
> complex...it
> > is just that it has to be dealt with.
>
>
> Assuming something has to be done, is this something that has to go to
> the base RFC, or something that can be done in an extension
separately?
> Jari

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Apr 2002 10:15:28 -0800

> HA...you obviously still have not read it :-)

Yes, sorry.

> another timer in their system, present company excluded of course :-).

The first option has the problem that it may cut off traffic
prematurely, though 5 sec. is pretty generous and the packets would need
to be really laggard for that to be a problem. The second sounds OK and
is probably better from a practical standpoint. There were objections to
letting tunnel state simply time out on ARs for BETH and there was some
insistence on actually having signaling to clean it up, if I recall
correctly. But if nobody is complaining now, then I've got no problem
with it.

            jak