[Mipshop] Questions about implementation of FMIPv6

Hello folks

Recently I implemented FMIPv6 based on mipv6-1.0-v2.4.22 according to 
draft-ietf-mipshop-fast-mipv6-02.txt. From the sight of implementation, 
I hope the following trivial changes be made to the draft:

1. In the draft, FNA is a mobility header message, but I think a ICMPv6 
message is better. Because FNA MUST contain the link-layer address of 
the MN, but no one mobility option defined in rfc3775 can hold 
link-layer address. The LLA option defined in the draft is a ICMPv6 
message option, isn't it? And FNA may encapsulate FBU, it will be 
easier implemented if FNA is a ICMPv6 message. 

2. In the draft, when NAR receive FNA, if NCoA is not valid, NAR will 
send out RA containing NAACK option. I think a new ICMPv6 message 
should be defined as the acknowledgement to FNA, and whether the NCoA 
is valid or not, the acknowledgement should be sent out. Because RA is 
sent out by a user space daemon program (radvd), not kernel protocol, 
so it is not suitable to act as the acknowledgement to FNA. Considering 
FNA may be lost because of the unstable signal strength, an acknowledge 
to FNA is always needed. 

3. In the section 5.5 of the draft, it said that:
   "IP layer mobility, however, introduces its own limits.  IP layer
   handovers should occur at a rate suitable for the MN to update the
   binding of, at least, its HA and preferably that of every CN with
   which it is in communication.  A MN that moves faster than necessary
   for this signaling to complete, which may be of the order of few
   seconds, may start losing packets."
If MN moves too fast, handover may involve 3 (or more) AR: MN moves from 
AR1 to AR2, then to AR3. So in the short time that MN connected with 
AR2, if MN completed the update the binding, should AR2 be the PAR in 
the handover from AR2 to AR3? It seems that the author bypass this 
question, but I think it should be answered here..

4. The draft not clarify when fast handover should transit to normal 
handover, i.e, after MN received FBACK from PAR, when should it begin 
update bindings?  I think it is better to wait several seconds, if we 
take into account the ping-pong movement.  

5. When should PAR begin forward using tunnel? I think, if PAR received 
FBU from new link (reactive fast handover), then it should immediately 
begin forward after received HACK from NAR, but if it received FBU from 
old link (predictive fast handover), should it wait until MN disconnect 
with it? 

Sincerely yours,
Y.C. Peng

_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop