Argll. We manage to disagree on definitions? There's multipath and there's load balancing. Multipath is a topological thing, load balancing is one thing you can do with that topology. Maybe we disagree on definition because you are grouping the two together?
So if we have to define (N)ECMP, here's my take: - Shortest path routing creates DODAGs to a destination D wherein all paths to get to D have an equal cost. When a network is not engineered, this usually means forming trees. - Greedy NECMP forms DODAGs whereby different paths may have different costs; the resulting topology still exhibit single points of failure (e.g. the node closest to destination does not have a plan B). - Non-greedy NECMP routing such as ARCs allow to roll back and reroute around the block. Multipath is important inside the home when the links are not reliable; that's not for complex load balancing stuff but for the purpose of per-packet reroute. If a wireless transmission fails between A and B, the statistical chances of successful transmission drop with the number of retries. It makes sense to add diversity to avoid the cause of the failure, and spatial diversity using multipath is one way to achieve this, which is particularly efficient to combat multipath fading. On wireless, equal cost is a vague approximation anyway so NECMP is perfectly acceptable and, in fact, desirable. With the definition above, feasible successors used adequately can bring useful NECMP at home. Unless I really missed something, RPL and BABEL have the same feasibility condition, which your Babel RFC explains extremely well, and that inherits from a long line of successful DV protocols such as EIGRP, and can be traced back to JJ's DUAL work. You'll find a very similar logic in LFA (section 3-2 of RFC5286). RPL's rules are in section 8.2.2.4 of RFC 6550. The thing BABEL appears to be missing is this: - to really benefit from NECMP, (this is really driven by OF policy but the general rule is that) RPL builds a parent set as opposed to selecting a shortest path next hop. In practice the parent set is actively used to forward retries. Being a routing protocol we did not really discuss the forwarding in the spec, but the behavior is that the packet for which L2 transmission failed is passed back to L3 to be eventually retried on another successor. - On top of that, RPL has an optional tweak that a node may increase its Rank (up to a bounded limit) in the hope of getting more parents and/or retain connectivity with the accepted risk of Count-To-Infinity and data-path micro-loops. Because packets are tagged with the Rank of the sender and the direction (increasing or decreasing Rank), a packet along a micro-loop is detected and eliminated immediately. Cheers, Pascal > -----Original Message----- > From: Juliusz Chroboczek [mailto:j...@pps.univ-paris-diderot.fr] > Sent: mardi 11 août 2015 23:02 > To: Pascal Thubert (pthubert) <pthub...@cisco.com> > Cc: Alia Atlas <akat...@gmail.com>; HOMENET <homenet@ietf.org> > Subject: Re: [homenet] question: equal-cost multipath? > > > RPL enables non-equal cost multipath, > > Could you please point out the place in the spec where it is described? > > > That's called feasible successors in EIGRP. > > Er, no. Feasible successors are something different. > > -- Juliusz _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
