Subject: [pim] New Open-Source PIM BIDIR (and more) implementation

From: Pierre Pfister <[email-masked]>
Date: Tue, 18 Aug 2015 15:06:13 +0200

Hello everyone,

I am pleased to announce the public release of pimbd, the PIM implementation that was demonstrated during the last Bits and Bites in Prague.

https://github.com/Oryon/pimbd <https://github.com/Oryon/pimbd>

It is a compliant IPv6 PIM-BIDIR implementation which also does:
- IPv4 multicast routing in a non-compliant way by including IPv4 groups in IPv6 Join/Prunes (Because it works although it is forbidden by the specs). It is obviously disabled if you don’t enable IGMPv3 listener.
- Implements the PIM-SSBIDIR extensions: https://tools.ietf.org/html/draft-pfister-pim-ssbidir-00 <https://tools.ietf.org/html/draft-pfister-pim-ssbidir-00>
- Implements the PIM border proxy extensions: https://tools.ietf.org/html/draft-pfister-pim-border-proxy-00 <https://tools.ietf.org/html/draft-pfister-pim-border-proxy-00>
- Can be configured by HNCP in order to function without any human configuration: https://tools.ietf.org/html/draft-pfister-homenet-multicast-00 <https://tools.ietf.org/html/draft-pfister-homenet-multicast-00>

It runs on any Linux (given it has the required multicast routing support).
An OpenWrt package has been published in the routing feed: https://github.com/openwrt-routing/packages <https://github.com/openwrt-routing/packages>.

As stated above, pimbd can be configured by HNCP, and will if you install both pimbd and hnetd (https://github.com/sbyx/hnetd <https://github.com/sbyx/hnetd>) packages on your OpenWrt router.

You will notice that the three above drafts have expired.
I have no intention to revive them unless there is a strong support from the homenet working group to keep moving this way. I do believe that a routed home network will need routed multicast to work ‘somehow’. One of the purpose of this implementation was to provide a possibly-temporary patch to this missing part in our homenet implementation. At least, now, we can route multicast ! As for the IETF work, BIER based solutions might be interesting to consider.

Thanks to all those who contributed.

Pull requests are welcome.

Have a nice day,

- Pierre

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 19 Aug 2015 13:17:55 +0200

> Le 19 août 2015 à 12:37, Juliusz Chroboczek <[email-masked]> 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

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 19 Aug 2015 13:39:29 +0200

> Le 19 août 2015 à 13:31, Juliusz Chroboczek <[email-masked]> a écrit :
> 
>>> extension?
>> SSBIDIR is not very different than BIDIR. It still uses one single
>> forwarding tree,
> 
> Thanks for the explanation.
> 
> So what happens when there are multiple default routes?
> 
> And what about that?

Oops, sorry about that. I missed this question.

It is related to "So what happens when there are multiple default routes?" as well.

PIM-(SS)BIDIR does the routing inside the home network. The only route that BIDIR uses is the one to
the RP-Address, which is inside the home network. So it does not uses default routes.

The assumption is that the user will want to receive traffic from the ISP. 
To do so, it needs to subscribe first (e.g. using MLD) on one of the WANs.
One problem is that you don’t know which WAN. 
The solution used here is to subscribe on all WANs.

This subscription/forwarding is the proxy part.
Proxy *controller* is the process that allows routers to ask border routers to subscribe to given groups.
In the HNCP case, a single router is elected on the RP-Link. 
This router will have a knowledge of the home-wide-membership-state and will reflect that state
by « asking » (through TCP connexions) all border routers to subscribe to those groups.

I hope it is clear enough,

- Pierre

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 19 Aug 2015 14:01:29 +0200

> Le 19 août 2015 à 13:53, Juliusz Chroboczek <[email-masked]> a écrit :
> 
>> The assumption is that the user will want to receive traffic from the
>> ISP.  To do so, it needs to subscribe first (e.g. using MLD) on one of
>> the WANs.  One problem is that you don’t know which WAN.  The solution
>> used here is to subscribe on all WANs.
> 
> Sorry if I'm being dense -- but does that mean that if multiple ISPs route
> multicast, you get duplication of traffic?
> 

If they provide the same traffic (source and group), yes.

Adding some signaling in the Proxy Controller protocol would be a fairly simple way to fix that problem.
I do not plan to do that for now.

- Pierre

---

From: Haoweiguo <[email-masked]>
Date: Wed, 19 Aug 2015 13:18:54 +0000

Good work!  
I have another comments related to the comparison between Bidir-PIM and IGP multicast solution in home network scenario.
If bidir-tree is required in home network, i think IGP based bidir-tree solution will be simpler than bidir-PIM, it uses unified protocol for both unicast and multicast. Also the home network scale is not so large, so the multicast group membership flooding through IGP protocol will not be an issue.  The plug and play of IGP based multicast solution also will be better than the combo of unicast IGP + bidir-PIM. So i think the home network maybe the applicable scenario for IGP based multicast solution.
Thanks,
weiguo

________________________________________
From: pim [[email-masked]] on behalf of Pierre Pfister [[email-masked]]
Sent: Wednesday, August 19, 2015 19:17
To: Juliusz Chroboczek
Cc: [email-masked]; [email-masked] Group; Steven Barth; Mohammed HAWARI (mhawari)
Subject: Re: [pim] [homenet] New Open-Source PIM BIDIR (and more)       implementation

Thank you !

- Pierre

_______________________________________________
pim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pim

---

From: Haoweiguo <[email-masked]>
Date: Thu, 20 Aug 2015 11:06:21 +0000

IGP based multicast protocol is suggested, pls refer to http://tools.ietf.org/html/draft-yong-isis-ext-4-distribution-tree-02. The draft has not been implemented in any open source now, theoretically it is better than IGP+Bidir-PIM for home network.
weiguo
________________________________________
From: Steven Barth [[email-masked]]
Sent: Wednesday, August 19, 2015 21:32
To: Haoweiguo; Pierre Pfister; Juliusz Chroboczek
Cc: [email-masked]; [email-masked] Group; Mohammed HAWARI (mhawari)
Subject: Re: [pim] [homenet] New Open-Source PIM BIDIR (and more) implementation

> If bidir-tree is required in home network, i think IGP based bidir-tree solution will be simpler than bidir-PIM, it uses unified protocol for both unicast and multicast. Also the home network scale…
What kind of protocols are you suggesting here and are they implemented anywhere?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 18 Aug 2015 15:45:44 +0200

> implementation that was demonstrated during the last Bits and Bites in

Excellent news, Pierre, automagic site-local multicast would be a great
feature for Homenet.  I'll try it out as soon as it migrates into an
OpenWRT snapshot.

(If you test this with Babel, you need to set "reflect-kernel-metric true"
in babeld's config file; Pierre tells me that this is done automatically
by hnetd.  I'll make some refinements to the reflect-kernel-metric code,
and make it the default in the next release of babeld.)

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 18 Aug 2015 21:31:00 +0200 (CEST)

> and make it the default in the next release of babeld.)

What does that do?

From: http://www.pps.univ-paris-diderot.fr/~jch/software/babel/babeld.html

reflect-kernel-metric {true|false}
Reflect route metrics as kernel priorities. The priority effectively used 
is kernel-priority + metric.

http://linux-ip.net/html/routing-selection.html

"The kernel begins iterating by priority through the routing policy 
database. For each matching entry in the RPDB, the kernel will try to find 
a matching route to the destination IP address in the specified routing 
table using the aforementioned longest prefix match selection algorithm. 
When a matching destination is found, the kernel will select the matching 
route, and forward the packet. If no matching entry is found in the 
specified routing table, the kernel will pass to the next rule in the 
RPDB, until it finds a match or falls through the end of the RPDB and all 
consulted routing tables."

So it takes whatever metric it came up with and sets the metric as kernel 
priority? So if there is a shorter prefix that has a lower metric, this 
will be chosen over a longer prefix with higher metric?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 18 Aug 2015 21:42:39 +0200

> What does that do?
[...]
> priority?

That's right.

> So if there is a shorter prefix that has a lower metric, this will be
> chosen over a longer prefix with higher metric?

No, the kernel still uses the most specific route -- it's only in case of
equal prefixes that the kernel priority is used.  It's analoguous to
Cisco's administative distance.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 19 Aug 2015 12:37:02 +0200

A few questions.

Careful, libubox compilation fails silently if liblua is not version 5.1.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 19 Aug 2015 13:31:25 +0200

And what about that?

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Wed, 19 Aug 2015 13:34:15 +0200

>>> What problem does the proxying business attempt to solve?  And what does
You need to tell the ISPs (via IGMP / MLD joins) which (global) MC groups someone in the net is interested in, so you need to replicate each (globally-scoped) join in the network on all your edge routers or at least the "sum" of all your joins.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 19 Aug 2015 13:53:27 +0200

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Wed, 19 Aug 2015 15:32:00 +0200

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 20 Aug 2015 13:21:17 +0200

> IGP based multicast protocol is suggested, pls refer to
> http://tools.ietf.org/html/draft-yong-isis-ext-4-distribution-tree-02.

That's similar to MOSPF, but done in IS-IS, right?

-- Juliusz

---

From: Pierre Pfister <[email-masked]>
Date: Mon, 24 Aug 2015 14:32:22 +0200

Hello again,

In order to help everyone to give a try to this new piece of software, I just added an example script
which will create a small basic network using linux namespaces, and run pimbd on each namespace such
that you can see multicast routing actually happening.

The topology is really basic, and does not intend to explore particularly complex topologies, but rather
to give an example of how pimbd can be configured and run properly.

The not-so-hidden intent is also, of course, to get feedback in case of obvious platform related bugs.
But the script should provide a running demo on any recent Linux that has the multicast routing 
options enabled as well as networking namespaces enabled.

The script is now on the git repository (https://github.com/Oryon/pimbd/blob/master/examples/example.sh).

Thanks,

- Pierre

> Le 18 août 2015 à 15:06, Pierre Pfister <[email-masked]> a écrit :
> 
> Hello everyone,
>