Hi Jorge, Related to this topic, I had couple of queries as well. Could you please clarify.
1. I hope the section of RFC pasted by Jai is superceded by the particular DF algorithm used. If all PEs can decide one particular backup PE for Ethernet-segment based on HRW (for e.g), only that particular backup-PE can be used for unicasting traffic. We can avoid flushing mac-entry in this case. 2. If 'all-active' multihoming is used and a particular MAC is learnt from multiple PEs on an Ethernet-segment, should we use 'mac-ip' route label for load-balancing traffic or alias-label from 'EAD/ESI' route. Or it doesn't matter. Regards Anush On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) < jorge.raba...@nokia.com> wrote: > Muthu, > > > > About this: > > > > Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would > withdraw the routes if the primary PE / DF itself fails? Instead, the BGP > session would timeout causing the primary PE's neighbors to flush out the > A-D routes received from the primary PE, right? This can take several > seconds, isn't it? > > > > No, not in the implementations I know of. Next Hop tracking will > immediately detect that the PE is not in the network anymore and the routes > will be invalidated. You can also bootstrap the BGP sessions to BFD. > > But that has nothing to do with EVPN!.. it’s regular BGP. > > > > Thx > > Jorge > > > > *From: *Muthu Arul Mozhi Perumal <muthu.a...@gmail.com> > *Date: *Thursday, October 4, 2018 at 1:14 PM > *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com > > > *Cc: *"jaikumar.somasunda...@ericsson.com" < > jaikumar.somasunda...@ericsson.com>, "bess@ietf.org" <bess@ietf.org>, " > jiang...@ericsson.com" <jiang...@ericsson.com>, " > p.muthu.arul.mo...@ericsson.com" <p.muthu.arul.mo...@ericsson.com> > *Subject: *Re: [bess] EVPN MH: Backup node behavior in Primary Path > Failure > > > > Please see inline.. > > > > On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) < > jorge.raba...@nokia.com> wrote: > > In-line. > > > > Thx > > Jorge > > > > *From: *Jaikumar Somasundaram <jaikumar.somasunda...@ericsson.com> > *Date: *Thursday, October 4, 2018 at 11:28 AM > *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>, > "bess@ietf.org" <bess@ietf.org> > *Cc: *Jiang He <jiang...@ericsson.com>, P Muthu Arul Mozhi < > p.muthu.arul.mo...@ericsson.com> > *Subject: *RE: [bess] EVPN MH: Backup node behavior in Primary Path > Failure > > > > Thanks Jorge for the quick reply. > > Please find further question below. > > > > *From:* Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> > > *Sent:* Thursday, October 4, 2018 1:52 PM > *To:* Jaikumar Somasundaram <jaikumar.somasunda...@ericsson.com>; > bess@ietf.org > *Cc:* Jiang He <jiang...@ericsson.com>; P Muthu Arul Mozhi < > p.muthu.arul.mo...@ericsson.com> > *Subject:* Re: [bess] EVPN MH: Backup node behavior in Primary Path > Failure > > > > Hi, > > > > Questions: > > 1. Will the node in backup mode forward the packet to CE? > > [JORGE] as soon as it becomes DF it can forward packets to the CE. The > backup node will have to run DF election upon the ES route withdrawal from > the primary. If AC-DF is enabled, it can also react to the withdrawal of AD > routes from the primary PE. > > *[Jai] Does that mean if any packet comes to a node that is still in the > backup mode will get dropped, before the new DF election is complete? Why > cant this be used as FRR? Or what is the use case of having backup node(s)?* > > *[JORGE2] when the primary node fails, ES and AD routes are withdrawn. * > > Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would > withdraw the routes if the primary PE / DF itself fails? Instead, the BGP > session would timeout causing the primary PE's neighbors to flush out the > A-D routes received from the primary PE, right? This can take several > seconds, isn't it? > > > > Regards, > > Muthu > > *The AD route withdrawal is an indication for remote nodes that they have > to send traffic to the backup (for a given MAC) or to flush the MACs if > there are more than 2 PEs in the ES. Around the same time or maybe earlier, > the ES route withdrawal will make the backup PE take over as DF. So the > overall convergence time will depend on how/when those two things happen in > time. Only the DF PE can forward traffic. A non-DF can never forward > traffic or there will be risk of duplicate packets.* > > > > 2. Will all the nodes in backup mode forward the packet before DF > election? > > [JORGE] Only the new DF can forward. > > > > 3. If they forward, how is duplicate packets handled, in this case? > > [JORGE] see above. > > > > My two cents.. > > > > Thanks. > > Jorge > > > > > > > > *From: *BESS <bess-boun...@ietf.org> on behalf of Jaikumar Somasundaram < > jaikumar.somasunda...@ericsson.com> > *Date: *Thursday, October 4, 2018 at 10:03 AM > *To: *"bess@ietf.org" <bess@ietf.org> > *Cc: *Jiang He <jiang...@ericsson.com>, P Muthu Arul Mozhi < > p.muthu.arul.mo...@ericsson.com> > *Subject: *[bess] EVPN MH: Backup node behavior in Primary Path Failure > > > > Hello Everyone, > > > > Sorry if it is a duplicate. I repost this query as I did not receive any > response yet. > > (I was wondering if this mail already reached the group or not) > > > > I have a question on Primary PE encountering a failure in EVPN multihoming > > in single active mode. > > > > RFC7432, section 14.1.1: > > <snip> > > If there is more than one backup PE for a given ES, the remote PE > > MUST use the primary PE's withdrawal of its set of Ethernet A-D per > > ES routes as a trigger to start flooding traffic for the associated > > MAC addresses (as long as flooding of unknown unicast packets is > > administratively allowed), as it is not possible to select a single > > backup PE. > > </snip> > > > > Questions: > > 1. Will the node in backup mode forward the packet to CE? > > 2. Will all the nodes in backup mode forward the packet before DF election? > > 3. If they forward, how is duplicate packets handled, in this case? > > > > Please help me anwere these questions. > > > > Thanks & Regards > > Jaikumar S > > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess