On Mon, Mar 23, 2015 at 03:17:54AM +0100, Juliusz Chroboczek wrote: > > 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.
I fully agree as far as anything that looks even remotely like MOSPF is concerned. Caveat: I have no opinion on anything related to BIER or other recent approaches to handling multicast. They're different beasts. [quote shortened] > > 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. I stand corrected - that does indeed sound like there is rough parity between Babel and IS-IS on the ability to transport separate metrics, in case the WG comes to the opinion that this is useful. For the comparison document, this thread is what I would expect to see for section 11, looking at "backing" for multicast routing instead of multicast routing itself. *If* there really is an argument for IS-IS as multicast routing protocol, it really needs to be more informative (and reference an actual implementation, I guess) than 11.1 in the -02 comparison draft. Cheers, -David _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
