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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sun, 4 Feb 2001 19:05:57 +0100

Hello, 

First of all I'd like to state that there is a new draft that will 
appear in a couple of days, this draft is much clearer and 
hopefully it will explain a bit more what we're trying to 
achieve. The draft will however still contain the HI/Ack messages
hence this email. 
Now, let me try to explain why these messages exist and see 
if we can get some feedback. I hope we can keep this discussion
constructive.

IPv6 allows the MNs to get a new COA when attaching to the new
AR, however this requires DAD. DAD can take up to 2 seconds. If 
you strictly folow RFC 2462, then the MN can not receive or send 
packets during that period. Not very fast is it !
The draft is based on anticipation, the MN anticipates its new COA
and sends BUs based on that anticipated address. 

So we had to work around RFC 2462: 

- If the new AR has knowledge of all MNs connected to it, then this 
knowledge can be used to immediately know whether the MN's 
address is valid or not. This would require a request-reply message 
from the old AR to the new one. 

The option of doing DAD in parallel was there but in view
of the new approach (coming out in the new draft) it may not 
be needed. 

Now we are solving the routing part of the problem. No new
COA means no routing. Obviously CT is still needed for a more
complete solution. 
We had two possible options for sending this
request-reply messages. Dest options or ICMP. After a long 
debate we thought ICMP is more appropriate since it allows 
for future extensions and MAY also be used by the CT team. 

Now if that is a bad solution then we can always revert to
destination options and leave the door open for highler level
protocols for CT. But we need to know why it's bad and why
CT will be done differently. So far we haven't heard any reasons
because the work of the CT team is not done yet. So nothing 
is set in stone. 

As far as I'm aware no one was trying to "take over" the context
transfer work. So I don't see any need for being concerned about 
that. 
I hope we can cooperate in this area as it is obviously 
needed by both WGs. 

Hesham

---

From: Michael Thomas <[email-masked]>
Date: Sun, 4 Feb 2001 14:04:36 -0800 (PST)

> for future extensions and MAY also be used by the CT team. 

   Well, I'm glad to hear that you ditched the
   Destination Option, but as far as whether ICMP
   is the right method, I think it's far to early
   to guess. A few questions come immediately to
   mind:

   1) Do we need congestion avoidance?
   2) Do we need > MAX MTU contexts?
   3) What are the security requirements?
   
 > protocols for CT.

   Or you could feed the requirements to SEAMOBY
   and have a single solution. #1 above is almost
   certainly going to have some AD shaking their
   head "yes" and I don't see why MIP's can ignore
   it either.

	    Mike