Subject: [Bier] comments on draft-wijnands-bier-mld-lan-election-00.txt

From: Antoni Przygienda <[email-masked]>
Date: Sat, 31 Oct 2015 11:49:28 +0000

Agreed with problem statement. As to specific algorithm, I suggest to model it on the current DF election draft being hammered out for EVPN. Satya wrote a good analysis of how to get a bunch of PEs to carve properly delivery of BUM by VLAN/service (could be considered G here or something like this). The FSM is simple and could be adopted and the key is stable hashing algo which he extensively describes. I think it needs a priority extension for couple reasons but  I'll talk to Satya @ IETF if he's there and it may apply here as well.

Actually, the problem is not fully described I think, the election seems to be suggested per G but it really is per G,LAN interface (as in broadcast domain) but if a listener is multi-homed over 2 p2p interfaces (multi-homed like Group3), the problem gets funkier.

Here it is impossible to have one single transit node being DF for the whole G,   the election is per Ether to reach all receivers (but I think MLD does it already, don't remember the specifics). Observe that the fact that Transit 1 and Transit 3 don't even share a LAN does not prevent them from seeing each other since the suggestion seems to be to run the election over the BIER multicast overlay ?

thanks

--- tony

"Your work is to discover your work and then with all your heart to give yourself to it." --- Buddha

---

From: Greg Shepherd <[email-masked]>
Date: Sat, 31 Oct 2015 09:03:50 -0700

Inline:

On Sat, Oct 31, 2015 at 4:49 AM, Antoni Przygienda <
[email-masked]> wrote:

> Agreed with problem statement. As to specific algorithm, I suggest to
> model it on the current DF election draft being hammered out for EVPN.
> Satya wrote a good analysis of how to get a bunch of PEs to carve properly
> delivery of BUM by VLAN/service (could be considered G here or something
> like this). The FSM is simple and could be adopted and the key is stable
> hashing algo which he extensively describes. I think it needs a priority
> extension for couple reasons but  I’ll talk to Satya @ IETF if he’s there
> and it may apply here as well.
>
>
>
> Actually, the problem is not fully described I think, the election seems
> to be suggested per G but it really is per G,LAN interface (as in broadcast
> domain) but if a listener is multi-homed over 2 p2p interfaces (multi-homed
> like Group3), the problem gets funkier.
>
>
>
>
>
> Here it is impossible to have one single transit node being DF for the
> whole G,   the election is per Ether to reach all receivers (but I think
> MLD does it already, don’t remember the specifics). Observe that the fact
> that Transit 1 and Transit 3 don’t even share a LAN does not prevent them
> from seeing each other since the suggestion seems to be to run the election
> over the BIER multicast overlay ?
>

I don't think this was the suggestion. The election needs to take place
over the same interfaces where there are redundant nodes - where they see
each other.

Greg

> thanks
>
>
>
> *--- tony*
>
>
>
> “Your work is to discover your work and then with all your heart to give
> yourself to it.” --- *Buddha*
>
>
>
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 1 Nov 2015 02:19:40 +0000

On Sat, Oct 31, 2015 at 4:49 AM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:
Agreed with problem statement. As to specific algorithm, I suggest to model it on the current DF election draft being hammered out for EVPN. Satya wrote a good analysis of how to get a bunch of PEs to carve properly delivery of BUM by VLAN/service (could be considered G here or something like this). The FSM is simple and could be adopted and the key is stable hashing algo which he extensively describes. I think it needs a priority extension for couple reasons but  I’ll talk to Satya @ IETF if he’s there and it may apply here as well.

Here it is impossible to have one single transit node being DF for the whole G,   the election is per Ether to reach all receivers (but I think MLD does it already, don’t remember the specifics). Observe that the fact that Transit 1 and Transit 3 don’t even share a LAN does not prevent them from seeing each other since the suggestion seems to be to run the election over the BIER multicast overlay ?

I don't think this was the suggestion. The election needs to take place over the same interfaces where there are redundant nodes - where they see each other.

[Tony saiz:] OK, I was just clarifying.  The tricky part is the last case, it leads basically to something similar to “Ethernet segement ID”  (a listener on two interfaces which are not necessarily a broadcast domain). I don’t think I saw anything along those lines in MLD which either points to the fact that it’s not a relevant problem in L3 multicast or I need more education from multicast crowd ;-)

n  Tony