Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for FastHa ndoff Discussion

From: George Tsirtsis <[email-masked]>
Date: Thu, 21 Dec 2000 15:37:26 -0500

May I just second Charlie's comments and remind the obvious...we create
technologies for the Internet not for a specific L2...

George

-----Original Message-----
From: Charlie Perkins
To: [email-masked]
Sent: 12/21/00 2:14 PM
Subject: Re: [MOBILE-IP] Architectural v.s. Incremental Lession for
FastHandoff Discussion

Hello Jim,

> There were some significant technical objections to some of the the
proposed IPv6
> extensions raised during the meeting. In particular, the need for a
binding
> update and binding reply over the old link after L2 at the old
mobility
> router has detected the need for a handoff and started one is
problematic.
> I do not believe one can guarantee L2 connectivity after L2 has
decided a
> handoff is necessary.

Then this results from a misunderstanding.  We allow but do not require
these messages.  If they are supplied, then in some scenarios the
handoff
can be faster.  If the network initiates the handover, these messages
are
not needed to initiate the fast handover.  I believe that everyone in
the
IPv6 design team would quite agree with your assessment about whether
L2 can be relied upon for the delivery of the messages.

> I would actually rather propose the opposite, that the IPv6 take a
hard look
> and winnow down their proposals to ones that have a realistic chance
of working,
> rather than trying to split the difference for purposes of concensus.

We did not split the difference.  We decided which scenarios needed
work,
and designed messages to support those scenarios.  Generally, the same
messages are used in the different scenarios, but perhaps applied in
different
orders.

> In the final analysis, the *real* test in all this is "running code."
If the
> Hesham/Karim proposal and the IPv6 proposal for signalling over L2
during
> handoff works, then lets include it in the drafts. If not, then lets
drop them.

There is running code, to within a certain degree of imprecision caused
by changes from the design team.  I think that we should have one
solution
per problem.  Different ways of applying layer-2 triggers result in
different
problems.  We cannot expect that layer-2 triggers will be applied in the
same way in all future systems, so it is very prudent to determine which
problems need solving, and look for as many common denominators as
we can find.

Regards,
Charlie P.