Subject: Re: [mobile-ip] FMIPv6 Address confusion

From: Rajeev Koodli <[email-masked]>
Date: Wed, 25 Jun 2003 17:11:35 -0700

Hesham,

my general comments are that

- I do not see HI/Hack as optional for the
scenario when MN is able to  send FBU from old
link ("predictive"). The NAR needs to not do ND,
and send Dest Unreachable, until MN shows up on
new link.

- I do not see how a router can create an ND cache entry,
when there isn't one, using a 2461 unsolicited NA. I might even say
you agree that at least a flag is needed to distinguish. This is
FNA.

So, I am unable to see how we can make HI-HAck and
FNA optional when optDAD is in use.

Some more comments below.

Soliman Hesham wrote:

>
> On a high level, FMIPv6 handles 2 types of handovers:
>  1. Predictive
>  2. Reactive
>

Yes.

>
> 1. In the predictive case, the assumption here is
> that the MN sent the BU to the PAR before moving. Since OptDAD
> is used, the MN would have included its NCOA in the BU.
>

MN should include NCoA in any case.. Anyway, Ok.

> Therefore, when it arrives at the new link, assuming
> that it has active sessions, traffic will be waiting
> at the NAR. Typically, the L2 handover (break before
>

If you are using standard ND, why would traffic wait at
NAR ? If no one answers NS, NAR sends Dest Unreachable
isn't it ?

> make) will take longer than the path between PAR and
> NAR. Therefore, the NAR would have already sent an
> NS (address resolution) for the MN's NCOA before it arrived and
> will create a cache entry in INCOMPLETE state. If the MN sends
>

Since the L2 handover delay takes longer wrt to path delay
between PAR and NAR, the MN would not be there to answer
NAR's NS. So, why would it create the ND entry ?

> an unsolicited NA as soon as the link is up, it will
> create a Neighbour cache entry (for the NCOA) and traffic
> will be forwarded.
> In this scenario, I can't see any advantages for
> having HI/ack FNA/ack

First, there is no dependency on L2 handover timing versus
path delay between PAR and NAR. This means, NAR does
not invoke NS as soon as packets arrive; doing so when the MN has
not attached to NAR could result in Dest Unreachable sent back
to PAR.

Second, you don't require ND queue to be larger. Only the
FMIP buffer needs to be bigger.

Third, NAR proxies NCoA in case some node tries
to capture it.

I would argue that all of above (except for buffering) comes with
"proxying the address" capability, something available from standard
HA functionality.

Finally, there is no Ack for FNA proposed. Only NAck, when
there _is_ conflict is proposed.

>
>
> How long is the queue? How large is the buffer in the
> current draft? Implemnentation issues. RFC 2461 makes
> no requirements here.

Queue size is one issue. Why should NAR buffer instead
of replying with Dest Unreachable, a standard 2461 behavior,
is the primary issue.

>
>
> In this scenario, there is no change in the NAR. Standard
> 2461.
>

Proxying an address, standard HA feature, plus buffering is
what is needed otherwise.

>
> 2. The reactive case can be broken down into two
>    subcases:
>       a. MN received Pradv before moving
>       b. MN didn't receive Pradv before moving
>
> a. In this case, the MN could send the BU right after
> it connects to the new link. Of course this is done
> after configuring an address with OptDAD. The normal traffic flow
> will force the NAR to do address resolution as usual.
> Again, standard 2461 stuff.
>

So, here NAR would do NS and NA when packets arrive. Since
FMIPv6 is an optimization, we can save this round-trip, and I
don't believe that the cost (i.e., FNA) is unreasonable.

>
> b. In this case, the MN needs to solicit for an RA
> anyway, after configuring an address using OptDAD.
> So again, this is standard 2461 stuff.
>

Currently, FMIPv6 assumes that MN knows of NAR's
co-ordinates before attaching. May be we should mention
this as well.

>
> Now, the benefits of the above method is the obvious
> elimination of unnecessary signalling to cater for
> the extremely rare case of address collision.
>

This is too broad and partially accurate a statement.

- HI and HAck are necessary, IMO, not for avoiding
address collsion. But, to not send Dest Unreachable
and to buffer packets. A side effect is that NAR also
defends NCoA in case some node tries to configure it.

- FNA is not meant for address conflict resolution. It serves to move
an existing entry to REACHABLE state when MN has not
received FBack but has sent FBU (so NAR has a proxy entry).
And, it helps to create an entry unambiguously when
there is not one (reactive scenario). In the process of creating
a new entry (during the reactive case), the router also checks
if it has any pre-existing entry. To that extent, it is doing
any address collision detection.

>
> If something above is unclear please let me know.
>

Hope above is useful.

> But please don't tell me "The DNA BoF handles OptDAD"
> or "OptDAD is not an RFC". I'm only interested in having
> a technical discussion.
>

I have heard that this discussion has been "too technical" :-)

>
> Finally, note that I did not suggest more than:
>
> Include statements that make it clear that the use
> of OptDAD (or your favourite word for optimal
> addr conf) would mean that these messages are optional.
>

Unfortunately, I am not convinced..

-Rajeev

> Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Thu, 26 Jun 2003 21:52:03 -0400

=> First of all there should be no retransmission. It sends
it once.
Because it's simpler: Avoids implementing HI/ack, NA/NAck.
And the cost is negligible.

And I've already mentioned other cases where DAD is not
used on other link layers. This alone is sufficient
to make these messages optional.

Hesham