>> While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was >> proposed that the IoT device domain would never be used for transit so it >> only needed to get a default (or other aggregate) and inject a prefix and >> the HNCP could be made to satisfy this requirement. > > Could you please clarify what you mean by "inject" a prefix in this > context? Stub router sends HNCP message to non-stub router asking it to > perform redistribution? When does the non-stub router cease redistributing?
indeed. there are quite a few unknowns here. on the Thursday meeting I think we jumped too early into making assumptions on solutions before understanding the requirements. from speaking to James, I can at least see the variants for homenet to LLN peering: 1) pure peering - homenet -> LLN ::/0 - LLN -> homenet more specifics for LLN routes and cloud service prefixes 2) peering + homenet numbered from LLN 3) peering + LLN numbered from homenet as soon as there is a requirement for one of the networks providing prefix assignment to the other, some variant of HNCP is required in addition to some form of peering routing relationship. 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. while 2 and 3 require participation in HNCP, my worry is that even HNCP is too chatty for the LLN to deal with. do we have any numbers? presumably one could design a stub HNCP, where the peer only received messages relevant to it, possibly even with a HNCP sleep proxy. cheers, Ole _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
