Subject: [Bier] DR election ...

From: Robert Raszuk <[email-masked]>
Date: Fri, 6 Nov 2015 09:36:05 +0900

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.

---

From: Haoweiguo <[email-masked]>
Date: Fri, 6 Nov 2015 00:38:42 +0000

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]
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.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 9 Nov 2015 15:08:51 +0000

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]>; IJsbrand Wijnands <[email-masked]>
Cc: [email-masked]
Subject: Re: [Bier] DR election ...

Thanks,

weiguo

Cc: [email-masked]<mailto:[email-masked]>

Ice,

Cheers,
R.

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 9 Nov 2015 09:16:04 -0800

On Mon, Nov 9, 2015 at 7:08 AM, Jeffrey (Zhaohui) Zhang <[email-masked]>
wrote:

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

+1

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

+1

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 9 Nov 2015 16:15:11 -0800

Everybody seem to agree that this should technically be discussed
in PIM-WG, but the fact that this thread happens on BIER proves Ice's point
on the microphone in yokohama: BIER has the most active community caring about this.

On Mon, Nov 09, 2015 at 09:16:04AM -0800, Tony Przygienda wrote:
> > 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.
> >
> 
> +1
> 
> 
> > - While Ice???s DR election draft was triggered from using IGMP/MLD to

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

-- 
---
Toerless Eckert, [email-masked]

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 10 Nov 2015 00:57:09 +0000

Yupp, whoever will push the work forward will get the work done ... 

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 

> 
> Everybody seem to agree that this should technically be discussed in PIM-
> WG, but the fact that this thread happens on BIER proves Ice's point on the
> microphone in yokohama: BIER has the most active community caring about
> this.
> 
> > > 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.
> > >
> >
> > +1
> >
> >
> > > - 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.
> > >
> >
> > +1
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 9 Nov 2015 17:09:18 -0800

I am mostly worried that this will turn out to be more work than
what the first draft makes it look like. If we want to get rid of PIM,
we have to somehow understand how to route multicast between
multiple LANs connected to the same router. If serious router have
to start figuring out how to operte from the IGMP proxy routing RFC that's
not good.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Nov 2015 11:04:40 +0100

Hi Jeffrey,

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

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 ?

Many thx,
r.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 10 Nov 2015 12:02:39 +0100

Hi Robert,

I thought some more about this topic after our discussion at IETF.

VRRP is probably not good to use because it is possible there is a router on the LAN that may not be BIER capable, but will be elected by VRRP to be the default gateway for unicast. Also, it is very likely we want to define a per Group based DR election to share the load if there are multiple BIER capable routers on the LAN. It does not seem right to modify VRRP to support that.

Thx,

Ice.

> On 10 Nov 2015, at 11:04, Robert Raszuk <[email-masked]> wrote:
> 
> 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 ? 
> 
> 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. 
> 
> 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 ?
> 
> Many thx,
> r.
> 
> 
> 
>

---

From: Haoweiguo <[email-masked]>
Date: Tue, 10 Nov 2015 12:18:39 +0000

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.

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]
Subject: RE: [Bier] DR election ...

- 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

Thanks,

weiguo

Ice,

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Nov 2015 14:10:21 +0100

Hi Ice,

Well to be clear I am not suggesting to modify VRRP here.

I am simply observing that unicast and multicast forwarding will be
different and likely multicast may use unicast standby router.

Perhaps this is ok .... but I am not sure if this is desired operationally.

Cheers,
r.

On Tue, Nov 10, 2015 at 12:02 PM, IJsbrand Wijnands <[email-masked]> wrote:

> VRRP is probably not good to use because it is possible there is a router
> on the LAN that may not be BIER capable, but will be elected by VRRP to be
> the default gateway for unicast. Also, it is very likely we want to define
> a per Group based DR election to share the load if there are multiple BIER
> capable routers on the LAN. It does not seem right to modify VRRP to
> support that.
>
> Thx,
>
> Ice.
>
> > 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
> >
> > 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 ?
> >
> > Many thx,
> > r.
> >
> >
> >
> >
>
>

---

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,

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.

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

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: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 10 Nov 2015 15:09:41 +0000

>From the draft it seems that active-stanby is the requirement?

Regarding active-active, I don't know how that would work with BIER. The goal of active-active is typically to have all links utilized. Looking at draft-wijnands-bier-mld-lan-election, R3 could be the DR for some flows/services and R4 would be the DR for other flow/services, but how do you define/configure/share the service/flow?

Regards,
Reshad.

From: BIER <[email-masked]<mailto:[email-masked]>> on behalf of "Jeffrey (Zhaohui) Zhang" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 10, 2015 at 12:08 AM
To: Haoweiguo <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, "IJsbrand Wijnands (iwijnand)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] DR election ...

Jeffrey

To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>>

Thanks,

weiguo

From: BIER [[email-masked]<mailto:[email-masked]>] on behalf of Robert Raszuk [[email-masked]<mailto:[email-masked]>]

Ice,

Cheers,
R.

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 10 Nov 2015 18:49:21 +0000

+ you have the case where both routers are on a different LAN but both are BIER capable and hook into same BIER domain ...  and yepp, I can show you the case easily (or read my previous email) where both routers must receive traffic for same G and will duplicate unless something is done ... 

Generic election is not per G (that's just load carving), the general election is per <G,bunch of ethers multi-homing> really. Problem more complex than it looks, it's really EVPN DF in another cloth ... 

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: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands
> Sent: Tuesday, November 10, 2015 3:03 AM
> To: Robert Raszuk
> Cc: Jeffrey (Zhaohui) Zhang; Haoweiguo; [email-masked]
> VRRP is probably not good to use because it is possible there is a router on
> the LAN that may not be BIER capable, but will be elected by VRRP to be the
> default gateway for unicast. Also, it is very likely we want to define a per
> Group based DR election to share the load if there are multiple BIER capable
> routers on the LAN. It does not seem right to modify VRRP to support that.
> 
> Thx,
> 
> Ice.
> 
> 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.
> >
> >
> >
> 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.
> >

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 10 Nov 2015 18:50:29 +0000

You can't use active-active unless you start to alias, not an easy thing to do ...

thanks

--- tony

From: BIER [mailto:[email-masked]] On Behalf Of Reshad Rahman (rrahman)
Sent: Tuesday, November 10, 2015 7:10 AM
To: Jeffrey (Zhaohui) Zhang; Haoweiguo; Robert Raszuk; IJsbrand Wijnands (iwijnand)
Cc: [email-masked]
Subject: Re: [Bier] DR election ...

Regards,
Reshad.

Jeffrey

Thanks,

weiguo

Ice,

Cheers,
R.

---

From: Antoni Przygienda <[email-masked]>
Date: Tue, 10 Nov 2015 18:52:22 +0000

Hi Jeffrey,

[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

Jeffrey

Thanks,

weiguo

Ice,

Cheers,
R.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 10 Nov 2015 14:47:03 -0800

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

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 11 Nov 2015 01:17:12 +0000

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

> 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]
> Can you elaborate (picture, packet flow) how you imagine MC-LAG to be
> used with BIER ?
> 
> 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
> 
> 
> > 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
> >
> > - 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
> > To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>;
> > IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>>
> > As we duscussed offline there are practically two major types of
> multihomed deployments in production networks:
> >
> > 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.
>

---

From: Haoweiguo <[email-masked]>
Date: Wed, 11 Nov 2015 06:19:59 +0000

Yes, i also think MHD is more accurate than MC-LAG. The first impression for MC-LAG is a proprietory technology. Currently in PIM WG, maybe there are no good existed solutions for MHD. I also suggests that we had better cover this scenario in future solutions.

thanks,
weiguo

________________________________________
From: Antoni Przygienda [[email-masked]]
Sent: Wednesday, November 11, 2015 9:17
To: Toerless Eckert
Cc: Haoweiguo; Jeffrey (Zhaohui) Zhang; Robert Raszuk; IJsbrand Wijnands; [email-masked]
Subject: RE: [Bier] DR election ...

Do I miss anything ?

thanks

--- tony

---

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

> 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]
> 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
> 
> 
> forwarding, and
> > > I agree with Robert's comments. I think BIER also should cover active-
> active
> > and active-standby access scenarios.
> > >
> > > Thanks,
> > >
> > > weiguo
> > >

---

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
> 
> > > network, IGMP/MLD extension can be used for the DR/DF election, this
> is
> > the
> > > source or receiver is directly accessed to two multicast routers
> through
> > MC-
> > > routing underlay. It is really the multicast overlay's job to handle
> the
> > multi-
> > > some BIER keywords in it, it is really independent of BIER. The draft
> is
> > still

---

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: Antoni Przygienda <[email-masked]>
Date: Wed, 11 Nov 2015 19:14:24 +0000

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. 

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. 

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

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]
> 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 (besides l3 mcast aspects)? Or is it that the only missing piece for
> MHD is l3 mcast?
> >
> > Jeffrey
> >
> > > <[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
> > >
> > >
> > > > form of
> > > anything
> > > > 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
> > > > 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
> > > > >
> > > > > active-standby
> > > > routing underlay. It is really the multicast overlay's job to
> > > > handle the
> > > multi-
> > > > 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
> > > > > 2. Active/standby .. there is multiaccess lan but VRRP is used
> > > > > so
> > > hosts can
> > > > have single default out.
> > > > >
> > > > there will pretty much always CEs. I am worried that most BIER
> > > > slides
> > > skip
> > > > those.
> > > > >
> > > > > Cheers,
> > > > > R.
> > > >

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 11 Nov 2015 11:59:08 -0800

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]> 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.
>
> 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 ?).
>         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.
>
> 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 ...
>
> 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
> > Maybe Tony can detail. In current IETF RFC/drafts, MHD is only used in
> the
> > VPN context.
> for

-- 
*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 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]>

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

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

> most generic problem.

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

> Observe that both routers will receive the traffic
> 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
> 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

---

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

PIM RPF ☺

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

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:
MC-LAG is see used in L2 context mostly and it mostly implies LACP and often proprietary inter-chassis protocols as well.

thanks

--- tony

> 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]>]
> > > > Cc: Haoweiguo; Jeffrey (Zhaohui) Zhang; Robert Raszuk; IJsbrand
> > > > 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]>

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

--
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: Antoni Przygienda <[email-masked]>
Date: Wed, 11 Nov 2015 20:05:48 +0000

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

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
Subject: RE: [Bier] DR election ...

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]>>
Subject: Re: [Bier] DR election ...

thanks

--- tony

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 11 Nov 2015 20:16:26 +0000

> > protocols and it seems to imply that both routers homed into do not
> > see each other on the same ether.
> 

 [Tony saiz:]  well, both routers have to run _something_ as peers, BGP/PIM/whatever in which they can exchange the knowledge that they MHD ... 

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

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

-- tony

---

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

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

> 	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 devi…

Right. 

> 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 wi…

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
> > > > > Wijnands; [email-masked]

---

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]>
> > 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 :-)

>  [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.

> [Tony saiz:] Mandating PIM is a pretty heavy hammer to solve the problem

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

---

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:
> 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
> 
> PIM RPF ???
> 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 ...

thanks

--- tony

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

PIM RPF ☺

thanks

--- tony

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 11 Nov 2015 20:48:04 +0000

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

 [Tony saiz:]  +1

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

 [Tony saiz:]  If we declare BIER MHD a problem, then we can.  The according protocol can be put into BGP or PIM or something light-weight if we want to solve it from the PE side (like EVPN). Or we can simply say, it's the host problem to know which 2 links are MHD and make sure that JOINs go only one way.  Or we can declare it a 'non-problem', i.e. a MHD configuration is BIER is simply not a valid network config (unless reality proves us wrong me thinks ;-)

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

[Tony saiz:] hmm, if we want to support MHD in interoperable fashion, nothing prevents us from solving the problem in interoperable fashion ;-) 

IETF's role is to come up with protocols (bits-on-the-wire) that all vendors agree on semantically so they interop.  The semantics themselves that protocols carry allow the network to reach a usable state in certain configurations. Now, which configurations IETF declares of significance is a meta question that is above my pay-grade here. It's more like A-D type of discussion in terms of charters/working groups/recommended existing-protocol-extensions ;-) 

-- tony

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 11 Nov 2015 22:17:23 +0000

OK, all agreed. I think I got by now how you guys see the issue. I let the list run away with it and the authors of the draft-wijnands-bier-mld-lan-election drive it further.

First step is probably to define which flavor of MHD we're talking precisely (l2, l3, one ether interface, multiple interfaces on different ethers, same IP address/different) and which of those the draft is attempting to solve.  

thanks for enlightement 

--- tony

> Sent: Wednesday, November 11, 2015 12:32 PM
> To: Antoni Przygienda; Toerless Eckert
> Cc: Haoweiguo; [email-masked]; IJsbrand Wijnands; [email-masked]; Robert
> Raszuk
> > > > protocols and it seems to imply that both routers homed into do
> > > > not see each other on the same ether.
> > >
> > > > 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.
> > >
> > > > 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)
> > -
> >  [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.
> 
> 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.
> 
> >
> > > > 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
> 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: Caitlin Bestler <[email-masked]>
Date: Thu, 12 Nov 2015 13:04:54 -0800

> unclear if thats what Tony is talking aout, and i also wouldn't see a problem
I think mapping BIER to L2 forwarding is very straight-forward.

The common model for L2 forwarding has the upper layer (L3 and
above) build a forwarding table. Each entry in the forwarding table
maps an L2 destination identifier (VLAN + MAC address) to a set
of egress queue or ports.

A BIER-friendly L2 forwarding rule would map a VLAN + BIER
bit position to a set of egress queues or ports, and the forwarding
firmware should IOR the forwarding destinations for every bit that
was set in the header.

That is barely more complex than the current forwarding code.
There is very little risk that someone is going to need a larger
sized die for their ASIC. The real gotcha is that L2 forwarding
chips are not built from scratch very often. There will be foot
dragging on supporting "L2 BIER", but out of inherent inertia
rather than out of fear of implementation complexity.