Hi Erik Please see below:
> I think you are mistaken. > Mesh under works with just RFC 2461, since it is the layer 2 mesh that has to > solve all the hard problems, essentially making things look like an Ethernet to > IP. [Pascal] Assumptions, assumptions. I think you're confusing the 802.11 infrastructure mode and the larger world of mesh under. You'll note that 11S does not go far trying to extend the concept to a real mesh. What about other well-known mesh under topologies like Frame Relay? > > You might be confusing mesh-under with the notion of having a wired > backbone be part of the lowpan without participating in the lowpan routing > protocols. While I think the best way to handle such physical topologies is to > make the wired backbone be part of the lowpan routing protocol domain, > 6lowpan-nd carries sufficient information in the case of mesh-under for the > 6LBR to track all the IPv6 addresses that are registered. [Pascal] The big question is whether the routing domain is an IGP or an SGP. If it is an IGP, then you've split the mesh into multiple mesh an eluded the question. On the way, you've lost the capability to move seamlessly and that is not acceptable. So it must be an SGP. But then it's a route-over solution, even if you're routing only in the backbone. If you do that, why not do it throughout? > > It does not support route over either since it is not compatible with > > the only route over protocol in existence. > > Which RFC contains that 'only protocol'? ;-) [Pascal] Please, I really wish to make progress. I do. > I'm pretty sure I can build a route over solution using RIPv2 or OSPF which are > existing IETF RFCs. It might be far from optimal, but it does indicate that the > separation between the host-to-router interaction and the router-to-router > is in the right place. [Pascal] I'm pretty sure that we can extend those to make decent SGPs for networks where they are fit. They will not be fit inside the LoWPANs, though. Just figure deploying OSPF/P2MP. You'd having to set up a dominating set of routers, and then suffer the bows and arrows of outrageous multicasts. We made that study and decided to work on RPL. What they are missing is the notion of "keeping things together" which relates to the concept of root or authoritative router. Once you have this concept, it's only fair to propagate PIO and RIO as we propose to do in RPL. I do not think I am mistaken. I am certainly unclear. Let's see: The backbone router that was elected in Dublin as WG doc for 6LoWPAN ND was mostly concerned with mesh under. The idea behind was that any route-over (== routing within the subnet) specific problem that would come on top would have to be managed as part of the router-over solution, which we (try to) do in RPL by the way. The expectation of the 6LoWPAN WG when we elected the backbone router draft over Samita's draft was to radically eliminate multicast. The backbone router draft takes a number of measures to get there. The most obvious is the use of NS/NA as a registration mechanism, and I'm very happy that this core idea is still present in the current draft, though the original author somewhat disappeared by some black magic that's quite unusual to the IETF. I claim that the current proposed solution still does not work on mesh under because it does not fulfill that expectation. For instance, I do not see how multicast is avoided in mesh under when there are more than one router in the subnet, without involving routing protocols, which would be route-over. From the backbone router draft till ND-07, we answered that question at the ND level using a whiteboard registrar as a backend to the registration. Please do not confuse that question with the use of a backbone where admittedly, either an SGP or ND proxy could work. I'll add that it is pretty hard to complete the registration mechanism before we know what the registration bask end is. You demonstrated that ND-08 could not be used to front end DHCP. I demonstrated that it cannot be used to front end RPL either. And it's broken for mesh under because it is incomplete. I cannot see how the whole picture works from either this draft alone, or any combination of drafts on the works today. For all I know ND 09 is broken while ND 07 was not. My suggestion to resolve the issues I see: - put the whiteboard interaction back in the base spec so the spec is standing on its own 2 feet. - let the route over problem propagation to RPL (that's the PIO/RIO propagation) - make a separate spec for the ND proxy piece. We have already text from Zach, Carsten and I that can be used Cheers, Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan
