Re: [6lo] Comment about "draft-thubert-6lo-rfc6775-update-reqs-06"

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

I reviewed draft-thubert-6lo-rfc6775-update-reqs-06 and had a few comments/questions below:


1.       In Section 3, the concept of a Multi-Link Subnet is presented. In it, it was mentioned that “The scope of the 6TiSCH Architecture is a Backbone Link that federates multiple LLNs (mesh) as a single IPv6 Multi-Link Subnet”.

a.       What is the significance of specifying “single” subnet?

> Pascal: that we can span a same /64 subnet across a backbone. Yet there can be multiple ones. Can that be misunderstood?

b.      There could be multiple 6BBRs anchoring each LLN subnet. Would these subnets each have separate sub-prefixes within single IPv6 prefix similar to how IPv4 is deployed with a public address and subnets in the private address space? Granted in IPv6, the subnets do not need to be private.

> Pascal: the /64 is not further subnetted, but it is not onlink

c.       Further into section 3, there was a statement that an LLN can move freely within the multi-link subnet anchored by the same or different 6BBR while keeping its address. Is the assumption here that all the 6BBRs share the same prefix?

> Pascal: Yes; that’s why we need the subnet to span. There are use case where forcing a subnet to be associated to one particular BBR would break mobility scenarios such as changing the line of production where a robot is deployed. We do not want IPv6 to become the reason why this should be an operational hassle.



2.       The call flow in Figure 2 seems to apply to both registration and re-registration procedures – is this correct? If so, it seems during re-registration, the DAD should not need to be performed?

> Pascal: Correct. The first registration will come from the DAR/DAC and the next registrations (the re registrations) will be triggered by periodic RPL DAO.





3.       Figure 2 shows the DAD going beyond the BBR, which based on Figure 1, implies that DAD is performed by the Gateway. Is this assumption correct?

> Pascal: by the 6BBR over the backbone, assuming it performs ND proxy.  It could also redistribute in a routing protocol. If movement is expected then that protocol would require MANET behaviors to clean up stale routes.



4.       In Figure 2, is “Efficient ND” supposed to be compatible with traditional (6775) ND?

> Pascal: the only differences are that it transports a sequence number (a TID) and that it allows the 6LBR to register on behalf of the 6LN (the host)



5.       In section 4.4, there is reference to a duty-cycled device needing the help of a 6LBR to perform registration to the 6BBR on its behalf. Does this statement imply that the device cannot stay awake long enough to receive the NA after sending an NS?

> Pascal: This is the case where a normal device ( a PC) on the backbone sends a NS lookup to the 6LN address. The sleeping device will not hear the NS since it is sleeping, and it needs a proxy to answer on its behalf (a so called sleeping proxy). The same need occurs if the device is far inside the LLN. You do not want to pollute the LLN with the NS.



6.       Req5.4 specifies that a security mechanism lighter than SHA-1 should be preferred. Is it envisioned that LLN devices are constrained devices as specified by RFC 7228 (Class 0-2)?

> Pascal: I have no working code and device doing this to tell you what the lower limit is, sorry for that.



7.       What is meant by Req6.1 in which a single 6LBR can register multiple thousands of devices? Any clarify the use case a little bit?

> Pascal:  yes. This means that the protocol is designed with adequate timers and spread load for this to happen, which is really what’s behind this requirement from a protocol perspective.

And then the 6LBR must have enough storage and CPU power, of course, but that is implementation.

Thanks,

Pleasure : ) Do I read that the text should be clarified?

Pascal