Subject: [seamoby] context transfer/fast MIP conflict (was: [seamoby-mm] FW: I-D ACTION:draft-designteam-fast-mipv6-00.txt)

From: Michael Thomas <[email-masked]>
Date: Sat, 3 Feb 2001 12:17:46 -0800 (PST)

[why is it that John's always the shot messenger? :)]

[email-masked] writes:
 > Hi all,
 > 
 > This is probably a good thing for all of us to read.

 I've read through this and I'm struck by the fact that
 the HI and HACK do not seem to have anything to do with
 the fast handoff Mobile IP problem at all. As far as I
 can tell, they are not required since the tunnel
 is established between ARold and MN. All ARnew is 
 doing forwarding packets toward the subnet that
 it already knows how to forward to. 

 Before people get up in arms that ARnew might not 
 be willing to forward packets, I'll point out
 that that is a routing and/or admission control
 problem and seems squarely in the problem space
 that the context transfer design team seems to
 have in its charter. 

 So my question is what justification the MIP 
 design team has for initiating what amounts to
 the shell of a context transfer when their 
 charter was to figure out a way to provide a
 way to provide fast mobility during movement?
 It appears to me that their work minus the
 HI/HACK does that just fine and that it would
 be better to keep the agreed upon problem
 partition intact so that the context transfer 
 design is not needlessly hobbled by the design
 decisions which did not account for the larger
 problem.

		Mike

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 03 Feb 2001 14:40:13 -0800

Hello,

I reckon I need to supply at least part of this answer.
Also, there is a very much improved version of the draft
that will be posted on Monday, resulting from our recent
two-day design meeting last week.  It was a big success.

The [mobile-ip] working group design team did this for
a lot of logical reasons (note that I do not speak for them,
and these comments must be considered my opinions
only):

- The design does work with care-of addresses.  Maybe
   it also works with other addresses. So much the better!
   I reckon you do not suggest we should have made
   needless restrictions

- It is a routing protocol.  [mobile-ip] is a working group
  in the Routing Area.

- Everyone always knew that fast handovers should work
  with context transfers.  If it is at all reassuring (?) whenever
  anyone in the design team mentioned context transfers,
  we were told not to be concerned with that because it
  was out of scope.  Nevertheless, most people on the design
  team are aware of the general problem surrounding context
  transfer.

- The network-controlled case is explicitly designed to provide
   information needed for care-of addresses.  One of the things
   about Mobile IPv6 is that it uses natural IPv6 address
   configuration mechanisms to create care-of addresses.  Thus,
   any protocol whatsoever that we might create for the expedient
   management of new care-of address assignment, would right
   away look like an expedient mechanism for managing new
   IPv6 address assignment.

We had to solve the problem.  We had a mandate to solve
the problem.  We went about it the most direct way we could
figure out to do.  I'm surprised if this makes anyone uncomfortable.
On the contrary, I'd expect to a certain degree that other people
might be happy we did the appropriate amount of analysis and
engineering to come up with a useful solution.

On your more specific statements...

>  it already knows how to forward to.

HI provides information that the new AR needs
to avoid doing DAD.  That's useful.  The new AR provides
information to the old AR, using HAck, about whether this
avoidance is going to work.  I'm not sure about what you
meant in the last sentence.  I also do NOT believe that we
make any statement anywhere about a tunnel between
the new AR and the mobile node.  That's something which
would severely limit the applicability of our fast handover
protocol.

>  that the context transfer design team seems to

Right, if I understand you correctly.  However, in many
circumstances the admission control policy is trivial.

>  way to provide fast mobility during movement?

I think this amounts to an accusation of something,
but I'm not quite sure what.  Perhaps you would
like to reconsider your demand in light of the
foregoing explanations.

>  decisions which did not account for the larger

Without HI/HAck, there is no fast handover protocol.
Maybe I'm not getting the sense of your discussion.
No matter, I'll volunteer to try to bridge the gap in as
polite a way as possible.  Now, where is my cane?

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 3 Feb 2001 15:41:57 -0800 (PST)

> and these comments must be considered my opinions

The MIP WG seems to be schizophrenic about what it
sees as in its charter. When it punted the context
transfer problem to SEAMOBY, it should have punted
the *entire* problem, not just the parts that it
didn't feel like working on. As it stands now, MIP
WG has either decided for SEAMOBY what the
appropriate transport vessel for context transfer
is (a destination option strikes me as a giagantic
hack), or define a different protocol which deals
with everything but the few bits and dregs that
MIP needed to affect "fast" handoff (read: fast in
the narrow world view of MIP's charter).

 > - It is a routing protocol.  [mobile-ip] is a working group

Yet, you're clearly defining a transport protocol
to move CoA's, DAD state, etc. What, exactly, is
HI/HACK doing to the _routing_ state of ARnew?

 > to avoid doing DAD.  That's useful.  

Fine, but why ought that not just be input
to the seamoby/context transfer? There are a *lot*
of other things than DAD that are required to 
effect a fast/smooth handoff in reality. 

Besides, I thought it was MN that did DAD? How
can AR know the difference between two different
MN's that have the same lower 64 bits?

 > The new AR provides
 > avoidance is going to work. 

Again, there's a lot more than DAD which figure 
into "work" vs. "not work".

 > I'm not sure about what you
 > meant in the last sentence.  

It means exactly what it says: ARnew's job is just
to forward packets; it's not like it needs to
terminate a tunnel or something. Any state which
is a pre-condition to forwarding seems squarely
within the problem that seamoby/context transfer
is supposed to solve.

 > I also do NOT believe that we

I didn't say anything about a tunnel from ARnew
to anything.

 > circumstances the admission control policy is trivial.

And in many cases it's complex. I don't see this
as a reason to gratuitously come up with a
protocol to solve that narrow problem.

 > Without HI/HAck, there is no fast handover protocol.

How so? Assuming can MN get the new subnet in a
reasonable period of time, it can cons up its
address and do parallel DAD as the draft suggests.
What, exactly, prevents ARnew forwarding packets
to MN? 

 > polite a way as possible.  Now, where is my cane?

Without the rest of context transfer, HI/HACK is
inadequate in a large enough set of cases that
SEAMOBY became a WG to set about finding a
generalized mechanism to deal with the rest of
those things that are necessary to perform
fast/smooth handoffs. 

		      Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 3 Feb 2001 17:39:18 -0800 (PST)

Charlie Perkins writes:
 > >                                       As it stands now, MIP
 > Well, this statement wrong (and perhaps even
 > offensive) on several counts:
 > - We only have a draft, not a decision
 > - We are only a design team, not the working group
 > - Your (polite) inputs are welcome, and could
 >    change the design

   Fine. Since (polite) is in the eye of the
   beholder, I'll just state my objections.
   Consider this as input that I think that
   MIP should not be defining a transport protocol
   between AR's which has nothing to do with
   routing. 

 > This is also wrong.
 > We don't move CoAs.
 > We don't move DAD state.

   You're splitting hairs. You're transporting the knowledge
   of whether DAD would fail on ARnew. You're also transporting
   Old CoA, New CoA, HomeAddress and L2 address in HI, and
   new CoA in HACK. I don't see how you can rationalize that
   Old, HomeAddress and L2 are not state knowledge that ARold
   possess that ARnew doesn't. 

 > The old AR sets up a route to the new AR by using
 > HI.  The new AR tells the old AR how to determine
 > some details about its route table entry for the
 > mobile node by using the HAck.

   Wait a minute: I thought that the tunnel between
   ARold and MN was no different than the tunnel
   between HA and MN. That is, ARnew is no different
   than any other router that might be in the
   path between ARold and MN. ARold only needs to
   consult its existing FIB to determine where to
   forward the tunneled packets.

 > Please say what they are.

   AAA state, QoS state, etc, etc. Regardless I
   think the burden is still on the design team to 
   justify why ARnew needs to be involved in the
   fast handoff in way that is related to routing. 
   Thus far haven't seen any reason which holds
   any more weight than the things I just mentioned.

 > Which AR?  Two mobile node's cannot have the same
 > care-of address, nor the same link-local address.
 > If the new AR finds out that a new mobile node is
 > trying to use a care-of address that is already spoken
 > for, then it should return an error in the HAck message.

   The only way that ARnew can tell that MN is trying
   to use an already spoken for address is to
   *transmit*. ARnew cannot know whether a receive
   only MN (perhaps because it hasn't arrived) is
   a duplicate. If a MN configures a duplicate
   address and sends a fast handoff BU to ARold,
   the only thing that will happen is that ARnew
   will forward the packets arriving to the wrong
   MN. C'est la guerre.

   This is a reasonable thing to counter
   with some communication between the two AR's,
   but I don't see it as a reason for MIP to 
   design a handoff transport protocol in addition
   to whatever SEAMOBY comes up with.

 > If it's for routing, then I hope we didn't miss it.

   My point, such as it is, is that what you've
   got in there is *not* routing, per se. It's
   pre-configuration of ARnew which is, I thought,
   what SEAMOBY was supposed to deal with.

 > The point is to do handovers as fast as possible.  There are
 > many scenarios under which signaling between the mobile node
 > and the new AR is not possible.  We reckon that signaling
 > between the old AR and the new AR is always possible.
 > In fact, we basically relegate to base Mobile IPv6 all
 > scenarios under which the first signaling to/from the mobile
 > node occurs at the new AR.  Only when the old AR can
 > help, can handovers be "faster" than base Mobile IPv6.

   Even if what you're thinking of is the MAP
   stuff here, I don't see how that resolves 
   the conflict between SEAMOBY and MIP's
   charter. In fact, I don't see how ARnew's
   reachability by MN for signaling changes
   anything at all in any case.

 > A mobile node cannot receive packets on the new subnet
 > at its new care-of address until DAD is done.  That could
 > take a while.  Even with short-cuts, we would need a
 > retransmission algorithm, and we would be introducing
 > additional traffic between entities at a bad time.

   Yet, section 5.1 suggests that the MN does DAD
   in parallel while using the address anyway
   which seems eminently reasonable to me.

 > I guess we tend to disagree on this point.  In fact, to me
 > it is clear that context transfer operations are specifically
 > useful only when the context(s) exist.  It is also clear that,
 > for all values of context that I am aware of, useful systems
 > can be built that use none of them. 

   All you're really saying is that sometimes less
   context needs to be transfered than other
   times. Fine. I don't see that as a reason to
   I either Shanghai SEAMOBY into using HI/HACK
   as the transport vessel for context, or end
   up with yet another protocol mechanism if 
   that is not agreeable.

 > In other words,
 > vanilla fast handover is useful, contrary to your assertion.

   I've never said that. I said it's not adequate
   for fast handoff in large set of cases. Namely,
   oh say, where a service provider such as, oh
   say, a cellular provider, needs AAA to happen
   first before access is granted on ARnew, etc, etc.
 
 > You still didn't say what's wrong with HI/HAck.

   See above.

		Mike

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 03 Feb 2001 16:21:48 -0800

Hello again,

> didn't feel like working on.

You ought to ask the area directors about this.  I agree
that context transfer is important during fast handovers,
and nevertheless I also agree that a division of labor is
possible and perhaps even desirable.  However, the
desirability will depend on the results.

Well, this statement wrong (and perhaps even
offensive) on several counts:
- We only have a draft, not a decision
- We are only a design team, not the working group
- Your (polite) inputs are welcome, and could
   change the design
- A (?narrow, ?circumscribed, ?focussed, ?practical)
   world view does sometimes help to get things done.
- There is a hell of a lot of work to do besides just
   bits and dregs.  If you think otherwise, then please
   produce the "dregs draft" to show how easy it is.

This is also wrong.

We don't move CoAs.

We don't move DAD state.

Is there some particular thing that can be explained
better so that communication will be possible?

If it's for routing, then I hope we didn't miss it.
If it's for context, then I hope that [seamboby]
won't miss it.  Maybe QoS is context, or maybe
it's network-layer, but I reckon that there is so far
some tacit agreement to treat it as context.

If you suggest that additional errors should be defined
for the HAck message, I'm sure people will be willing
to believe you.  I can imagine errors to the effect
that admission control has failed, or that resources are
unavailable for particular QoS contexts.

> within the problem that seamoby/context transfer

Then I agree with both of your clarifications, and
do not see any contradiction to HI/HAck.

> I didn't say anything about a tunnel from ARnew

You are right.  You said something about a tunnel from ARold
to the mobile node, and I reached the wrong conclusion.

> protocol to solve that narrow problem.

Of course we didn't come up with such a protocol, gratuitous
or otherwise.  That would be the work of [seamoby-context],
presumably.

There are a lot of details.

can be built that use none of them.  In other words,

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 03 Feb 2001 18:05:47 -0800

Hello again,

>    between AR's which has nothing to do with

The matter seems to be that you don't accept our
work as a routing protocol, and yet I think it very
clearly is.  Maybe that's the point worth elaborating,
and I'll do so by inserting commentary below.

>    of whether DAD would fail on ARnew.

Only ARnew can determine that, and it matters to ARold
because of the need to determine the destination IP address
of the outer tunnel.

That's routing.  That's NOT transporting DAD state.  I think
this is obvious.

>                   You're also transporting

Well, in my route tables the IP address and the L2 address are
the information that is important.  Routing is stateful.  That's
obvious,
so calling something "state" does not insert it into the exclusive realm

of [seamoby-context].  I could make a better definition of "context"
that would distinguish [seamoby-context] from routing, but evidence
indicates that my effort would be about as useful to you as a burp
in a scuba-diving suit

We do not transport HomeAddress, that was fixed.

>    forward the tunneled packets.

We don't define FIB, and we never compared the tunnel
between ARold and MN to that between the HA and MN.
However, I don't see why you are insisting that they are
different.  The new draft will be much clearer in this matter.

>    AAA state, QoS state, etc, etc.

AAA state and QoS state are required sometimes.
I'm still not getting your point, though, unless you are saying
that no solution is worth anything unless it solves everything
all at once.

>                                    Regardless I

How about if we involve ARnew it makes things faster?
That's good enough for me, and it works.

>    *transmit*.

This assumption is not universally valid.  A router has
a neighbor cache.  That cache has useful information for
the determination we are discussing.

>         ARnew cannot know whether a receive

This is not one of the scenarios we consider in the
draft.  I'm not sure how it is relevant to the current
discussion.  I could try to make it relevant by imagining
further uses for HI/HAck, but that doesn't seem to
help advance the discussion.

>    to whatever SEAMOBY comes up with.

O.K.  I'm lost.

Regarding your last sentence, I think it's obvious that the
two efforts should be coordinated.  I think it's also obvious
that each bit of context is useful in fewer cases than the
overall fast handover will be useful.  Thus, waiting for
[seamoby] to design particular context transfer mechanisms
for particular bits of to context, before doing fast handover,
would seem weird to me.  Or, what were you proposing?

>    what SEAMOBY was supposed to deal with.

It's preconfiguration of the _routing tables_ on ARnew.
That's not what [seamoby] is supposed to deal with.

>    anything at all in any case.

MAP didn't cross my mind when I wrote the above paragraph.
I don't know what to say to make it clearer.  I reread the paragraph,
and it says exactly that the fast handovers have only been designed
for the case where the old AR can help speed the handover.
That's what I think we _were_ supposed to do, and (again) I
I thought that if the old AR can't help, then Mobile IPv6 was
deemed to be sort-of good enough.  Modulo context transfer,
that is, which is what we were not supposed to be doing.

>    up with yet another protocol mechanism if

Instead of railroading something, why don't you have
a discussion about what's needed?  You have a tool
at your disposal.  You can sharpen it, use it as it is,
or discard it as unworthy.  There's a lot of people
around who would like to help.

>    first before access is granted on ARnew, etc, etc.

So we agree that vanilla fast handover is useful.  I point out
that is what we intended to design.  You say it's not good enough
for many cases.  I hope to eventually see you point out the
insufficiencies.

>  > You still didn't say what's wrong with HI/HAck.

I sure have been looking hard.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 4 Feb 2001 13:53:10 -0800 (PST)

> That's routing.  That's NOT transporting DAD state.  I think

   Well, I don't think it's obvious at all.

 > of [seamoby-context].

   By this definition, DHCP is a routing problem too.

 > different.  The new draft will be much clearer in this matter.

   Please read what I actually write. This is the
   second time that you've misconstrued something
   that was not mistated.

   And I still don't understand your previous comment
   about "old AR sets up a route to the new AR". It
   is my understanding that the new AR is just a
   router like any other router in the path between
   MN and ARold; that there is no reason to change
   ARold's routing tables at all. Did you
   misspeak, or is there something that I'm not
   understanding?
 
 > that no solution is worth anything unless it solves everything

   No, I'm saying that I don't understand what
   modularity is buying in this particular case,
   and indeed, it may have significant downside.

 > That's good enough for me, and it works.

   Great. If we do context transfer, it will be
   faster still. Whether we think this was a 
   great split or not, the AD's decided to 
   partition the problem this way. All I'm asking
   is that we not end up with a bifurcation
   because MIP WG (or their design team) could
   rationalize *some* of the needed state transfer
   within the MIP context.

 > would seem weird to me.  

   Can Destination Options be encrypted using ESP?
   I was under the impression from the last IETF
   that the answer was no (which I confess to
   still not understanding the reason why). If so,
   by coding MIP's needs as a destination option, 
   you have either forced a new protocol for
   context transfer to be devised, or made the job
   doing a context transfer harder by requiring it
   to needlessly devise an application layer
   encryption scheme.

 > Or, what were you proposing?

   I'm proposing that MIP deliver its requirements
   to SEAMOBY context transfer and then a suitable
   protocol can be devised that meets all of the
   requirements.

 > That's not what [seamoby] is supposed to deal with.

   Again, then DHCP is a routing protocol too. It
   delivers static routes to hosts, and some
   routers use the MAC/IP data going by to build
   proxy ARP tables, blah blah blah.

   You think this is cut and dry. I don't.

 > around who would like to help.

   Um, the same can be said in reverse. Why are
   you so disagreable to the notion of letting
   SEAMOBY deal with the MIP context requirements?
   Why is MIP any different than, say, RSVP,
   Diffserv, AAA, RAP, IPsec, etc that need to
   have state and/or coordination with ARnew to
   achieve fast/smooth handoff? 

 > for many cases.  I hope to eventually see you point out the

    Right, but I think you can achieve vanilla
    fast handoff without needing to create the
    HI/HACK messages. Since SEAMOBY will be right
    behind with the CT work which could
    incorporate the shortcomings of "vanilla"
    (as if there were, IMO :-), I don't see this
    as risking an orphaned problem.

		Mike

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 04 Feb 2001 15:15:44 -0800

Hello Michael,

>    By this definition, DHCP is a routing problem too.

You use DHCP as an example related to determining
whether MAC address usage distinguishes routing protocols
from other protocols.  We perhaps do agree that DHCP is not
a routing protocol, and yet DHCP relays use the MAC address
for routing purposes.

I claim that this example is the exception that proves the rule,
because DHCP relays have no other choice in this matter.
Things are, of course, a lot better in IPv6 because there are
link-local addresses available for use.

Mobile IPv4 struggled with this problem, exactly because of
the effects of MAC address resolution.  While ARP is also
not a routing protocol, routing is much more difficult without
something like it.  Furthermore, ARP and DHCP are not
application protocols, and they are not context transfer
protocols.

Thus, I think that using the example of DHCP detracts from
the validity of your argument in a very substantial way.

>    second time that you've misconstrued something

In order to avoid parsing hairs, I'll let this drop, since I gather
you do not disagree with my statements even if they were
incorrectly motivated.

>    misspeak, or is there something that I'm not

Well, I meant exactly that.  Routers typically set up routes
for particular (hosts-or-prefixes), and in this case the old router
sets up a route for (destination == mobile node) that uses
(next intermediate point == new access router).  That is
what I think I said, and I don't know if it was said in a way
that was understandable to you.  I believed that we were
discussing ways to route packets to a mobile node undergoing
handover.

>    and indeed, it may have significant downside.

O.K.  I claim that modularity is crucial for the overall design.
Perhaps you will eventually come to the same conclusion.
So far, in our implementation, there hasn't been any
downside except possibly the need for a few more
bytes of memory in certain framework data structures.

>    faster still.

That's specfically assuming that there is context to
transfer, and that the context is in place for the purposes
of performance enhancements that are relevant to
handovers.

>    still not understanding the reason why).

Here, we are entering the realm where few mortals
dare to tread.  I _think_, speaking as an avowed mortal,
that the IESG suggests that "tunnel mode" with ESP is
the right way to handle encrypting destination options.
In order to get away from that, you have to have a payload
in a "higher order protocol".  That could be an ICMP
payload, I believe, but more typically is a TCP or UDP
payload.  Please don't shoot me if I am wrong about this.

>    protocol can be devised that meets all of the

This is a very clear statement, and thanks.  I reckon
that you'll have a hard time convincing the [mobile-ip]
working group to delegate that charter item, though.

>    proxy ARP tables, blah blah blah.

That blah blah blah is what routers do, and as I pointed
out at the start of this note, it is an unfortunate (and very
confrontational) part of DHCP that they had to mess with
this.  It has had continuing bad effects on other protocols.
For instance, it's not perfectly clear how a mobile node
should get its home agent to use DHCP for home address
allocation, although people have done it in several different
ways.

>    SEAMOBY deal with the MIP context requirements?

Actually, I am quite agreeable to exactly that mode of
operation.  However, Mobile IP doesn't have very much
context requirement, as best I understand it.

>    achieve fast/smooth handoff?

A good thing would be to identify and coalesce all the
common needs.  Why don't we make that our roadmap?

>     as risking an orphaned problem.

My experience from the design team effort is that it's easier
said than done, but even so I'll be very happy to see what you
can come up with.  We do not say our approach has no
shortcomings.  In fact, I could rattle off a few right away, but
this is the wrong mailing list for it.  I only claim that it is a very
good approach that does what it is supposed to do without
getting in your way.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 4 Feb 2001 16:29:38 -0800 (PST)

> discussing ways to route packets to a mobile node undergoing

   I'm still confused, so maybe I should be pedantic
   to make certain we're communicating here:

   Suppose that my home address is 11.12.13.14 and
   my current attachment point is 100.1.1.1, my
   next attachment point is 100.1.2.1. When I send
   a BU to the old AR to create a tunnel to my
   new care of address at 100.1.2.1, the format
   of the IP packets from the old AR will be:

   IPHdr: D:100.1.2.1 [D:11.12.13.14 ...]

   Correct? As such, _ARnew_ doesn't need to do anything
   extraordinary to route the tunneled packet to MN
   since from its perspective it's just an ordinary
   IP datagram that is reachable via whichever interface
   100.1.2.0 points to. Correct?

   Thus, I don't understand what new routing state
   needs to be set up on ARnew: it's already there.
   What you seem to be implying above is that the tunnel
   endpoint is on ARnew instead of MN in which case
   I could understand why ARnew's routing tables 
   need to be updated, but that's not what you 
   mean is it?

 > bytes of memory in certain framework data structures.
  
   The downside I see is that if there needs to be
   two different messages exchanged between the AR's
   it may be pertinent to the overall latency of
   the handoff. I'm certainly open to modularity
   arguments -- I have no love for protocol
   reinvention -- but in this case, it seems that
   combining the two needs into one would not
   raise the modularity spectre. Since you don't
   seem to disagree with that -- since it was an
   explicit desire to be able to use HI/HACK for
   CT if appropriate -- our argument is only in
   who should choose the appropriate transport
   vessel for the goodies. I think it would be
   better to defer that decision and let SEAMOBY
   decide which is best for both in light of the
   full set of requirements.

 > the right way to handle encrypting destination options.

   Bletch.

 > payload.  Please don't shoot me if I am wrong about this.

   Right. Another reason to use a higher level
   protocol -- especially here  -- is that
   we avoid playing the Stump Bellovin game :-)

 > common needs.  Why don't we make that our roadmap?

   Yes, let's do.

	      Mike

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 03 Feb 2001 18:05:47 -0800

Hello again,

O.K.  I'm lost.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 3 Feb 2001 15:41:57 -0800 (PST)

Mike

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 03 Feb 2001 14:40:13 -0800

Hello,

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 3 Feb 2001 17:39:18 -0800 (PST)

See above.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 3 Feb 2001 12:17:46 -0800 (PST)

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 4 Feb 2001 13:53:10 -0800 (PST)

Mike

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 03 Feb 2001 16:21:48 -0800

Hello again,

This is also wrong.

We don't move CoAs.

We don't move DAD state.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 04 Feb 2001 19:55:07 -0800

Hello again,

>    IPHdr: D:100.1.2.1 [D:11.12.13.14 ...]

Check.

>    100.1.2.0 points to. Correct?

Check.

>    needs to be set up on ARnew: it's already there.

No, what needs to be set up is that ARnew needs
to know the MAC address for the mobile node, and
ARnew needs to confirm that 100.1.2.0 is not already
in use by some other mobile node.

>    need to be updated, but that's not what you

No, the tunnel endpoint is MN as you originally thought.
However, in order for MN to actually use its new care-of
address without suffering the rigors of DAD and ND,
special arrangements have to be made at ARnew, and
the logical seat of authority for those arrangements is
ARold.

>                  ...         our argument is only in

On the other hand, other people do not feel this way.
Nothing has been set into stone, although I think that
the design team has a good design.  If after due
consideration it turns out to be incompatible with
whatever [seamoby-context] decides has to be done
simultaneously with HI/HAck, then why don't we fix
the problem then instead of going into paralysis mode
now?

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 5 Feb 2001 15:57:01 -0800 (PST)

> in use by some other mobile node.

   Why can't ARnew get the MAC address in the
   usual way? Ie, through ARP or ND? This only looks
   like an optimization of one round trip on the
   local media which is certainly not on the same
   order latency as what fast handoff is trying
   to counter.

   As for DAD, I sort of like the optimistic
   do-dad-in-parallel optimistic approach. Since
   we could easily put that in the SEAMOBY CT
   protocol, we could have it both ways
   eventually.

   Honestly, I really like the idea of keeping 
   fast handoffs localized just within MN and
   ARold. Involving ARnew adds more complexity
   to that which is otherwise a fairly clean
   mechanism. Context transfer -- as a router
   router mechanism -- explicitly says that you're
   willing to deal with all of the added
   complexity of moving stuff around (besides
   routes). It would be nice to have a mechanism
   which doesn't require that heft too. Fast
   handoff without HI/HACK fits that middle 
   ground, IMO.

 > the problem then instead of going into paralysis mode

   The problem is that it's impossible to tell you
   whether your transport vessel is a good one at
   this point. I was fairly certain that a
   destination option wasn't the right answer, but
   can't tell you whether ICMP is adequate and
   won't be able to tell you until the
   requirements are nailed down. Assuming you go
   forward with HI/HACK and they don't fit the
   requirements, you'll be somewhere around last
   call and we'll have a conflict if we want to
   combine the two (as I think they should be).

   And hence this entire thread.

	     Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 06 Feb 2001 07:34:38 -0800

Hello Mike,

>    order latency as what fast handoff is trying

Any such round trip comes equipped with retransmission
timers and failure conditions.  So, even if I agreed
with your premise (which I do not) I would still believe
it is highly advantageous to eliminate control messages
over the air.

Furthermore, we have to design a protocol that allows
access routers to work better even if they have
hundreds of thousands of attached mobile nodes.

I claim that eliminating this round trip that you
mention is more than worth the effort.  And I do not
see any downside.

>    protocol, we could have it both ways

One problem that has to be considered (according to
strict IPv6 design guidelines) is what to do if two
mobile nodes end up trying to use the same link-local
address.  DAD prevents that.  Any strategy deviating
from DAD has to also prevent that.  I believe that
the design team has achieved that goal, but the cost
is some signaling between access routers.  I'm not
sure what you mean about having it both ways.

>    handoff without HI/HACK fits that middle

You have made your opinion very clear!  There is a
tradeoff between signaling between routers and speed
of handovers.  I think it is clear that we can get
significantly faster and less error-prone handovers
by specifying a bit of signaling between routers.
You are trying to convince people otherwise.  Maybe
it's time to get a little field experience and compare
notes.

>    this point.

This is in the eye of the beholder.  I'm 95% sure that
it's a good one, and a number of highly qualified people
have been staring at it for months.  The design team
didn't get to this point accidentally after a wild
night of bar-hopping.  There has been a great deal of
serious design and engineering consideration going
into it.  That may not help you decide, but at least
you ought to recognize the effort and the possibility
for good.

>                       I was fairly certain that a

Unfortunately, your statement is tautologically true,
and hence somewhat unpersuasive.  One can _always_
take the viewpoint that some "other way" is better,
until the specification for that other way is able to
be inspected, constructed, and tested.  We've put out
something that can be inspected.  You do not find it
compelling, but as best I can tell mainly because you
view it as a design constraint on your own underspecified
problem space.  I'm not trying to put words in your mouth,
though, so if I have the wrong picture please set me
straight.  And, in the meantime, perhaps we can make
further engineering observations about how best to
proceed.

Regards,
Charlie P.

PS. I cut down the number of respondents.  I reckon if they
    care, by now they know where to find us.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 6 Feb 2001 10:30:43 -0800 (PST)

> hundreds of thousands of attached mobile nodes.

   It would be even more advantagous for the router 
   to do some mind reading. I'm sorry, but this is 
   completely unpersuasive. Fast handoff's job is 
   to come up with a way that deals with in-flight 
   data for the potentially long round trips to HA's 
   and CN's. It wasn't to explore every possible optimization 
   for the least common denominator. I, for one, think 
   it is a lousy idea for an 802.11 network which 
   has ample bandwidth and doesn't want to deal 
   with the administrative nonsense of having to 
   get adjacent routers to know and trust one 
   another. Yet the last draft I saw makes HI/HACK 
   MUST requirements. Bletch. 
 
 > hundreds of thousands of attached mobile nodes. 
 
   Please explain the scaling issue here. If a 
   router melts down because of a single round trip to
   do ARP/ND per node, it's got way bigger problems than
   the MIP WG can help with.
 
 > mention is more than worth the effort.  And I do not

   Sure there's downside: you're *requiring* network
   administrators to set up the provisioning and
   security between AR's. That is *hardly*
   inconsequential.

 > by specifying a bit of signaling between routers.

   _Significantly_? It sure looks like it's down
   several orders of magnitude to me. Like one
   round trip on the local interface vs. round
   trips across the world.

 > have been staring at it for months. 

   How can you say that when your design team just
   decided to switch to ICMP? How can you know
   that CT's requirements won't require a reliable
   datastream using, say, SCTP because context
   doesn't fit within an MTU and we need
   congestion avoidence?

   I think it's entirely premature to be spouting
   95% confidence levels.

 > The design team
 > night of bar-hopping.

   Yes, but does it pass the Turing Test?

	    Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 06 Feb 2001 10:57:44 -0800

Hello,

>    completely unpersuasive.

I didn't think I said anything so horrid as to evoke mockery.

>                           Fast handoff's job is
>    for the least common denominator.

In the first place, Mobile IPv6 already offers a way for
 a mobile node to connect the dots between its previous
and new access routers.  In the second place, it doesn't
have to be limited to "in-flight" data.  You don't have any
need nor grounds to make the accusation implicit in that
second sentence.

>                                  I, for one, think

They are requirements for routers that implement the
protocol.  They are not requirements for routers that
do not implement the protocol.  I guess that we're
doomed to be receptacles for Thomas-Bletch for
the foreseeable future.  I, for one, think it's a lousy
idea to carry on an argument when I'm doomed to
be Bletched-on, but I'll do it anyway for a short while
longer.

>    the MIP WG can help with.

A problem here, a problem there, and sooner or later you
really have a problem.

>    security between AR's. That is *hardly*

We decided not to design the inter-router discovery
protocol, since the fast handover part could be done
separately and more quickly.

>    round trip on the local interface vs. round

Compared to what?  The mobile node, using our
protocol, should be able to get on the air immediately
upon connecting to a new access router.  We avoid
DAD and ND, under typical circumstances.  Avoiding
the routing trip across the world is already available
using Mobile IPv6, given appropriate security.

>    doesn't fit within an MTU and we need

Switching to ICMP didn't alter the basic control flow.
We could still switch back if need be.  We could still
switch to UDP if need be.  Nobody claimed infallibility,
nor intransigence, as you seem to imply.  And, I
stand by my statement.

>    I think it's entirely premature to be spouting

O.K., a clarification: I am 100% confident that the
design is not finished.  I am 95% confident that the
design is good.  Well, maybe 92%.  I lost my black
and white crayons.

>    Yes, but does it pass the Turing Test?

Please explain to me how that is going to move us
towards any beneficial resolution to the questions you
have raised.

Charlie P.