Le 16 nov. 2014 à 03:55, Juliusz Chroboczek <[email protected]> a écrit :
> I've thought about it some more this morning, and I've changed my mind: > I think it's actually not a bad idea, and if done right it might even work. > >> 1) pure peering >> - homenet -> LLN ::/0 >> - LLN -> homenet more specifics for LLN routes and cloud service prefixes > > Ok. What I'm still not clear about is whether you intend the LLN prefix > to be announced by just one homent router, or by all of the homenet > neighbours of the LLN edge router. Proposal #1 is the later. It’s probably the simplest way of doing it. But we can always find ways to agree on the buddy router using HNCP. There is a DR election mechanism already. > If the former, you get non-optimal > routing and brittleness. If the latter, I can see some opportunities for > transient routing loops if not done carefully. (And you certainly don't > want a routing loop on a link with low-power nodes.) That’s interesting. Could you try explaining what could happen ? > > The other issue is how the edge router picks its next hop for its default > route. I don't think that you'd want to reflect the routing protocol's > metric in HNCP, but you certainly need some way to avoid picking a badly > connected nexthop. I see no easy solution here. In the current design, a host selects the designated router as next hop, but there is nothing which makes the DR be the best choice or not. A complication is that in multi-homed scenarios, the best next-hop may be different depending on the source-address you use. Homenet is not chartered to modify the host. But I’ll try to think about how we could improve default router selection for hosts. But to answer the question, I think Low-Power devices could configure as hosts (using RAs). - Pierre _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
