On 05/12/10 04:31 AM, Pascal Thubert (pthubert) wrote:
Hi Anders;
The current ND draft has a white board, though it calls it a neighbor
cache. Sometimes, renaming things is good. In this instance, I do not
know. Clearly, standard neighbor cache entries must not be confused with
the ones gleaned for the registration process, because only the latter
can be fed into the backbone mechanism, be it route over or mesh under.
I clarification might be in order.
In 6lowpan-nd-09, the only way a neighbor cache entry is created is from
the registration process. Thus there isn't any "gleaning" and any risk
of conflicts.
The White Board conceptually differs from the traditional Neighbor
Cache:
- The WB is a table as opposed to a cache. A neighbor cache entry can
stay STALE for a very long time after the node is gone. A neighbor cache
entry can be flushed to make room anytime. So a neighbor cache entry
does not represent the node accurately enough to be redistributed in a
routing protocol or proxied over a backbone.
That is true in RFC 4861, but section 6 in 6lowpan-nd-09 tries to make
it clear that the entries stay around until they time out. Is there
something we should make more clear in that section?
- It is fed proactively using a registration as opposed to reactively to
traffic. The registration and timely reregistration guarantees the
presence of the node proactively. NUD is reactive, depends on traffic.
It is nice to have but not mandatory as long as you have a registration.
The purpose of NUD in 6lowpan-nd is primarily to be able to detect when
one of the host's default routers have disappeared.
Thus I don't see how NUD can not be mandatory; the registration is for
the reverse direction - traffic from the router to the host.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
