Ole Troan <[email protected]> wrote: > 1) pure peering - homenet -> LLN ::/0 > - LLN -> homenet more specifics > for LLN routes and cloud service prefixes
I don't understand your ::/0 here.
I think the LLN gets a ::/0 route into the homenet, and the homenet gets a
specific route into the LLN. Is this what you were trying to say?
> 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.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
pgpM4LbGEsRv4.pgp
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
