Subject: Re: [pim] [Bier] DR election ...

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 10 Nov 2015 15:05:07 +0000

[ + PIM ]

Hi Robert,

Please see zzh> below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, November 10, 2015 5:05 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Haoweiguo <[email-masked]>; IJsbrand Wijnands <[email-masked]>; [email-masked]
Subject: Re: [Bier] DR election ...

Hi Jeffrey,

- While Ice’s DR election draft was triggered from using IGMP/MLD to replace PIM for multicast overlay signaling in a BIER domain and the draft has some BIER keywords in it, it is really independent of BIER. The draft is still applicable if BIER had never happened.

​So let me understand why this came up just now ? How does current deployments deal with the problem ?

Zzh> It just came up because in the past typically PIM is always running, and now we may not need to run PIM. That does not mean that this is a BIER specific problem.

If I recall the slides the topology Ice presented was ​following:

R1              R2
 |                  |
 -------------------
          |
        H1

where R1 and R2 are two routers terminating BIER domain and H1 is a host. All connected over single VLAN/LAN via some L2 switch

My point was that in the above case R1 and R2 would run VRRP and look as single gateway from H1 point of view. At least for unicast.

The alternative would be theoretically to configure on H1 two default routes and let H1 perform L3 load balancing. However the problem here is that H1 would not be normally able to detect R1 or R2 liveness hence likely it send packets there till arp entry of dead router would timeout.

Now the key question is how does IGMP work with VRRP for multicast today ?

From what I was able to find PIM and VRRP could work together. But the R1 and R2 interfaces towards H1 are not really enabled for PIM are they ?

Zzh> Today PIM does not care about VRRP. They run independently (though there have been discussions tying them together). IGMP is the same way. If PIM is not running, as Ice pointed out, in the simplest form one could just use IGMP querier in place of PIM DR though we want to go beyond that – hence Ice’s proposal.

Jeffrey

Many thx,
r.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 11 Nov 2015 13:42:50 +0000

[+ PIM]

So what exactly is different between MC-LAG and MHD? Is there a standard for MHD (besides l3 mcast aspects)? Or is it that the only missing piece for MHD is l3 mcast?

Jeffrey

> -----Original Message-----
> From: Antoni Przygienda [mailto:[email-masked]]
> Sent: Tuesday, November 10, 2015 8:17 PM
> To: Toerless Eckert <[email-masked]>
> Cc: Haoweiguo <[email-masked]>; Jeffrey (Zhaohui) Zhang
> <[email-masked]>; Robert Raszuk <[email-masked]>; IJsbrand Wijnands
> <[email-masked]>; [email-masked]
> Subject: RE: [Bier] DR election ...
> 
> That's why I don't use MC-LAG, we talk MHD.  We have MHD, we have the
> problem and we need  a protocol between the two homes to elect DF.
> 
> Do I miss anything ?
> 
> thanks
> 
> --- tony
> _____________________________________________
> "Simple, clear purpose and principles give rise to complex and intelligent
> behavior. Complex rules and regulations give rise to simple and stupid
> behavior."
> --- Dee Hock
> 
> 
> > -----Original Message-----
> > From: Toerless Eckert [mailto:[email-masked]]
> > Sent: Tuesday, November 10, 2015 2:47 PM
> > To: Antoni Przygienda
> > Cc: Haoweiguo; Jeffrey (Zhaohui) Zhang; Robert Raszuk; IJsbrand Wijnands;
> > [email-masked]
> > Tony,
> > Can you elaborate (picture, packet flow) how you imagine MC-LAG to be
> > used with BIER ?
> >
> > The way i see it, MC-LAG is always implemented via vendor specific
> > cluster*uck oops: platform specific multi-chassis implementation.
> > No standard approach AFAIK.
> >
> > I see no problem (just annoyed developers) also supporting any form of
> > BIER->IP multicast in the same vendor specific approaches.
> >
> > But given how its all vendor/platform specific i don't think there is
> anything
> > we could/should define about it in IETF.
> >
> > Cheers
> >     Toerless
> >
> >
> > On Tue, Nov 10, 2015 at 06:52:22PM +0000, Antoni Przygienda wrote:
> > >
> > >
> > >
> > > Hi Jeffrey,
> > >
> > > There are two multi-homing scenarios, one is multi-homed network,
> > another one is multi-homed device. For multi-homed network, the network
> > is a LAN, DR/DF mechanism can be used to select one router as master and
> > other routers as slave, only the master router can forward traffic to
> the LAN
> > network, IGMP/MLD extension can be used for the DR/DF election, this is
> the
> > focus of draft-wijnands-bier-mld-lan-election-00. However, if a
> multicast
> > source or receiver is directly accessed to two multicast routers through
> MC-
> > LAG, flow-based loadbalancing can be achieved for uplink direction
> traffic. In
> > this case, IGMP/MLD can't be used for DR/DF election for the MC-LAG. I
> think
> > the new DR/DF election mechanism should also cover the MC-LAG multi-
> > homed scenario.
> > >
> > > [Tony saiz:] yeah, pretty much what I sent out as well.  MHD is the
> > > proper term for the scenario (or MC-LAG but I don't like to use that,
> > > people see LACP immediately ;-)
> > >
> > >
> > >
> > > Tony
> > >
> > >
> > >
> > >
> > >
> > > My two cents.
> > >
> > > Thanks,
> > >
> > > weiguo
> > >
> > > ________________________________
> > > From: Jeffrey (Zhaohui) Zhang [[email-masked]]
> > > Sent: Monday, November 09, 2015 23:08
> > > To: Haoweiguo; Robert Raszuk; IJsbrand Wijnands
> > > Cc: [email-masked]<mailto:[email-masked]>
> > > Subject: RE: [Bier] DR election ...
> > > Not exactly sure about the details of active-active or active-standby
> > scenarios and their relationship to BIER, but here is my understanding:
> > >
> > > - BIER architecture has three layers: multicast overlay, bier
> forwarding, and
> > routing underlay. It is really the multicast overlay's job to handle the
> multi-
> > homing - be it PIM, IGMP/MLD, or BGP, or any other things.
> > > - While Ice's DR election draft was triggered from using IGMP/MLD to
> > replace PIM for multicast overlay signaling in a BIER domain and the
> draft has
> > some BIER keywords in it, it is really independent of BIER. The draft is
> still
> > applicable if BIER had never happened.
> > >
> > > Jeffrey
> > >
> > > From: BIER [mailto:[email-masked]] On Behalf Of Haoweiguo
> > > Sent: Thursday, November 05, 2015 7:39 PM
> > > To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>;
> > > IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>>
> > > Cc: [email-masked]<mailto:[email-masked]>
> > > I agree with Robert's comments. I think BIER also should cover active-
> active
> > and active-standby access scenarios.
> > >
> > > Thanks,
> > >
> > > weiguo
> > >
> > > ________________________________
> > > From: BIER [[email-masked]] on behalf of Robert Raszuk
> > > [[email-masked]]
> > > Sent: Friday, November 06, 2015 8:36
> > > To: IJsbrand Wijnands
> > > Cc: [email-masked]<mailto:[email-masked]>
> > > Subject: [Bier] DR election ...
> > >
> > > Ice,
> > >
> > > As we duscussed offline there are practically two major types of
> > multihomed deployments in production networks:
> > >
> > > 1. True multihoming ... each edge router connect to CEs over different
> > > subnet
> > >
> > > 2. Active/standby .. there is multiaccess lan but VRRP is used so
> hosts can
> > have single default out.
> > >
> > > Now moreover beteen BIER domain and multicast senders and receivers
> > there will pretty much always CEs. I am worried that most BIER slides
> skip
> > those.
> > >
> > > Cheers,
> > > R.
> >
> > > _______________________________________________
> > > BIER mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/bier
> >
> >
> > --
> > ---
> > Toerless Eckert, [email-masked]

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 11 Nov 2015 14:59:30 +0000

If MHD is implemented in such a way that routers will see each other as PIM/IGMP neighbors, and IGMP reports/leaves from H1 will be received by both R1 and R2 no matter how H1 sends them (e.g., EVPN all-active), then this is no different from regular LAN case.

 R1      R2
  \      /
   \    /
    \  /
     H1

If R1 and R2 cannot see each other on the "LAN", and the reports sent by H1 to R1 will not be seen by R2, then this is no different from p2p case. There is one caveat - if H1 was originally sending reports to R1 and then switches to R2 (e.g. the hashing result changed), then H1 needs to send leaves to R1 - otherwise it'll receive duplicate traffic until R1 times out the groups.

Jeffrey

> From: Jeffrey (Zhaohui) Zhang
> Sent: Wednesday, November 11, 2015 8:43 AM
> To: 'Antoni Przygienda' <[email-masked]>; Toerless Eckert
> <[email-masked]>
> Cc: Haoweiguo <[email-masked]>; Robert Raszuk <[email-masked]>;
> IJsbrand Wijnands <[email-masked]>; [email-masked]; [email-masked]
> So what exactly is different between MC-LAG and MHD? Is there a standard
> for MHD (besides l3 mcast aspects)? Or is it that the only missing piece
> for MHD is l3 mcast?
> 
> Jeffrey
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2015 10:51:23 -0800

Maybe Tony can detail. In current IETF RFC/drafts, MHD is only used in the VPN context.
AFAIK, we have so far not talked about BIER in l2 switched contexts. Of course,
one could replace p2mp LSP (via mLDP) as used in EVPN with BIER, but i am
unclear if thats what Tony is talking aout, and i also wouldn't see a problem
doing this.

Cheers
    Toerless

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 11 Nov 2015 19:59:52 +0000

Tony,

We're converging :-) (see my earlier email on this).

Please see below.

> Sent: Wednesday, November 11, 2015 2:14 PM
> To: Toerless Eckert <[email-masked]>; Jeffrey (Zhaohui) Zhang
> <[email-masked]>
> MC-LAG is see used in L2 context mostly and it mostly implies LACP and
> often proprietary inter-chassis protocols as well.
> 
> MHD I saw used as generic term in L2/L3 and it does not imply any
> protocols and it seems to imply that both routers homed into do not see
> each other on the same ether.

Right - if they do not see each other, it makes DR election difficult (if not impossible).

> 
> Yes, we are supposed to write something about eVPN using BIER (Ice, I
> forgot, who agreed to write something & do we add it to the MVPN draft
> simply ?).
> EVPN will not have a MHD problem ;-) since
> 	a) the EVPN running router will originate the PMSI for EVPN and have
> a BFER bit.
> 	b)  hosts behind the router will be managed by the EVPN multi-homing
> procedures (split-horizon and DF) which solve the problem even if the PMSI
> delivers the frame to multiple routers homing a device on an ESI.

Right - from L3 point of view, this is a regular LAN.

> 
> The problem  exists only for PIM overlay over BIER (or other overlays
> without DF procedures).
> 
> So, I'd talk about MHD and consider the problem where a device is MHD'ed
> via 2 p2p links into 2 different routers, both in same BIER domain as the
> most generic problem.

Right - but now you can replace BIER with PIM as well :-)

> Observe that both routers will receive the traffic
> for same G since both may have beside the MHD device SHD devices that need
> to be served.

But only one should have membership reports for a particular G or (S,G) - unless the host switches to another router when sending joins - as I mentioned in the earlier email.

> So the MHD device must be under some set of DF procedures
> (and possibly split-horizon, observe that the device injecting the traffic
> may see it again from ther other router who'll receive it across BIER for
> its SHD devices and is DF for the G).  Most people who don't deal with
> EVPN will have probably trouble parsing that stuff ...

I happen to be plugged in EVPN BUM stuff and can parse the above, but I believe this is where we want to solve it by PIM overlay - it's there already. I understand that Ice's original intention is to simply run IGMP/MLD over the virtual LAN (simulated by BIER) but for this kind of situation, it's better to rely on PIM.

Jeffrey

> 
> Now, whether the problem needs solving in its generality for IP S,G
> multicast overlay (like EVPN did for L2) is something I have not much
> opinion on and leave it to heavy-weights like Ice to argue ...
> 
> thanks
> 
> --- tony
> > Sent: Wednesday, November 11, 2015 10:51 AM
> > To: Jeffrey (Zhaohui) Zhang
> > Cc: Antoni Przygienda; Haoweiguo; Robert Raszuk; IJsbrand Wijnands;
> > [email-masked]; [email-masked]
> > Maybe Tony can detail. In current IETF RFC/drafts, MHD is only used in
> the
> > VPN context.
> > AFAIK, we have so far not talked about BIER in l2 switched contexts. Of
> > course, one could replace p2mp LSP (via mLDP) as used in EVPN with BIER,
> > but i am unclear if thats what Tony is talking aout, and i also wouldn't
> see a
> > problem doing this.
> >
> > Cheers
> >     Toerless
> >
> for
> > MHD is l3 mcast?
> > > > <[email-masked]>; Robert Raszuk <[email-masked]>; IJsbrand
> > > > Wijnands <[email-masked]>; [email-masked]
> > > > That's why I don't use MC-LAG, we talk MHD.  We have MHD, we have
> > > > the problem and we need  a protocol between the two homes to elect
> DF.
> > > >
> > > > Do I miss anything ?
> > > >
> > > > thanks
> > > >
> > > > --- tony
> > > > "Simple, clear purpose and principles give rise to complex and
> > > > intelligent behavior. Complex rules and regulations give rise to
> > > > simple and stupid behavior."
> > > > --- Dee Hock
> > > >
> > > >
> > > > > Cc: Haoweiguo; Jeffrey (Zhaohui) Zhang; Robert Raszuk; IJsbrand
> > > > > Wijnands; [email-masked]
> > > > > Can you elaborate (picture, packet flow) how you imagine MC-LAG to
> > > > > be used with BIER ?
> > > > >
> > > > > another one is multi-homed device. For multi-homed network, the
> > > > > network is a LAN, DR/DF mechanism can be used to select one router
> > > > > as master and other routers as slave, only the master router can
> > > > > forward traffic to
> > > > the LAN
> > > > > the new DR/DF election mechanism should also cover the MC-LAG
> > > > > multi- homed scenario.
> > > > > >
> > > > > > [Tony saiz:] yeah, pretty much what I sent out as well.  MHD is
> > > > > > the proper term for the scenario (or MC-LAG but I don't like to
> > > > > > use that, people see LACP immediately ;-)
> > > > > >
> > > > > >
> > > > > >
> > > > > > Tony
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > My two cents.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > weiguo
> > > > > >
> > > > > > 1. True multihoming ... each edge router connect to CEs over
> > > > > > different subnet
> > > > > >

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2015 12:20:55 -0800

On Wed, Nov 11, 2015 at 07:14:24PM +0000, Antoni Przygienda wrote:
> MC-LAG is see used in L2 context mostly and it mostly implies LACP and often proprietary inter-chassis protocols as well. 
> MHD I saw used as generic term in L2/L3 and it does not imply any protocols and it seems to imply that both routers homed into do not see each other on the same ether. 

Ok, my understand was exactly the opposite. MHD in IETF was just EVPN == L2,
MC-LAG == any service (L2/L3 via multi-chassis, vendor specific).

> Yes, we are supposed to write something about eVPN using BIER (Ice, I forgot, who agreed to write something & do we add it to the MVPN draft simply ?).  

Ok, so thats not BIER end-to-end in EVPN,  but BIER to replace eg: mLDP for
p2mp LSPs in EVPN. That should be just fine. RFC7432 mentions RSVP-TE P2MP,
so the BGP signaling should already allow to know the necessary BFER.

> 	a) the EVPN running router will originate the PMSI for EVPN and have a BFER bit. 
> 	b)  hosts behind the router will be managed by the EVPN multi-homing procedures (split-horizon and DF) which solve the problem even if the PMSI delivers the frame to multiple routers homing a device on an ESI. 

Right. 

> The problem  exists only for PIM overlay over BIER (or other overlays without DF procedures). 
> 
> So, I'd talk about MHD and consider the problem where a device is MHD'ed via 2 p2p links into 2 different routers, both in same BIER domain as the most generic problem. Observe that both routers will receive the traffic for same G since both may have beside the MHD device SHD devices that need to be served. So the MHD device must be under some set of DF procedures (and possibly split-horizon, observe that the device injecting the traffic may see it again from ther other router who'll receive it across BIER for its SHD devices and is DF for the G).  Most people who don't deal with EVPN will have probably trouble parsing that stuff ... 

With EVPN out of the picture, there seems to be no standard for
MHD MC-LAG, so nothing we can do in the IETF about it IMHO.

> Now, whether the problem needs solving in its generality for IP S,G multicast overlay (like EVPN did for L2) is something I have not much opinion on and leave it to heavy-weights like Ice to argue ... 

Definitely want to support BIER with multi-chassis.
But its all vendor/platform proprietary work, nothing AFAIK that could be standardized.

Thanks
    Toerless
> "Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior." 
> --- Dee Hock 
> 
> 
> > but i am unclear if thats what Tony is talking aout, and i also wouldn't see a
> > problem doing this.
> > 
> > Cheers
> >     Toerless
> > 
> > for MHD (besides l3 mcast aspects)? Or is it that the only missing piece for
> > MHD is l3 mcast?
> > >
> > > Jeffrey
> > >
> > > > the problem and we need  a protocol between the two homes to elect DF.
> > > >
> > > > Do I miss anything ?
> > > >
> > > > thanks
> > > >
> > > > --- tony

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 11 Nov 2015 20:31:53 +0000

Please see zzh> below.

> Sent: Wednesday, November 11, 2015 3:16 PM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Toerless Eckert
> <[email-masked]>
> Cc: Haoweiguo <[email-masked]>; [email-masked]; IJsbrand Wijnands
> <[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>
> > > protocols and it seems to imply that both routers homed into do not
> > > see each other on the same ether.
> >
> > Right - if they do not see each other, it makes DR election difficult
> (if not
> > impossible).
> 
>  [Tony saiz:]  well, both routers have to run _something_ as peers,
> BGP/PIM/whatever in which they can exchange the knowledge that they MHD ...

Zzh> That may be considered as a heavy hammer, too :-)

> 
> > > procedures (split-horizon and DF) which solve the problem even if the
> > > PMSI delivers the frame to multiple routers homing a device on an ESI.
> >
>  [Tony saiz:]  +1
> > > So, I'd talk about MHD and consider the problem where a device is
> > > MHD'ed via 2 p2p links into 2 different routers, both in same BIER
> > > domain as the most generic problem.
> >
>  [Tony saiz:]  +1
> > > Observe that both routers will receive the traffic for same G since
> > > both may have beside the MHD device SHD devices that need to be
> > > served.
> >
> > But only one should have membership reports for a particular G or (S,G)
> -
> > unless the host switches to another router when sending joins - as I
> > mentioned in the earlier email.
> 
>  [Tony saiz:]  I see. If it's the MHD device responsibility to send the
> JOIN or IGMP only on a single link, we don't need split-horizon. That of
> course will imply significant delay on multicasdt on link failure and I
> would have to think whether the MHD will even know which links form a
> 'multi-homing-group' (pretty much equivalent of ESI).  In EVPN this is
> configured on the PE routers.

My understanding is that in LAG case, the MHD device only sends traffic (data or control) out of one interface.
In PIM, a router can send joins to both upstream routers (MoFRR), but it is this router's job to discard duplicate traffic, not the upstream router's job.

> 
> > > So the MHD device must be under some set of DF procedures (and
> > > possibly split-horizon, observe that the device injecting the traffic
> > > may see it again from ther other router who'll receive it across BIER
> > > for its SHD devices and is DF for the G).  Most people who don't deal
> > > with EVPN will have probably trouble parsing that stuff ...
> >
> > I happen to be plugged in EVPN BUM stuff and can parse the above, but I
> > believe this is where we want to solve it by PIM overlay - it's there
> already. I
> > understand that Ice's original intention is to simply run IGMP/MLD over
> the
> > virtual LAN (simulated by BIER) but for this kind of situation, it's
> better to rely
> > on PIM.
> 
> [Tony saiz:] Mandating PIM is a pretty heavy hammer to solve the problem
> if you ask me ...

The EVPN procedure is also a heavy hammer :-) it involves BGP, identification of each MH'ed Ethernet Segment, and additional forwarding semantics (a label in the packet to identify the source segment, and forwarding logic to discard the traffic if it is from the same segment).

Jeffrey

> -- tony

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Nov 2015 12:37:30 -0800

Below...

On Wed, Nov 11, 2015 at 08:05:48PM +0000, Antoni Przygienda wrote:
> OK< so here I need referesh on IP multicast a tad (PIM joins).
> 
> Assuming MHD host runs PIM: I thought RPF only checks whether packet arrived on one of the interfaces that the JOIN went out on (reverse-path). If we are MHD in most generic case, we???d need to PIM JOIN on both interfaces (otherwise multicast is not multi-homed) and with that RPF won???t work.  Or do we assume MHD host will only join on one interface ?
> 
> And worse, if host uses IGMP, does IGMP even do RPF ? Not that I ever saw that but again, I???m a real light-weight on traditional IP multicast ;-)
> 
> thanks
> 
> --- tony

I thought the MHD definition was still L2, aka: the MHD device sees a
single L2 etherchannel. That means it sens one PIM join and in general
doesn't even have to care which link it goes to, and the traffic
coming back could be from either interfaces. Thats the MHD case
i think we can ignore because as said in my last email, its either EVPN
(not an L3 service), or proprietary.

If the two uplinks are L3, then what you are saying about sending
joins out of both interfaces is what we do with MoFRR. MHD device will
get traffic from both links and is eliminating duplicates. This case
would be relevant to the DR/DF discussion because so far MoFRR is
really only known to be used with PIM. No reson why it couldn't be
used with IGMP/MLD though. No real changes either.

Without MoFRR, you have two uplinks and use RPF selection to determine
to which of the two links you want to send the PIM join, and thats the
link you'll then get traffic from. If we want to get rid of PIM,
we could do the same with IGMP except that there  is no standard
explaining how to do RPF for IGMP . There is draft-asaeda-pim-multiif-igmpmldproxy.

I am not sure if Ice meant to replace PIM when the client behind the
BFER is an actual router that can run PIM.
I was reading Ice's proposal for DR/DF changes to apply to the
case twhere the clients are really hosts, which means they
do not need MoFRR, and do not have L3 redundant links. At most,
we'd have servers connected via etherchannel, those would be "MHD",
but they'd have to end up in a single logical BFER, and if thats
multi-chassis then thats platform/vendor specific.

Cheers
    Toerless

> ???Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.???
> --- Dee Hock
> 
> From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
> Sent: Wednesday, November 11, 2015 12:01 PM
> To: Tony Przygienda; Antoni Przygienda
> Cc: Toerless Eckert; Haoweiguo; [email-masked]; IJsbrand Wijnands; [email-masked]; Robert Raszuk
> PIM RPF ???
> From: Tony Przygienda [mailto:[email-masked]]
> Sent: Wednesday, November 11, 2015 2:59 PM
> To: Antoni Przygienda <[email-masked]<mailto:[email-masked]>>
> Cc: Toerless Eckert <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Haoweiguo <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>
> Having thought about it a bit, the src address on the frame should be enough to serve as split horizon (absent NAT'ing) and a MHD device should drop any frame originating @ any of its interface addresses (unless I missed something here).
> 
> On Wed, Nov 11, 2015 at 11:14 AM, Antoni Przygienda <[email-masked]<mailto:[email-masked]>> wrote:
> > From: Toerless Eckert [mailto:[email-masked]<mailto:[email-masked]>]
> > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> > > > From: Antoni Przygienda [mailto:[email-masked]<mailto:[email-masked]>]
> > > > To: Toerless Eckert <[email-masked]<mailto:[email-masked]>>
> > > > Cc: Haoweiguo <[email-masked]<mailto:[email-masked]>>; Jeffrey (Zhaohui) Zhang
> > > > <[email-masked]<mailto:[email-masked]>>; Robert Raszuk <[email-masked]<mailto:[email-masked]>>; IJsbrand
> > > > Wijnands <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > > > > From: Toerless Eckert [mailto:[email-masked]<mailto:[email-masked]>]
> > > > > Wijnands; [email-masked]<mailto:[email-masked]>
> > > > > > From: Jeffrey (Zhaohui) Zhang [[email-masked]<mailto:[email-masked]>]
> > > > > > Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > > > > > From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Haoweiguo
> > > > > > To: Robert Raszuk <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>;
> > > > > > IJsbrand Wijnands <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > > > > > Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > > > > > From: BIER [[email-masked]<mailto:[email-masked]>] on behalf of Robert Raszuk
> > > > > > [[email-masked]<mailto:[email-masked]>]
> > > > > > Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> > > > > > [email-masked]<mailto:[email-masked]>
> > > > > Toerless Eckert, [email-masked]<mailto:[email-masked]>
> >
> > --
> > ---
> > Toerless Eckert, [email-masked]<mailto:[email-masked]>
> 
> [email-masked]<mailto:[email-masked]>
> We???ve heard that a million monkeys at a million keyboards could produce the complete works of Shakespeare; now, thanks to the Internet, we know that is not true.
> ???Robert Wilensky

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 11 Nov 2015 20:42:26 +0000

[The message is getting too long for the PIM mailing list, so I pruned some text]

It’s not that the senders/receivers run PIM. It’s the routers. In this case, if we’re running BIER, then only edge BFRs need to run PIM to handle “split horizon”. From PIM’s point of view, the BIER network is a virtual LAN, much like the Rose-MVPN.

Consider the following plain PIM:

Src

   R1 R2
\ /
R3
|
Rcvr

R3 normally only send join towards either R1 or R2, and expect traffic arrive on the corresponding interface. With MoFRR, it could send join to both R1 and R2, but it is R3’s job to discard duplicate traffic, not R1/2’s job.

Jeffrey

From: Antoni Przygienda [mailto:[email-masked]]
Sent: Wednesday, November 11, 2015 3:06 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Tony Przygienda <[email-masked]>
Cc: Toerless Eckert <[email-masked]>; Haoweiguo <[email-masked]>; [email-masked]; IJsbrand Wijnands <[email-masked]>; [email-masked]; Robert Raszuk <[email-masked]>
Subject: RE: [Bier] DR election ...

Assuming MHD host runs PIM: I thought RPF only checks whether packet arrived on one of the interfaces that the JOIN went out on (reverse-path). If we are MHD in most generic case, we’d need to PIM JOIN on both interfaces (otherwise multicast is not multi-homed) and with that RPF won’t work.  Or do we assume MHD host will only join on one interface ?

And worse, if host uses IGMP, does IGMP even do RPF ? Not that I ever saw that but again, I’m a real light-weight on traditional IP multicast ;-)

thanks

--- tony
_____________________________________________
“Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.”
--- Dee Hock

Cc: Toerless Eckert; Haoweiguo; [email-masked]<mailto:[email-masked]>; IJsbrand Wijnands; [email-masked]<mailto:[email-masked]>; Robert Raszuk

PIM RPF ☺

thanks

--- tony