Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Pierre Pfister]

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  a écrit :
> 
> 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 
> 
> 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 
> 
> - Implements the PIM border proxy extensions: 
> 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 
> 
> 
> 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 
> .
> 
> As stated above, pimbd can be configured by HNCP, and will if you install 
> both pimbd and 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
> 
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Pierre Pfister]

> Le 19 août 2015 à 13:53, Juliusz Chroboczek  
> 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Juliusz Chroboczek]

> 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?

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Pierre Pfister]

> Le 19 août 2015 à 13:31, Juliusz Chroboczek  
> a écrit :
> 
>>> Could you please explain what problem you're solving with the SSMBIDIR
>>> 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?
> 
>>> What problem does the proxying business attempt to solve?  And what does
>>> it use TCP for?
> 
> 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



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Steven Barth]

Am 19.08.2015 um 13:31 schrieb Juliusz Chroboczek:
>>> What problem does the proxying business attempt to solve?  And what does
>>> it use TCP for?
> And what about that?
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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Juliusz Chroboczek]

>> Could you please explain what problem you're solving with the SSMBIDIR
>> 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?

>> What problem does the proxying business attempt to solve?  And what does
>> it use TCP for?

And what about that?

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Pierre Pfister]

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

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Juliusz Chroboczek]

> 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

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?

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)

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

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Juliusz Chroboczek]

> Both of these techniques makes use of a metric in order to decide which
> one is the ‘best’ router to forward some packet.

Perfectly clear.  The unicast routing protocol needs to communicate the
metric to the PIM daemon, and the kernel priority is a convenient place to
put it.

Thanks, Pierre.

-- Juliusz


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Pierre Pfister]

> 
> 
>> So this is to choose between identical routes. Why is this needed?
> 
> I have no idea.  You'll have to ask Pierre.
> 
> (And I'd appreciate an explanation myself.)
> 

*clearing throat* :)

Here is my humble understanding as a multicast non-expert.

PIM makes an extensive use of RPF (Reverse Path Forwarding) to build the 
multicast forwarding tree.
RPF can be done with the routing table alone, with no metric. You just need to 
know the ‘upstream’ interface to either an RP address, or a source address.

The issue comes from that multicast routing is not about sending a packet to a 
next hop, but to a next link. This situation implies that you may have multiple 
routers that, according to the RPF and PIM Join/Prune, could be candidate to 
forwarding a packet to/from some link.

When such a situation occurs, an election mechanism is used to solve it.
- In PIM-SM, it is not reactively using Asserts
- In PIM-BIDIR, it is not proactively using DF election mechanism.

Both of these techniques makes use of a metric in order to decide which one is 
the ‘best’ router to forward some packet.

I do not know exactly what are the consequences for PIM-SM if you don’t have 
these metrics (Asserts are won randomly).
But I think that in PIM-BIDIR, you can end-up with stable routing loops.

- Pierre
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Juliusz Chroboczek]

> So this is to choose between identical routes. Why is this needed?

I have no idea.  You'll have to ask Pierre.

(And I'd appreciate an explanation myself.)

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Mikael Abrahamsson]

On Tue, 18 Aug 2015, Juliusz Chroboczek wrote:


(If you test this with Babel, you need to set "reflect-kernel-metric true"



What does that do?

[...]

So it takes whatever metric it came up with and sets the metric as kernel
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.


So this is to choose between identical routes. Why is this needed? Where 
do the duplicates come from?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Juliusz Chroboczek]

> > (If you test this with Babel, you need to set "reflect-kernel-metric true"

> What does that do?
[...]
> So it takes whatever metric it came up with and sets the metric as kernel
> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Mikael Abrahamsson]

On Tue, 18 Aug 2015, Juliusz Chroboczek wrote:


(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.)


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 Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Open-Source PIM BIDIR (and more) implementation

[Juliusz Chroboczek]

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

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet