On Nov 19, 2009, at 12:55 PM, Zach Shelby wrote:
On Nov 18, 2009, at 21:52 , Jonathan Hui wrote:
The question for me is what to do with the other half -
specifically the DAD portion.
The right question to ask is - What should be the goal of the other
half?
The goal will drive what to do.
First, I do believe that having a completely separate mechanism
solely for detecting duplicate addresses is unnecessary overhead in
real production deployments. In some cases, applications will
accept the extremely low probability that a duplicate address will
exist in the network. In other cases, networks will have other
mechanisms in place that can (and will) be used to assign unique
identifiers (e.g. through commissioning, strong security
associations, DHCPv6, etc.) within the proper scope which may be
used to form unique IPv6 addresses. If the identifiers are
*assigned* in such a way to be unique, the added benefit of
*detecting* failures in the assignment mechanism is marginal. For
these reasons, I think there is consensus in this working group
that DAD should be optional at best.
I agree that uniqueness of addresses within a LoWPAN is necessary,
and that can be assured in many ways. There will be networks where
the uniqueness of addresses must be checked with some mechanism. The
base 6lowpan-nd document shouldn't tell how this uniqueness is
determined. But checking for uniqueness should use very strong
wording in that document, with an opt-out if you are sure addresses
have been assigned properly. Note this must be an opt-out rather
than an opt-in.
So we agree that it's optional.
Second, I'm not yet comfortable with the whiteboard mechanism, as
specified in nd-07, becoming a WG document. There is consensus in
this WG that the whiteboard mechanism does not work in all
scenarios and should be optional at best. Given that, I think this
WG needs to think more about the broader effects of specifying a
particular way to do DAD while making it optional. Having an
option (or multiple options) could cause interoperability issues
and confusion down the line.
It would not make sense to use the nd-07 mechanisms exactly as
specified now after the split. Multiple options is not the problem -
as you say above - there will be a wide variety of ways to insure
the uniqueness of addresses. The problem I see is that just defining
the whiteboard on its own only for DAD doesn't make much sense, so
there we can agree.
Options is a problem if not dealt with properly. For example, can a
node that does not implement the "whiteboard protocol" (for lack of a
better name) participate in a network that requires the use of the
"whiteboard protocol"? Specifying the "whiteboard protocol" (or any
other mechanism) now would almost make it required to be implemented
by all lowpan routers to ensure interoperability in networks that
depend on it. This is what concerns me and I admit that I don't have
a good solution to the problem.
We should instead call the second document "Extended LoWPAN", and
have it define a mechanism only for enabling Extended LoWPANs.
Extended LoWPANs require a binding cache of some kind at each ER
(called a whiteboard or whatever), as in the original backbone
router draft. As a side-effect of registering with the Extended
LoWPAN mechanism, you are also able to determine the uniqueness of
an address. So this would not be specified for use as DAD on its own.
The call for consensus cited DAD as the primary reason for separating
the whiteboard mechanism. Pascal's individual submission on
whiteboards cited many additional (and good) benefits, but many of
those were dependent on having mesh-under and become lost with route-
over. When operating mesh-under, I see lots of value for the
whiteboard. But, I'm mostly interested in route-over networks, so can
you list what additional features the whiteboard mechanism provides in
addition to DAD?
Third, I'm not sure, frankly, that the whiteboard mechanism is
something of broad interest to members of the WG. Looking through
the mailing lists, I haven't found much (any?) support for the
whiteboard outside of the authors. In fact, I have found more
comments of concern. I also don't think we've even polled the WG
about whether the whiteboard mechanism should be taken up in a WG
document.
The 6lowpan-nd document was taken as a WG document already a year
ago, and its main mechanism was (also then) based on registration to
a whiteboard. A cache such as a whiteboard is a means to an end...
are people using RFC4861 really deeply interested in neighbor caches?
I tried looking for the call for consensus in the archives, but could
not find it. I also tried to see if there was a consensus call on
what we would put in the draft, but could not find it either. What I
did find were objections to having a whiteboard mechanism. Correct me
if I'm wrong, but if it's true then skipping these steps was a
mistake. Now that we are splitting the document, we should at least
do a call for consensus on creating these new WG drafts. As far as I
can tell, this call for consensus is pretty close to that.
That said, the real issue for me is not that people are interested in
neighbor caches, the real issue is that there are people who see
little added value in the whiteboard mechanism for many of the reasons
I cited earlier.
The goal of the second document should be the Extended LoWPAN
feature and what it enables. For me this is an important feature,
and I have heard many planning to take advantage of it.
It would be good to hear from those who would like to actively work on
this whiteboard feature to speak up. There has been little feedback
on the whiteboard mechanism on the mailing list. As an author, I can
say that nearly all of the discussion on the mailing list is among 4-5
authors. I feel uncomfortable with a WG document that is not
supported/reviewed/edited by a good number of WG members outside the
authors. So it would be certainly help to get more input from other
WG members about what to do with the whiteboard mechanism.
--
Jonathan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
