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.
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.
--
Regards,
RayH
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
