>> 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 ?
I hope I'm just being paranoid, since I rather like the idea of
redistribution through HNCP.
A and B are homenet nodes. L is a low power node.
A-----B
\ /
\ /
L
|
|
LLN
A and B are both announcing the LLN route. L crashes. A and B both
notice that L is no longer reachable, so each of them attempts to route
through the other one. You have a transient routing loop that lasts until
A and B agree on the fact that L is unreachable.
On a wired network, the routing loop will be extremely short-lived (one
successful packet exchange for both Babel and OSPF, not sure about IS-IS).
I'm not sure what will happen on a wireless network, but I've learnt to be
pessimistic about the behaviour of 802.11. I could imagine cases where
the looping data traffic prevents A and B from communicating successfully,
especially if L had more than just two Homenet neighbours.
In the case of Babel (or EIGRP, for that matter), running a stub
implementation on L solves the problem quite nicely, by allowing the
loop-avoidance algorithm to kick in before the loop is established. With
link state, you still get a transient loop, but you're relying on the
carefully designed flooding algorithm of a mature routing protocol to
clear it, rather than counting on the poorly understood interactions
between the routing protocol and HNCP happening in the right order.
-- Juliusz
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
