Failed context switch on my part.
I was trying to use draft-ietf-6lowpan-nd-16 as an example of modified
ND being applied to all nodes on a certain link type for a specific
operational reason. (Yes I understand draft-ietf-6lowpan-nd-16 is
specifically targeted at only 6lowpan nodes, although of course your
6LBR will have to run both flavors of ND: one special type avoiding
multicast on the 6lowpan interface, and the other on the "classic"
interface)
The comments I made about ALL nodes should modify their behavior were
meant to be directed at draft-nordmark-6man-impatient-nud-00.txt.
Apologies for any confusion on the use of "this draft"
If you modify ND behavior for one node, from a purely operational
perspective, it makes sense IMHO to make sure the modified ND behavior
applies to all nodes on a particular link, so that you can obtain your
desired operational result.
/Grüße zurück aus Niederlande :-)/
RayH
Carsten Bormann wrote:
On May 25, 2011, at 19:58, Ray Hunter wrote:
I've just read the RFC covering the (very interesting) mesh under / route over
mechanism used in 6LoWPAN http://tools.ietf.org/html/draft-ietf-6lowpan-nd-16 .
Very cool stuff.
Thanks!
Even there it was a requirement that all nodes taking part in the network
behave the same way.
The applicability of this specification is limited to LoWPANs where all nodes
on the subnet implement these optimizations in a homogeneous way.
The idea here is that this draft updates RFC 4944 (the IP-over-foo for IEEE
802.15.4, usually referred to as 6LoWPAN) so that *all* nodes on a 6LoWPAN MUST
implement 6LoWPAN-ND as opposed to ND-classic.
So if the point of this draft is really to limit multicast, then from an
operational perspective don't you want ALL nodes on a link to avoid using
multicast as much as possible?
Yes, that is one of the reasons why we didn't try to tackle the theoretical
possibility of interoperation between nodes implementing 6LoWPAN-ND and other
nodes implementing ND-classic on 6LoWPANs, because even listening for multicast
is very expensive for some nodes there.
So if the point of this draft is really to avoid operational problems with STP
thrashing, then from an operational perspective don't you want ALL nodes on a
link to avoid timing out too fast as much as possible?
There is no STP in 6LoWPAN, so that isn't a consideration for this draft.
Again, 6LoWPAN-ND is currently defined for non-Ethernet networks that are
homogeneously 6LoWPAN-ND, i.e. 802.15.4 (and, most likely once their
IP-over-foo documents stabilize, similar constrained networks such as BT-LE or
DECT-ULE),
However if people want to go ahead and do the work of adapting 6LoWPAN-ND (or
some of its elements) to other networks,
e.g., Ethernet/WiFi, then one would have to open that can of worms.
Gruesse, Carsten
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
