Re: I-D ACTION:draft-hoon-mobileip-undad-00.txt

Hi

Thanks for your valuable feedback. At the onset let me clarify that the
intention behind releasing this draft was to propose the usage of the
Neighbour Cache (NC)for DAD related purposes. We believe that this approach
of maintaining the entire list of nodes in the link can help optimize DAD as
well as provide for future administrative and statistical purposes. I do
agree that the finer aspects of the proposal require much more work and I
hope that this working group will help us resolve some of the issues.

I hope to present some of my viewpoints below and I apologize if clubbing
them together has caused any inconvenience.

Ed had pointed out that the draft does not discuss any deregistration
mechanism for the Neighbour Cache Entry (NCE). There are different ways of
solving this issue I think.
- In cases where L2 triggers are available NUD can be performed to determine
if the NCE has to be removed on receiving a L2 trigger.This would however
require some form of mapping between the NCE and the L2 module.
- In cases where RA beaconing is used a periodic delay in RA message
transmission ( like 1 in 10 RAs sent can be delayed )can be used to receive
RS messages from the mobile nodes still connected to the link. NUD can be
performed for mobile nodes with a NCE in the access router and which do not
send RS messages. Partitioning the NC into static entries ( for non mobile
nodes ) and mobile entries would help minimize the overhead with NUD being
performed only on the mobile entries.
- Another option would be to inform the previous access router of its change
in attachment after the completion of the Binding process in order to remove
the NCE.

Greg  had pointed out problems with populating the NCE in cases where the
router boots after some of the nodes or when the router goes down and comes
up. Ed had suggested using a multicast ping for the purpose ... some
topological features can hamper its efficacy .. but the same can equally
apply to the normal DAD process. As RFC 2462 claims "Note that the method
for detecting duplicates is not completely reliable, and it is possible that
duplicate addresses will still exist." and the Optimistic DAD draft
reinforces in section 4.4 - the DAD procedure only provides a very good and
not a complete assurance that duplicates are absent.
In my opinion using the Ping process would not lead to a unacceptable risk
causing the DAD procedure to fail.

Another solution can be the partitioning of the NCE  into static entries and
mobile entries as I had stated earlier and having the static entries
administratively configured. That would overcome the problems when the
router boots up after some of the static nodes boot. Mobile nodes perform
DAD after the receipt of RA messages only and the router can handle those
cases. That would still leave the case where the router goes down and comes
up .... carrying forward the state information cannot be enforced in such
cases ... perhaps reconfiguring the addresses in the mobile nodes can be
used in such cases?

Eric and Greg had pointed out that when a node oscillates between networks
it will have to wait the mandatory 1000 ms before it can resume normal
communication and the draft does not offer any solution to it. In cases
where a L2 trigger is available to deregister the NCE this should not pose
any problems I think. Also in cases where a mechanism of informing the
previous router of its change in attachment is used the problem would not
exist. However when some periodic mechanism is used it can be problematic
when the oscillating time is less than deregistration time interval.

I hope the next version of the draft would discuss these issues in more
detail and I hope to hear from you about the viewpoints expressed above.

thanks and regards
Praveen


Optimistic DAD in section 4.4
----- Original Message ----- 
From: "Greg Daley" <[email protected]>
To: "jaehoon.kim" <[email protected]>
Cc: "Ed Remmell" <[email protected]>; <[email protected]>;
"'Youn-Hee Han'" <[email protected]>
Sent: Wednesday, October 22, 2003 10:19 AM
Subject: Re: [mobile-ip] I-D ACTION:draft-hoon-mobileip-undad-00.txt


> Hi Jaehoon and Ed,
>
> jaehoon.kim wrote:
> >>Jae-Hoon and Youn-Hee,
> >>
> >>I think there is another problem with this draft... the router doesn't
> >>know when a host leaves the link (i.e. due to link movement), therefore
> >>if the MN leaves link A to move to a new link B and then in some short
> >>time (i.e. 20 seconds or so) returns back to link A, the router will
> >>think that the MN never left link A, when the MN queries the router if
> >>its care-of address is already in use the router will respond that it
> >>is. This would cause the MN to fail to configure the care-of address it
> >>used before on link A.
> >>
> >>Thanks.
> >>- Ed
> >>
> >
> > Thank for your good comment.
> >
> > In this case, router have a NCE for CoA. So, router never reply to MN.
> > Refer to my draft.
> >
> >    3.2 AR's requirement
> >    -  Access router should reply to the sender which has sent NS message
> >       with the 'A' bit set in the 4th reserved field in NA if access
> >       router has no entry corresponding to the target address.
> >       =====================================
> >    4.1 Mobile node's operation
> >
>
> The time which was mentioned by Ed may be the relevant
> criteria (30 seconds is still within normal
> ND cache timeouts).
>
> If the router had an active neighbor cache entry
> for the host (perhaps because of NUD or Higher
> layer confirmation - it was sending packets to
> the MN), then the cache entry would indeed be valid.
>
> Leaving ND cache entries in the router for an arbitrary
> period of time is problematic though.  For example,
> I get off the same bus each morning to arrive at the
> same desk, possibly using a different path on the way.
>
> Assuming that address state still exists in the router
> when I return, my Tuesday and Wednesday networking
> experience is likely to be worse than my Monday one.
> Even returning from getting a coffee may be frustrating.
>
> If the NC entries aren't long term I can currently
> see two solutions to keeping them in the cache
> (and keeping state valid):
>
> * Make address lifetimes sufficiently short that the addresses
>    have a short lifetime, and must be reconfigured.
>
> * Actively poll devices using NUD even if they are not
>    receiving packets (maybe at longer than normal intervals).
>
> The second solution may have significant battery life issues
> in wireless computing environments (as MLD group membership
> does anyway).
>
> Greg
>
>
>