Hi Anthony: Thanks a whole bunch for this review. Let me please respond inline
[Anthony] I went through your draft about the concept of a Backbone Router to help large-scale networks deployments. I have a few comments about the draft, I put them below: In Figure 1 you drew one single gateway that connects the backbone router to the plant network. You do not refer to it later in the document. Is it something application specific, a requirement for the backbone router approach or a consequence to it? For any case, I would mention it or remove it from the figure. [Pascal] The figure depicts the current ISA100.11a reference model. I need to add words that this model applies to many situations in industrial, home and building automation, but certainly not all and that the gateway could become a firewall or a simple router depending on the use case. In the same fashion, the plant network can be the building control network, the Service Provider network or even the Internet. [Anthony] In Section 6.1, you wrote that Bacbone Routers announce themselves using RAs that are broadcasted. Maybe you could see whether the solution proposed in draft-chakrabarti-6lowpan-ipv6-nd-04.txt section 6.2 can help avoid sending many broadcast messages. As a resume, they suggest: " .. the PAN co-ordinator aka IPv6 router sends periodic RA to the co-ordinators in its PAN by sending unicast messages to each of them... Each co-ordinator can act as proxy IPv6 router advertiser and they can broadcast the RA on behalf of the IPv6-router in their own domain periodically.." [Pascal] Very right. The focus of this doc is to illustrate the white board approach and the use of proxy ND over the backbone to scale up the LoWPAN. If the group agrees that this is the direction then we can dig further and merging with draft-chakrabarti would be an excellent idea. It is clear to me that my Draft 00 falls short in a number of occasions which were not the focus at the time. - registration mechanism. DHCP formats make more sense than NS/NA that I used. I asked Benoit Lourdelet to join as a coauthor to rework that. I also got comments that a totally new format could be welcome, along the lines of RFC 3775 Binding Update (though the BU as it stands is not fit for the job) but for the time being I'd rather stick to DHCPv6 and see the feedback from the group. - NS lookup. There can be 2 ways, proactive and reactive. My draft reflects proactive using unicast NS/NA with the white board (and it will be based on DHCP RFC 5007 in the next release). It's good because it woorks for any type of address, link local, unique local and global. draft-chakrabarti proposes a reactive version where the backbone router does the lookup for you with an implicit request that comes with the packet to be forwarded. This saves the NS/NA flow but causes all packets to flow via the BbR. The route optimization with the PAN can still happen under the BbR control using redirects. I think we need both approaches make sense and are needed; that's a good reason to merge the drafts. - RA (as you point out), and that includes for me advertising the DHCP relay and white board capabilities so we skip the SOLLICIT flow that is normally multicast but makes little sense here. I had nothing much to add to the excellent work that is already there in draft-chakrabarti; that's another good reason to merge the drafts. [Anthony] In Section 6.4, you mention that the target link-layer address is that of the destination if a shorcut is possible over the Lowpan. Do you plan to specify the mechanism that will tell the nodes if they have to go through the Backbone Router or not for a communication? Shortly, how do the nodes know if a shorcut is possible and better than the backbone route? Is it out of scope of this document? [Pascal] My draft does not say haw the routing is done (mesh under or route over) and I do not think there is an assumption about it. What it does is a proactive unicast NS/NA that results in the 16 or 64bit address of the next hop. If the next hop is outside of the PAN then you get something that leads to the BbR. If the nect hop is inside the PAN (the destination) then you should get the address of that destination and you packet will get there directly. There is a complexity involved in the case where multiple BbRs serve the same PAN. They have to figure that the route inside the PAN exists and is shorter than the route outside via the BbRs and the backbone. I think that there's a point where we'll be needing ROLL to sort out these issues. My draft does not cover that and expects a single BbR, hot standby BbRs, or a default policy for inside routes vs. outside routes. [Anthony] There are various benefits of the Backbone router approach that may be mentionned in the document. If you let backbone routers take care of the routing for the nodes for instance, it may result in only unicast packets within the different lowpans (towards and from the backbone router), which will have as consequences 1) less interferences (less packets in the air due to routes that are known from the backbone router to the destination node and due to the shorcut that the backbone may offer compared to long multihop communications) 2) less broadcast packets 3) reduced memory requisite for routing tables on the nodes 4) longer battery life for the sensor nodes. This could be made more visible in the document. [Pascal] This should be made more visible in the document, and though the document does not specify how offline routing can be done there is a common spirit between the two and the benefits are similar. Note that both ISA100.11a and WiHART assume offline routing and that it will certainly be an option to consider for ROLL. I trust that most readers figured that those benefits apply to this draft already but it certainly does not hurt to add a small section about benefits that we expect from avoiding multicast and using the backbone as we do. Thanks a bunch Anthony, Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
