Hi Joseph,
On Nov 20, 2009, at 3:51 PM, Reddy, Joseph wrote:
The whiteboard scheme is not ideal but it does solve the problem of
ensuring unique addresses within a lowpan ( especially when the ipv6
addresses are generated from 15.4 16-bit short address )
You mentioned some sceanrios where it does not work, can you
elaborate more on that ? If whiteboard is not used, then my
preference is that we specify some other mechanism to guarantee
unique ipv6 addresses generated from short addresses.
The whiteboard doesn't work if you want nodes to communicate even when
connectivity with the whiteboard is temporarily down. This may occur
for a variety of reasons - whiteboard service is failing, network
connectivity is failing, etc. Even if we assume our networks are
perfect, some applications may not have connectivity with the
whiteboard at all times.
I think you are confusing address assignment and duplicate address
detection. Specifically for short addresses, what's described in
nd-07 today is a mechanism for *assigning* unique IP addresses and 16-
bit short addresses simultaneously, not ensuring the uniqueness of an
IP address generated from a 16-bit address by the client. If the goal
is to develop a lightweight solution to *assigning* addresses, then
that is how we should view it. The difference is that the service
should not be required if address assignment is done through a
different process.
--
Jonathan Hui
I think DAD should only be made optional in very specific cases -
where the EUI-64 is used for address autoconfiguration or if DHCPv6
is used. While it is true that other non-standard mechanisms are
possible, but then they will not be interoperable. And while some
applications do not require multi-vendor interop, there is nothing
preventing an implementation from violating the standard anyway in
such cases
-Regards, Joseph
------------------------------
Message: 2
Date: Thu, 19 Nov 2009 16:01:03 -0800
From: Jonathan Hui <[email protected]>
Subject: Re: [6lowpan] Way forward for 6LoWPAN-ND, consensus call
To: Zach Shelby <[email protected]>
Cc: Carsten Bormann <[email protected]>, 6lowpan <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
