Juliusz, I like your analysis, and I think it needs to be included in a homenet document. It doesn't really belong in the routing protocol comparison, although it may call for some requirements for router implementations. Maybe there is a homenet "router requirements" draft in our future.
Regards Brian On 07/03/2015 12:56, Juliusz Chroboczek wrote: >> But now I don't see what's to stop a home user from buying a more >> general-purpose router which happens to have a ZigBee port or something, >> and plugging it in such a way that it *should* behave as a stub router. >> How does it discover that and configure itself accordingly? > > Disclaimer: I know nothing about ZigBee. > > My first reaction is that we'll cross that bridge when we come to it. > > My second reaction is that in a properly functioning network, the ordinary > mechanisms of the routing protocol will effectively treat the link as > a stub. If the topology is just > > > Homenet --- A ........ > (ZigBee) > > then obviously the ZigBee link will not be used for transit. If the > topology is redundant: > > Homenet --- A ------ B > | | > | | > C ...... D > (ZigBee) > > then the routing protocol should assign a sufficiently high metric to the > ZigBee link, so that in effect it will be treated as a stub link. > (Disclaimer: the current implementation of Babel doesn't do that yet, it > currently only has a taxonomy of wired/wireless/bridged/BATMAN, I'm quite > willing to implement it if somebody has a suitable device to test on.) > > Where you run into trouble is when the Homenet topology is not redundant > enough, and there is a fault on the Homenet side: > > Homenet --- A B > | | > | | > C ...... D > (ZigBee) > > Here, no matter how high the metric of the ZigBee link, Homenet traffic > from A to B will want to go through it. If A is your NAS and B is your > TV, then an attempt to start a streaming session may bring the ZigBee link > to its knees. > > My third reaction is that this should be avoided by proper AQM on the > ZigBee link, but I don't know anything about AQM for ZigBee, so I'll shut > up. > > So in summary, the stub functionality is only necessary when (1) the > topology is redundant, (2) the ZigBee link doesn't have adequate AQM, and > (3) the ZigBee link needs to remain functional even when the Homenet gets > otherwise partitioned. While I agree that there are useful use cases for > that (you certainly want your thermostat to keep functioning even when > somebody unplugged the Ethernet from your television), frankly, I'm not > going to loose too much sleep over that. > > -- Juliusz > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
