for the pure peering case, I think it would be sufficient for the LLN
to do router discovery (as a host) and for the homenet to provide some
mechanism for the LLN to register which routes it should advertise for
it (aka buddy routing). that mechanism "please inject these routes for
me", would most likely not require participation in a routing protocol,
nor have stringent requirements for convergence, dead neighbour
detection. we may possibly think of them more as static routes.
Right, I think we should have this... I also think it simplifies how things
like virtual machine systems might work; HNCP gets them a prefix, and they
are always a stub network too.
the LLN may not get a prefix from the homenet. that depends. the LLN may make
up its own from ULA, or it may get one from LLN cloud provider. the LLN could
even number the homenet.
To clarify: the "full-featured" HNCP routers would then iterate over
it's LLN-neighbors HNCP-data, and create appropriate routes with
next-hop being the LLN for each assigned prefix with an R-Flag (buddy
router flag if i got the PDF right) and / or some other TBD injection-TLV?
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
