> Le 19 août 2015 à 12:37, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> > a écrit : > >> I am pleased to announce the public release of pimbd, the PIM >> implementation that was demonstrated during the last Bits and Bites in >> Prague. > > I've now looked at it, and it's looking good to me. It's roughly the size > of babeld (10kloc), the code looks reasonably clean, and there appears to > be dome amount of OpenWRT integration. I've been able to compile it under > Debian (libubox, grumble grumble), I've been able to get it to join IPv6 > multicast groups, but I've been unable to get it to actually route > multicast. Probably something wrong on my side, I'll wait until it > migrates into OpenWRT >
Thank you for this feedback. We can try to trouble-shoot the problem if you want. But I must admit that I learned how painful Linux can be with multicast forwarding sometimes. > A few questions. > > Does SSMBIDIR interoperate with plain BIDIR? What happens when there are > both BIDIR and SSMBIDIR routers in the Homenet? > > Could you please explain what problem you're solving with the SSMBIDIR > extension? I'm not a multicast specialist, so please correct me if I'm > wrong, but I understand that BIDIR: > > (1) doesn't optimise SSM trees; > (2) wants a well-defined default route. > > Which problem exactly are you trying to solve with SSMBIDIR? Both? If > just (1), might we as well go with plain BIDIR? SSBIDIR is not very different than BIDIR. It still uses one single forwarding tree, relies on designated forwarder election, all the traffic is sent to the RPA, ... The only difference is really an optimization that filters downstream traffic. If you have part of your network which wants (S1,G), and another that wants (S2,G), you will be able to filter that out such that you don’t send (S1,G) to the part of the network that does not want it. And you don’t send (S2,G) to the part of the network that only asked for (S1,G) (With the exception of upstream path, as traffic is always sent to the RPA). As for backward compatibility with PIM-BIDIR, it works fine. SSBIDIR routers will detect the presence of BIDIR-only router on the upstream interface. If a BIDIR-only router is detected upstream but is not the designated router: - You can still send (S,G) and (*,G) Join/Prunes - You stop using (S,G,rpt) Join/Prunes If a BIDIR-only router is detected upstream and *is* the designated router: - You use (*,G) Join/Prunes only This logic is implemented and, afaik, works. SSBIDIR is disabled by default. You can enable it with ‘pimbc link ...' > > What problem does the proxying business attempt to solve? And what does > it use TCP for? > > To compile this under Debian: > > apt-get install liblua5.1-0-dev > git clone http://git.openwrt.org/project/libubox.git > (cd libubox && make && sudo make install) > sudo ldconfig /usr/local/lib > git clone https://github.com/Oryon/pimbd > (cd pimbd && make && sudo make install) > Thank you ! I will add that to the HowTo. And may create a script at some point. - Pierre _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
