Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

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.rabadan@nokia.com> wrote:

> Muthu,
>
>
>
>
>
> *From: *Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
> *Date: *Thursday, October 4, 2018 at 5:37 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com
> >
> *Cc: *"jaikumar.somasundaram@ericsson.com" <
> jaikumar.somasundaram@ericsson.com>, "bess@ietf.org" <bess@ietf.org>, "
> jiang.he@ericsson.com" <jiang.he@ericsson.com>, "
> p.muthu.arul.mozhi@ericsson.com" <p.muthu.arul.mozhi@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.rabadan@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.arul@gmail.com>
> *Date: *Thursday, October 4, 2018 at 1:14 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com
> >
> *Cc: *"jaikumar.somasundaram@ericsson.com" <
> jaikumar.somasundaram@ericsson.com>, "bess@ietf.org" <bess@ietf.org>, "
> jiang.he@ericsson.com" <jiang.he@ericsson.com>, "
> p.muthu.arul.mozhi@ericsson.com" <p.muthu.arul.mozhi@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.rabadan@nokia.com> wrote:
>
> In-line.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>
> *Date: *Thursday, October 4, 2018 at 11:28 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>,
> "bess@ietf.org" <bess@ietf.org>
> *Cc: *Jiang He <jiang.he@ericsson.com>, P Muthu Arul Mozhi <
> p.muthu.arul.mozhi@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.rabadan@nokia.com>
>
> *Sent:* Thursday, October 4, 2018 1:52 PM
> *To:* Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>;
> bess@ietf.org
> *Cc:* Jiang He <jiang.he@ericsson.com>; P Muthu Arul Mozhi <
> p.muthu.arul.mozhi@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-bounces@ietf.org> on behalf of Jaikumar Somasundaram <
> jaikumar.somasundaram@ericsson.com>
> *Date: *Thursday, October 4, 2018 at 10:03 AM
> *To: *"bess@ietf.org" <bess@ietf.org>
> *Cc: *Jiang He <jiang.he@ericsson.com>, P Muthu Arul Mozhi <
> p.muthu.arul.mozhi@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
>
>