Re: [6lo] Draft applicability for 6775bis

[Lorenzo Colitti <[e-mail]>]

Thanks for writing this up. The text is very helpful.

In the general case, I'm not sure 10N is a reasonable recommendation. RFC
7934 section 7 discusses at some length the question of how many addresses
are necessary, and the conclusion is "in general it is not possible to
estimate in advance how many addresses are required".

For a constrained 6lo network, 10N seems reasonable. However, one of the
concerns I have with RFC6775bis is this text:

   Efficiency aware IPv6 Neighbor Discovery Optimizations
   [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND
   [RFC6775] can be extended to other types of links beyond IEEE std
   802.15.4 for which it was defined.  The registration technique is
   beneficial when the Link-Layer technique used to carry IPv6 multicast
   packets is not sufficiently efficient in terms of delivery ratio or
   energy consumption in the end devices, in particular to enable
   energy-constrained sleeping nodes.  The value of such extension is
   especially apparent in the case of mobile wireless nodes, to reduce
   the multicast operations that are related to classical ND ([RFC4861],
   [RFC4862]) and plague the wireless medium.  This serves scalability
   requirements listed in Appendix A.6.

I don't think this is good guidance for general purpose networks. On a
less-constrained device such as a phone connected to a less-constrained
network such as 802.11, ethernet, or LTE, I certainly wouldn't want to be
limited to 10 addresses. This is why RFC 7934 section 7 does not give a
recommendation for number of addresses per host, saying instead that the
network should be able to provide as many as necessary.

A registration-based mechanism is fundamentally different from an
opportunistic mechanism in that the scalability is determined by the number
of configured addresses, not the number of active addresses. For example:
on 802.11, for example, my device can configure 100, 1000, or 1000000
addresses in the same solicited-node multicast group (there are 2^40
addresses there, so there's plenty of space), and nothing in the network
will experience any load, until those addresses are used and have to be in
some router's neighbour cache. And if the neighbour cache were to implement
implement per-MAC address thresholds it would be possible to switch
addresses very frequently

I don't think we should say that 6LoWPAN ND can be extended to other links
without having good text on how to make a trade-off between the scalability
benefits that it claims and the address availability benefits that it gives
up.

On Thu, Apr 20, 2017 at 7:12 AM, Gabriel Montenegro <
[e-mail]> wrote:

> > Please let me know if the text below is OK (you may leverage the
> ticket); I'll time
> > out and post by the end of week.
>
> Thanks Pascal, looks good.
>
> Lorenzo?
>
> Unless we hear otherwise, we can think about WG LC perhaps as early as
> next week.
>
> Thanks,
>
> Gabriel (on behalf of chairs)
>
>