Hi Ralph >> So the model is closer to Frame Relay, for which as we all know 4861 >> is >> not better suited than ARP was for IPv4. Issues: >> * non transitive: A has a circuit to B and B has a circuit to C does >> not >> mean A has a circuit to C. Direct (one hop) multicast emulation cannot >> do DAD. >> * local addressing: A might not see B with the same address (VC nb) >> as C >> sees B. So A could not send redirects to C for B. And SLLAO is useless >> (same as 3122) if VCs are switched. > >OK, so these models really need to be documented so we can all start >on the same page. Which model(s) are you expecting for 6lowpan?
I think it is done quite well in the draft, and in particular the fact that we address non-transitive links, that 4861 explicitly does not cover. Since the draft wants to be more generic than IP-over-foo, it makes no assumption on what the switching operation does. Some conserve the MAC address, but others do not. For instance, Frame relay switches the DLCI. Our draft is well suited for Frame Relay as long as the FR is structured as a core of routers (doing some sub-routing between them to route the host addresses) with hosts always one DLCI away from a router. Host to host direct connectivity in FR would be covered by RFC 3122, just the way host to host would be covered by RFC 4861 on ethernet. >> Our draft can act as a complement to 4861 in transit links (to grant >> the >> right to use an address) and a complement to 3122 on NBMA. Our draft >> is >> enough for host to router, and the existing ND operation still provide >> value for host to host. > >"host to router"? What address resolutions does ND-07 provide? Only host to router. >>>> Would >>>> proxy ND be sufficient? >>> >>> I haven't seen such a design yet, so I don't know. >> >> Recursing proxy ND demands a strict hierarchy / spanning tree. Could >> be >> done but probably difficult and inefficient. >> This is certainly incapable to handle movement - there were drafts >> like >> this in NEMO long ago. > >Why would recursing proxy ND be necessary? If the mesh-under provides >hub-and-spoke reachability, why not put proxy ND at the hub? We already have included proxy ND when there a backbone like an ethernet or a TRILL network. But the radio mesh itself is more complex than just hosts one hop away from the backbone. That's a mesh in which we are doing some mesh under or route over. I thought that you idea was to do proxy ND there. If so, if you figure that mesh as a tree, you'd need proxying at each level. All I'm saying is that it is not a good idea. But maybe that was not your point. Cheers, Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
