Re: [Bier] DR election ...

[Toerless Eckert <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, November 11, 2015 12:01 PM
> To: Tony Przygienda; Antoni Przygienda
> Cc: Toerless Eckert; Haoweiguo; [e-mail]; IJsbrand Wijnands; [e-mail]; Robert Raszuk
> Subject: RE: [Bier] DR election ...
> 
> PIM RPF ???
> 
> From: Tony Przygienda [mailto:[e-mail]]
> Sent: Wednesday, November 11, 2015 2:59 PM
> To: Antoni Przygienda <[e-mail]<mailto:[e-mail]>>
> Cc: Toerless Eckert <[e-mail]<mailto:[e-mail]>>; Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Haoweiguo <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; IJsbrand Wijnands <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Robert Raszuk <[e-mail]<mailto:[e-mail]>>
> 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 <[e-mail]<mailto:[e-mail]>> 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 ?).
> 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
> _____________________________________________
> "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:[e-mail]<mailto:[e-mail]>]
> > Sent: Wednesday, November 11, 2015 10:51 AM
> > To: Jeffrey (Zhaohui) Zhang
> > Cc: Antoni Przygienda; Haoweiguo; Robert Raszuk; IJsbrand Wijnands;
> > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> > Subject: Re: [Bier] DR election ...
> >
> > 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
> >
> > On Wed, Nov 11, 2015 at 01:42:50PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> > > [+ 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:[e-mail]<mailto:[e-mail]>]
> > > > Sent: Tuesday, November 10, 2015 8:17 PM
> > > > To: Toerless Eckert <[e-mail]<mailto:[e-mail]>>
> > > > Cc: Haoweiguo <[e-mail]<mailto:[e-mail]>>; Jeffrey (Zhaohui) Zhang
> > > > <[e-mail]<mailto:[e-mail]>>; Robert Raszuk <[e-mail]<mailto:[e-mail]>>; IJsbrand
> > > > Wijnands <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> > > > 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:[e-mail]<mailto:[e-mail]>]
> > > > > Sent: Tuesday, November 10, 2015 2:47 PM
> > > > > To: Antoni Przygienda
> > > > > Cc: Haoweiguo; Jeffrey (Zhaohui) Zhang; Robert Raszuk; IJsbrand
> > > > > Wijnands; [e-mail]<mailto:[e-mail]>
> > > > > Subject: Re: [Bier] DR election ...
> > > > >
> > > > > 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 [[e-mail]<mailto:[e-mail]>]
> > > > > > Sent: Monday, November 09, 2015 23:08
> > > > > > To: Haoweiguo; Robert Raszuk; IJsbrand Wijnands
> > > > > > Cc: [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>
> > > > > > 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Haoweiguo
> > > > > > Sent: Thursday, November 05, 2015 7:39 PM
> > > > > > To: Robert Raszuk <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>;
> > > > > > IJsbrand Wijnands <[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>>
> > > > > > Cc: [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>
> > > > > > Subject: Re: [Bier] DR election ...
> > > > > >
> > > > > >
> > > > > > I agree with Robert's comments. I think BIER also should cover
> > > > > > active-
> > > > active
> > > > > and active-standby access scenarios.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > weiguo
> > > > > >
> > > > > > ________________________________
> > > > > > From: BIER [[e-mail]<mailto:[e-mail]>] on behalf of Robert Raszuk
> > > > > > [[e-mail]<mailto:[e-mail]>]
> > > > > > Sent: Friday, November 06, 2015 8:36
> > > > > > To: IJsbrand Wijnands
> > > > > > Cc: [e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>
> > > > > > 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
> > > > > > [e-mail]<mailto:[e-mail]>
> > > > > > https://www.ietf.org/mailman/listinfo/bier
> > > > >
> > > > >
> > > > > --
> > > > > ---
> > > > > Toerless Eckert, [e-mail]<mailto:[e-mail]>
> >
> > --
> > ---
> > Toerless Eckert, [e-mail]<mailto:[e-mail]>
> 
> _______________________________________________
> BIER mailing list
> [e-mail]<mailto:[e-mail]>
> 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

-- 
---
Toerless Eckert, [e-mail]