We also need to consider, in all of this, the fact that there _will be_
non-homenet-compliant routers and nodes on any home network where homenet is
newly deployed. We need to work properly with those routers and nodes, even
though they do not speak HNCP or whatever we designate as the homenet routing
protocol.
We already do:
HNCP-02 can be used behind legacy CERs that offer DHCPv6-PD (e.g. hipnet).
Also HNCP-02 states:
A homenet router SHOULD provide basic connectivity to legacy CERs
[RFC7084 <http://tools.ietf.org/html/rfc7084>] connected to internal
interfaces in order to allow
coexistence with existing devices.
which is funny enough a more lightweight (DHCPv6-PD-based) version of
the R-Flag described in proposal #1 but not requiring the constrained
device to speak HNCP (and maintain its full link-state database).
As I understand it, it is not the idea of Proposal #1 to have a "leafy
router", whatever that means.
A leafy router in this context is a router running HNCP but not the
homenet IGP.
The idea is that one (or more) of the battery-operated, low-power "routers" on a
low-power internally-routed network (like SEP nodes running RPL, or Nest nodes), would choose a
homenet router to proxy for the low-power network. The homenet router (not some "leafy
router", just a regular homenet router) would inject routes for the low-power network, would
serve as the default up-link router for that network, and would route packets destined for the
prefixes on the lower-power link down into the low-power network. None of the low-power nodes
would run the homenet routing protocol. This is not unchartered territory, as routers running OSPF
would often do this sort of thing for networks running RIP, back in the day, and BGP routers still
do this for networks running OSPF or IS-IS.
Well HNCP itself maintains a link-state database in order to allow
algorithms like prefix delegation to run fully distributed. Proposal #1
proposes to make constrained routers run the full HNCP, i.e. requiring
them to maintain the full link-state. Given Babel as a distance-vector
protocol (given reasonable implementations) your IGP probably requires
less ressources than HNCP itself. Plus as Juliusz demonstrated you can
actually make small stub-versions of them.
So in most cases what you actually need is a stub-version of HNCP, i.e.
a pubsub-like protocol a constrainted device can talk to an HNCP router
in order to publish / subscribe to its link-state DB. This would work a
bit similar to how we hook DHCPv6-PD to HNCP as described earlier.
Once you have that you can think about whether you want to do a
route-injection using HNCP like "proposal #1" and "fallback-routing" or
a stub-implementation of the routing-protocol as noted earlier.
Cheers,
Steven
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
