Hi Jonathan: Good points to clarify :)
>For me, the discussion isn't whether or not RFC 4861 works - some of >the mechanisms it defines clearly does not work in the networks we >care about. The discussion is whether or not there are aspects of RFC >4861 that we should NOT be changing but are. > >Another discussion point to raise is the properties of the "binding >table" vs. the "neighbor cache". A significant difference is that the >binding table is no longer a cache in the sense that the attachment >router MUST maintain state about any host currently attached to it. >If the binding table is full, a node cannot attach to it. Is this a >concern for some? Well actually I think we so improve that situation quite a bit. With traditional ND cache, if the cache is too small, the router would keep on flushing entries and doing NS/NA. At worse, there could be one NS/NA per packet to be transmitted, and that could end up overloading the router that MUST keep the packet during resolution. With our ND, we have the capability to say NO like an admission control. Action point would be to make sure that we have a code in the NC for the router to tell that its resources are exceeded at that the node should pick an alternate router. >>> We have found NUD useful for determining reachability with any >>> neighboring node - not just parents in the routing DAG. >> >> That is indeed a useful function. >> Using ND as a neighborHOOD discovery protocol would argue for >> implementing NS/NA, as is allowed (but not required) for 6lowpan- >> ND. NeighborHOOD discovery typically is a routing function, though, >> so it is hard to discuss this in general terms in the ND spec. It >> certainly should not be REQUIRED if the routing protocol does not >> use it (e.g., because it has a different neighborHOOD discovery >> protocol, or only supports host-to-host after a redirect). > >NeighborHOOD discovery would also include address resolution. While >the draft currently states that NS/NA are "not required", perhaps it >would be more correct to say that the implementation of processing NS/ >NA messages is required as per RFC 4861, but that the transmission of >them is optional. Or did we really intend to make their >implementation optional as well? In a really constrained node it can be optional. It appears that the use cases I've seen so far where direct connectivity is really needed comes from nodes that can actually afford it. The spec does NOT say that a node that does 6LoWPAN-ND MUST Not do 4861 on top. It may but that's out of scope for us. And that will provide additional forwarding perspectives just like using RIP and OSPF on a same router will give different routes that will require arbitration. 6LoWPAN-ND as it stands is self sufficient, very economical, but certainly not optimized for everything. Cheers, Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
