Subject: RE: [mobile-ip] I-D ACTION:draft-mccann-mobileip-80211fh-01.txt

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Mon, 11 Nov 2002 23:55:51 +0100

James,

  > > In the case where the MN doesn't anticipate the handover,
  > > we shouldn't rely on FBU/FBACK, since we're already in
  > > possession of an IP address in order to send the message
  > > to the oAR, and the oAR wasn't previously aware of our movement.
  > > This is the correct usage for BU to the oAR which
  > > was removed from MIPv6 base draft (issue 72).
  > >
  > > In the case where address acquisition optimizations aren't
  > > allowed and we haven't anticipated the handover...
  > > we don't know how often that will occur (so why optimize?).
  > >
  > 
  > Disagree. This is an architectural confusion between 
  > changing the routing id to
  > node id mapping and changing the routing for an existing, 
  > allocated address.
  > These are two different cases and they should be handled separately.

=> Mobile IPv6 deals with the change in the locator (IP address). 
There is no difference when this is between two visited
networks or a home network and a visited one. It's the 
same function. You choose to call the home address a "node id"
but it's still an interface id like any other IP address. 
Even if it identifies a virtual interface. 

Why should the two cases be treated separately?

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Tue, 12 Nov 2002 07:02:00 -0800

> Even if it identifies a virtual interface.

This is an implementation question, not an architectural question. In HIP, the
two are different from the start, in MIP, the node id just happens to also be a
routable IP address.

> Why should the two cases be treated separately?

Because treating them separately has certain tactical consequences.

If one considers movement to a new link without any prehandover L2 or L3
signaling to be a failure of routing that is detected by the MN rather than a
change in node id, then the solution should be to use some method to
re-establish the routing. The protocol should leverage the on-link routing
protocol, namely ND, not a protocol that is designed to manage the node id to
routing id binding, such as BU.

Mobile detection of the routing failure such as 802.11 exhibits leads to the
proposal I've made to use RS/RA to the new AR to start tunnel establishment
instead of F-BU. Now, the MN must do RS/RA anyway if no prehandover signaling is
available, since otherwise it does not have the L2 address of the router. Also,
if the MN wants to start configuring a CoA it must do RS/RA. Why add an
additional message on top of that afterwards? It just delays the tunnel
establishment.

In summary, I believe maintaining the proper architectural perspective can lead
to a protocol that more cleanly partitions functionality, has the potential to
be faster, and has better security properties.

            jak