Subject: [mobile-ip] MIPv6 Fast HO DT concluded

From: [email-masked]
Date: Wed, 2 May 2001 13:43:58 -0500

Hello,

The Mobile IPv6 fast handoff design team has now been shut down. All future
work
related to fast handoff for MIPv6 will be carried out in the Mobile IP WG
discussion
list. A new version of the I-D has been announced
(draft-ietf-mobileip-fast-mipv6-01.txt).
Please provide comments and feedback via the mailing list or to the editor.

The archives of the discussion list used by the design team will be made
available
shortly.

-Basavaraj

---

From: Michael Thomas <[email-masked]>
Date: Thu, 3 May 2001 17:50:36 -0700 (PDT)

1) This generally needs a pass at spelling and de-Frenchifying
   George's grammar :-)

2) It appears that the mobile node gates the flow of packets
   toward its new attachment point in the tunnel by issuing
   the Fast BU. Further, it looks like the new AR is supposed
   to buffer packets in flight toward MN until it receives
   a Fast Neighbor Advertisement.

   Why can't the OldAR do the buffering and not involve the
   NewAR at all? Ie:

   MN->ARold: I'm moving to ARnew, please buffer until I'm done (ie RS)
   ARold->MN: OK, here's the new prefix (ie, RA)

   [attaches to ARnew in whatever way is appropriate]

   MN->ARold: I'm here, start sending (ie, BU)
   ARold->MN: OK, here they come (BU_ACK)

   The advantage here is that the NewAR doesn't have
   to be involved, nor do we need any new neighbor
   advertisement (ie, F-NA).

3) As I've said before, it would be nice to decouple 
   the need to do the HI/HACK from the rest of this
   draft. The mobile node should be able to just 
   ask the old access router to buffer its packets
   while it's in transition. In fact, this has the
   positive side effect if the oldAR doesn't know
   anything about the newAR, the mobile node can
   still register on the newAR as if it were just
   booting up, and when it's ready, send the BU
   to the oldAR to start flowing the buffered 
   packets. Another benefit is that if, for some
   reason, the MN can't attach to the ARnew, it
   can abandon the handoff and still get the 
   buffers from ARold (assuming it is still 
   in range, but if not you're really hosed
   anyway).

4) I don't think anything prevents the MN from
   going through normal DAD procedures on the
   new AR. If we eliminate the need for the newAR
   to do the buffering, we can make the HI/HACK
   completely optional.

5) Is the FBU/FBACK really a different kind of BU?
   It looks the same as a normal BU. That would 
   actually be rather nice if it were the same
   since we're probably need to consider the
   security aspects of them, and it would be nice
   to have exactly one kind of BU to modify if
   necessary. Same goes for HMIP as well.

Probably enough for now