Hi,
Pascal Thubert (pthubert) wrote:
Hi Jonathan:
On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote:
Looks so alike and still is so fundamentally different. Ralph
explained
that in SFO a lot better than I can ever do but that has to do with
the
model below.
In DHCP, the server owns the address and lends it away. You have to
get
back to that server to renew the binding. In whiteboard, the nodes
owns
the address and registers it where it wants, or anywhere (anycast).
When we do SeND, that distinction might blur quite a bit but still,
the
white board acts on behalf of the node so it does not hold any master
state (like a pool with LRI etc...) after the node is gone.
Hi Pascal,
If Ralph could reiterate what he said at the WG meeting on the ML,
that would certainly help my understanding of the fundamental
difference between DHCP and whiteboard.
At least in my mental model, the whiteboard is authoritative in what
nodes can use what address. The node MUST periodically renew the
binding with the whiteboard. The node cannot use that address when the
binding expires without renewal because the whiteboard could then
allow another node to use that same address. Whether or not we view
the node as "owning" the address is a non-issue for me. Functionally,
the whiteboard is authoritative and that's not unlike DHCP.
Seems my words failed to convey the message and I hope Ralph will
express that better.
The key in my mind is that the owner is the node, and the whiteboard is
just an attorney.
Though he is the one who speaks during trial, the attorney can only say
what his client agreed upon.
And the client might switch attorney at will.
With stateful DHCP, the server plays is like a chess player that places
and controls its pawns at will.
So the model is reversed.
This is also my understanding.
Also, in various places in the ND draft, we say *stateless* address
autoconfiguration - when in fact this is not the case. The whiteboard
maintains necessary state for all nodes in the network no matter how
you spin it. If that state does not exist, is not maintained properly,
or cannot be reached by the client node, DAD using the whiteboard will
fail. At the very least, I think we should drop the word "stateless"
everywhere in the draft.
I think you're very right, that's an excellent point.
I don't agree completely. The node is creating an address using
Stateless Address Autoconfiguration (RFC4862), we are not breaking that.
So in Section 5.2, where we are forming addresses, this is used correctly.
The only thing we are changing, is the mechanism to perform DAD.
I agree that the Whiteboard is not stateless, but it also does not start
with any state, nor does it require configuration from an administrator.
It is a blank slate..
Stateful in the DHCP acceptance is certainly closer to what we are
doing.
Pascal
--
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297
Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND
This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system without
producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
