Thanks, Jorge. In EVPN single-active dual-homing or EVPN VPWS single-active multi-homing, when other PEs realize that the DF is dead, they all need to re-run the DF election for sure. However, traffic recovery need not wait until the DF election gets over electing a new DF..it only requires the other PEs and the backup to realize the primary/DF is dead and start forward. That's my point..
Regards, Muthu On Fri, Oct 5, 2018 at 1:30 AM Rabadan, Jorge (Nokia - US/Mountain View) < jorge.raba...@nokia.com> wrote: > Muthu, > > > > > > *From: *Muthu Arul Mozhi Perumal <muthu.a...@gmail.com> > *Date: *Thursday, October 4, 2018 at 5:37 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 > > > > Thanks, Jorge. This is inline with my thinking. So, in single-active > multihoming, once the primary is dead we don't need to wait for the DF > election to happen for the backup (or some other PE in the ES) to become > active and start forwarding traffic over the ES, instead it only requires > the remote PEs and backup to realize that the primary is dead (thru' NH > tracking / BFD) and start forwarding over the ES, right? > > [JORGE] When the other PEs in the ES realize the DF is dead, they need to > remove the dead PE from the candidate list and run DF Election. You may > optimize things if you only have two PEs in the ES (such as skip the timer) > but if you have more than 2 PEs in the ES, there is really no concept of > backup PE in RFC7432, but simply the other PEs are non-DF. However, the > concept of backup PE in an ES with more than two PEs is specified in > RFC8214, where all the PEs in the ES not only elect a DF but also a backup > DF, and signal this backup condition in the AD per-EVI routes. Note this is > not there in RFC7432. > > > > Regards, > > Muthu > > > > 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
