Re: [6man] New Version Notification for draft-nordmark-6man-impatient-nud-00.txt

[Ray Hunter <[e-mail]>]

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
>
>