Hi David, > The draft currently assumes IS-IS or Babel would/could be the multicast > routing protocol.
This is what I wrote in Section 11.3: Some experts believe that it may be better to run a dedicated multicast routing protocol rather than extensions to a unicast routing protocol. Sorry for the tone of the above, but since the IS-IS supporters are so keen on pointing out IS-IS's support for multicast, I didn't want to make it any more explicit. > Long story short, MOSPF was the archetype for trying to bolt multicast > routing onto a unicast routing protocol, and the best description I've > heard of it is "trainwreck." I'm really glad to hear that. > However, this doesn't mean that multicast is irrelevant in the routing > protocol comparison. The draft just needs to ask a different question: > does the unicast routing protocol provide the neccessary information for > the multicast routing protocol to perform its job? Good point. There are people working on using Babel with PIM, which is why the current babeld trunk has an option "reflect-kernel-metric" which is used for feeding the Babel metric back to the PIM daemon. I haven't been tracking this work closely, and I have no idea how well it is going. > But the point is that it's calculated separately, so that different > metrics can be used or links can be excluded. I strongly believe this > is useful in the homenet, namely to deprioritise wifi links - or other > future media that sucks at multicast. I don't know. Babel automatically assigns high metrics to wireless links, and in reasonable topologies it will already do the right thing for multicast. (Granted, you can work out a topology where that is not the case -- but you need three wired hops that run parallel to a single, lossless wireless hop, which I don't think is realistic.) > Hence, with IS-IS, I would put into use a separate multicast routing > topology (topology ID #4 is reserved for this.) Routers would use the > knowledge of their interfaces and link status to come up with a pair of > unicast and multicast metrics, instead of just one metric. > > Babel does not - correct me if I'm wrong - have the capability to work > with more than one topology. Babel does have the ability to work with multiple metrics. All Babel announcements carry the default Babel metric, which is a 16-bit integer, and which is used by routers that don't understand the non-default metrics. A Babel router may optionally include a non-default metric in a sub-TLV. The radio diversity extension uses this ability to carry detailed information used for predicting interference. [1] https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-00 No matter which metric they use for route selection, all routers use the default metric for loop-avoidance. This means that Babel remains loop-free even in a heterogeneous network containing routers using the default and non-default metrics. This is not full multi-topology support, and the limitation is that the non-default topology, taken as an unlabelled graph, must be a subset of the default topology: in other words, you cannot assign a finite non-default metric to a link that has an infinite default metric. Of course, the default metric can be arbitrarily large -- just not infinite. To be fair, no multicast metric sub-TLV is currently defined for Babel, and I will not do any work on defining one unless somebody shows me hard experimental data that proves that there exist realistic topologies where such an extension would be worth the hassle. Since the currently available implementations of IS-IS have extremely primitive metric support, even in the unicast case (Section 7 of the comparison document), I don't think an honest person could possibly claim this is a disadvantage of Babel. -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
