Hi Margaret, Chris & Juliusz, Hi homenet list,
while I haven't completely caught up with discussion on the homenet list --the routing protocol thread is truly (th|d)readful-- I seem unable to find significant feedback on the multicast part (sec. 11) of the comparison draft. (I apologise & appreciate pointers if I missed it.) The draft currently assumes IS-IS or Babel would/could be the multicast routing protocol. That assumption, IMHO, is wrong. 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." The most established protocol for multicast routing would be some variant of PIM, or for the hipsters you can try BIER. 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? What I have in the back of my mind here is a separate MRIB. For the non-multicast-savvy on this list, the MRIB is a separate routing table containing routes to unicast prefixes, used to perform RPF lookups to locate paths towards multicast sources/senders. At a large fully multicast-enabled ISP, the MRIB would be an identical copy of the unicast table/URIB. 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. The concept at work here is that metric/cost for a link isn't the same for unicast or multicast. 802.11ac with a wide channel and enough antennas provides great unicast performance - better than a 100MBit Ethernet link. Yet, I would never use that wifi link for any kind of multicast distribution. This means I want a low unicast metric on the wifi link, but a (very) high multicast metric. 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. (Also note that a MRIB will never contain source-destination routes. SADR is simply not supported for multicast RPF lookups; there is only the sender address and the multicast group address.) (I'm blissfully ignorant about BIER for now, yet google tells me there is some IS-IS integration for it.) Cheers, -David P.S.: I've seen 802.11 multicast rate being mentioned as 1-2MBit/s in some e-mails. There is some misconception involved there. 1-2 MBit/s is what you get on current Linux 802.11 AP/IBSS implementations (= home routers). Nothing precludes the AP from using higher rates, but this requires code that Linux doesn't currently have. Getting to full-rate multicast requires snooping for group memberships, determining the lowest rate used by any of the receivers, and optionally calculating whether it might be better to send unicast. "Enterprise" wifi implementations have these features to varying extent in the controller. (2 big vendors have quite extensive features there, 1 big vendor has almost nothing at all - guess it depends on whether some big customer asked for it at some point.) P.P.S.: That also means that a better AP implementation would have less of a difference between the unicast metric and the multicast metric for wifi links. I'd say they should still be different. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
