Re: [6lo] Draft applicability for 6775bis

["Pascal Thubert (pthubert)" <[e-mail]>]

What about :

«
    This implies that a 6LR or 6LBR which is intended to support N hosts MUST have space to register at least on the order of 10N IPv6 addresses.
«
->
«
    This implies that the capabilities of 6LR and 6LBRs in terms of number of registrations must be clearly announced in the router documentation, and that a network administrator should deploy adapted 6LR/6LBRs to support the number and type of devices in his network, based on the number of IPv6 addresses that those devices require.
«

Works ?

Pascal
From: Lorenzo Colitti [mailto:[e-mail]]
Sent: jeudi 20 avril 2017 11:52
To: Gabriel Montenegro <[e-mail]>
Cc: Pascal Thubert (pthubert) <[e-mail]>; Erik Nordmark <[e-mail]>; huitema <[e-mail]>; [e-mail]; Suresh Krishnan <[e-mail]>; [e-mail]
Subject: Re: [6lo] Draft applicability for 6775bis

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]<mailto:[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)