On 07/03/2015 01:02, Ray Hunter wrote: > Juliusz Chroboczek wrote: >>> Or more generally, how does a stub router know that it's a stub router, >>> when there is no human to tell it so? >> >> Yeah, it's not very clear. We were actually asked to describe the two >> protocols' support for stub networks, and nobody never told us which of >> the many definitions of stub network they meant, let alone describing the >> use case precisely. (The document uses the same definition as Cisco's >> EIGRP documentation, in case you're interested.) >> >> I'm imagining a dedicated device that has both a WiFi interface and >> a low-power interface that acts as a gateway between the Homenet network >> and the sensor network. Such a device would come from the factory with >> the low power interface configured as a stub. >> >> -- Juliusz >> >> >> > > Good points. > > My idea of a stub router is that the stub router itself knows it is a stub > router.
I thought for about 24 hours that this was indeed the answer to my question. Well, it is, for routers that are designed, packaged, labelled and shipped for a stubby purpose such as managing a bunch of thermostats or something. What Ray says below applies to this case. 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? Saying that the user made a mistake or should have configured the device is not an answer. Brian > > Someone somewhere has said that this device will not forward packets on > behalf of other devices. > Whether that's in the factory e.g. it runs a special version of the routing > daemon, or because the device has been configured by > the owner as a multi-homed host. > > classic stub routers in EIGRP and IS IS are generally used to save bandwidth/ > improve convergence times/ reduce memory > utilisation/ improve route table stability on remote sites. > > The main use case in Homenet that I have in mind is so that the "stub" device > can advertise a stable loopback or other interface > whilst changing it's attachment point to the rest of the homenet e.g. wifi > roaming. > > With those definitions in mind, I see little difference between a route > filter configured on the full-blown homenet routers, and > a route filter configured on the stub router device itself. > > Given the stub router knows it's a stub router (by a mechanism outside of > hnet or babel or IS IS), the obvious preference would > be for any filters to be set up on the stub router itself. > > e.g. use case of roaming node + stable addresses of other interfaces > outbound route advertisement filter = > permit directly connected interfaces > deny any > > The list of directly connected interfaces can be easily automated without > user intervention. > > And if the use case is to preserve memory utilisation on small devices > inbound route advertisement filter on upstream interface to homenet = > permit default route > deny any > > outbound route advertisement filter on upstream interface to homenet = > permit summary of all prefixes behind my downstream interface > deny any > > the list of prefixes downstream is also known locally. > _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
