> On 07 Mar 2015, at 16:54, Ted Lemon <mel...@fugue.com> wrote: > >> On Mar 7, 2015, at 10:44 AM, Juliusz Chroboczek >> <j...@pps.univ-paris-diderot.fr> wrote: >> I think that you and Mikael expect that the ZigBee link will be designated >> as stub, while Brian, ever the pessimist, expects things to go wrong >> whenever they can. I happen to agree with Brian. > > We can't prevent people from doing stupid things, but we can at least give > good advice. I think the advice we would want to give is that a router that > has a zigbee interface SHOULD NOT advertise routes that transit that link, > although they SHOULD advertise routes _to_ that link. I will admit that I > am not exactly an expert on the topic, but this doesn't seem like rocket > science.
My reasoning for asking for stub router support has more to do with the capability of devices e.g. How many lines of code the device needs to support, how difficult is zeroconf, how much memory the device needs, whether it needs to wake up from sleep on a topology change and thus drain the battery; rather than any requirements on best path selection. IMHO Routing protocols will do a fine job of picking the correct path, provided we specify the correct default metrics somewhere. If the last resort path is over mesh wifi, so be it. I see no reason to limit this via an arbitrary technology decision in the architecture. One of my friends ISP links runs over long range wifi in a rural area and it works fine. Radio between buildings over a public highway would be another use case. The zigbee example to me has more to do with the link technology being unsuitable because of its low power requirements and support for applications requiring long battery life, rather than anything else. Having all of these devices wake up whenever a mobile phone tethers to somewhere else in the Homenet would be daft. By using a stub router, anything behind the stub router can remain asleep during this topology change. The stub router itself could be mains powered and route to (yet to be developed) multi hop routed networks. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
