Subject: RE: [mobile-ip] FMIPv6: FBU transmission text

From: Soliman Hesham <[email-masked]>
Date: Fri, 20 Jun 2003 23:30:47 -0400

> > A simple and effective way of doing the anticipated
 > > handover is for the MN to generate a new CoA on the old
 > > link, send F-BU, move to the new link and send an NA
 > > with O=0. If there is any duplication, OptDAD would
 > > discover that. Note that there is zero changes on the
 > > wire here.
 > >
 > 
 > This is simple, but I am afraid we need to look a little
 > deeper.
 > 
 > a) Since FBack was not received, 

=> But why was it not received? This would
happen if it were only sent on the old link.
And again we talked about a trivial cure to
this that was in draft-00/1 and was then removed.
Send it to both links...Frankly, it's tiring how
many times this was mentioned, never discussed, never 
put in the draft....etc. 

      MN does not know if
 >     FBU was processed or not. So, it has to send FBU as
 >    soon as it connects to NAR.

=> It has to send an NA first. Again in most cases, 
messages are not lost over the wire. So if the 
message is sent to the old and new CoA, it's probably
waiting at the NAR to be sent.

 > b) If FBU was processed, and NAR is proxying the NCoA,
 >    then NA with O=0 will not override the proxy entry.

=> I don't understand this statement.

 > b) MN does not know if NCoA is okay.

=> Yet we all seem to think that it will
be Ok.

 > 
 > The text I sent addresses these. Essentially, it uses
 > a reformatted FNA (i.e., message 'M') with FBU as
 > encapsulation.

=> Ok. At this point we're going in circles. I
have nothing more to add :(

 > 
 > 
 > Here, the MN definitely knows FBU was not processed.
 > It also knows NAR does not have a ND cache entry for
 > NCoA. So, it sends M with FBU as encapsulation.

=> But you still refuse to let M be and existing NA?

 > > Note that I'm not saying that you should remove
 > > anything from the draft. I'm simply saying that
 > > there is no need to mandate the implementation of
 > > new messages all the time when their sole reason
 > > for existence is something that is not likely to happen
 > > at all.
 > >
 > 
 > There are no new messages.
 > I am only re-using FNA, and allowing FBU to be
 > sent encapsulated.

=> FNA _is_ a new message introduced by this draft!!

Hesham

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 23 Jun 2003 10:19:34 -0700

Hi Hesham,

couple of quick comments and more comments
in-line below.

- FNA has been around at least from version 04.
I was not the editor then :-) Sigh.. So, it is incorrect
to characterize it as a new message.

- I think any DAD optimization would work fine with
   this document. As Basavaraj Patil pointed out, this
   draft should progress on its own while not disallowing
   specs that might be standardized.

I am only trying to piece everything together and
wrap up the spec.

more comments..

> many times this was mentioned, never discussed, never

Even if you have sent it to both the links, unless NAR
has detected MN's presence, FBack is not received by the
MN. Besides, how do you ensure that FBack is not lost,
for instance due to overflow ?

> waiting at the NAR to be sent.

Right, it's probably waiting at NAR. BTW, it reminds me: for
that to happen, NAR has to proxy NCoA and buffer
packets, which is done by HI-HAck.
But, you don't need to wait for FBack to send packets using
NCoA.

> => I don't understand this statement.

How do you override a proxy ND entry ? Don't you need
an NA with O=1 ?

> => Yet we all seem to think that it will

That's something we _are_ trying to make use of.
But, the protocol itself has to work using some
well-defined steps.

> have nothing more to add :(

Sorry, I was hoping you would be able to provide some
feedback on the text.. It appears that it is still not fully
understood.

> => But you still refuse to let M be and existing NA?

I already replied to Greg on this..

- how does NAR distinguish between a vanilla NA and
   this NA ? In other words, why does it create a ND cache
   entry, if there is not one, for this NA. Why isn't there an
   ND cache entry ? Because, no FBU was sent on the old link.
   Nodes do not create ND cache entries for unsolicited NAs.

- You cannot encapsulate a packet in NA. Whys is this useful ?
    In the case NAr detects a conflict in its ND cache entry, it
    can drop the inner FBU packet. If the MN sends M and FBU
   separately, NAR has to have some state to capture FBU and
   drop it in order to avoid the result of collision.

> => FNA _is_ a new message introduced by this draft!!

No! FNA has been around. See Section 5.1.3 in version 04
for which I was not the editor.

-Rajeev