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
