Just as another point: nothing stops another protocol (the mesh protocol,
etc) from either populating the neighbor table, or defining additional
address resolution strategies for 6LN.

So I don't think 6lowpan-nd is broken. It just may not provide all the
features some are expecting, but doesn't stop a future extension or protocol
from providing those features.

Regards,

  -Colin

-----Original Message-----
From: Stok, Peter van der [mailto:[email protected]] 
Sent: March 9, 2011 8:40 AM
To: Colin O'Flynn; 'Pascal Thubert (pthubert)'
Cc: '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network

Thanks Colin for your reaction, given your summary I like to show my
support.

>>
"It would be good to have some confirmation from the authors to ensure I'm
not just being stupid, something we can never rule out ;-)"
--I feel exactly the same.
<<

>>
"This is a limitation of the 6lowpan-nd draft, if I am reading this
correctly. I'm not trying to argue for or against such a limitation, just
everyone should be aware of it, and if this is not acceptable look for a
solution."
-- I would like to see a solution as it generates unwanted overhead
<<

peter

-----Original Message-----
From: Colin O'Flynn [mailto:[email protected]]
Sent: Tuesday 8 March 2011 18:20
To: 'Pascal Thubert (pthubert)'; Stok, Peter van der
Cc: '6lowpan 6lowpan'
Subject: RE: [6lowpan] nd-15 for isolated network

Hello,

<Pascal>  I'm sure you mean addresses that are formed using a link-layer
address, not just Link Local. More in section 5.7
 </Pascal>

Yes of course! I guess though what I really meant is that according to the
draft, save for the 6LR(s) address(es), a link-local address based on the
EUI-64 is the only address a 6LN could send to directly.

This is a limitation of the 6lowpan-nd draft, if I am reading this
correctly. I'm not trying to argue for or against such a limitation, just
everyone should be aware of it, and if this is not acceptable look for a
solution.

It would be good to have some confirmation from the authors to ensure I'm
not just being stupid, something we can never rule out ;-)

Regards,

  -Colin O'Flynn

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email protected]]
Sent: March 8, 2011 2:03 PM
To: [email protected]; Stok, Peter van der
Cc: 6lowpan 6lowpan
Subject: RE: [6lowpan] nd-15 for isolated network

Hi:

<Colin>
The link-local address based on EUI-64 can always be mapped directly to
a L2 address. This is a special case, no other address can be mapped
that way according to the spec.
</Colin>


<Pascal>  I'm sure you mean addresses that are formed using a link-layer
address, not just Link Local. More in section 5.7
 </Pascal>


<Peter> In the applications I am involved, the bulk (say >90%) will be
messages > to one hop neighbors and possibly two-hop neighbors.
Actually, I expect that the quality of the link between source and
destination can be better than the link quality between source and 6LBR.
(people may argue that this is bad network engineering, but given costs
and knowledge today it looks a very probable situation)
</Peter>


<Pascal>  What's more troubling for Peter's point about 1-hop neighbors
is in 6.1:
"
   A router MUST NOT set the 'L' (on-link) flag in the Prefix
   Information options, since that might trigger hosts to send multicast
   Neighbor Solicitations.
"
This text prevents a node from checking whether another node is visible
at L2. I think that this recent addition is a mistake. Though clearly
costly on a mesh under, this could be reasonable in some route over
cases, as long as the multicast is not forwarded.

What this spec should mandate is whether and how to enforce the
registration for a given prefix as opposed to classical ND. The 'L' bit
does not say that. We need a new bit.
 </Pascal>

Cheers,

Pascal


The information contained in this message may be confidential and legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this message is
strictly prohibited and may be unlawful. If you are not the intended
recipient, please contact the sender by return e-mail and destroy all copies
of the original message.


_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to