Michael, >> 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?
homenet advertises a default into LLN. or LLN discovers a default from homenet. LLN advertises more specifics into homenet. > >> 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. cheers, Ole _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
