Anush,
From: Anush Mohan <[email protected]>
Date: Thursday, October 4, 2018 at 5:47 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
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.
[JORGE] see my other email. In RFC7432 you can avoid mac flushing at the remote
PEs only if there are two PEs in the ES, with more than two, the remote PEs
need to flush the macs and flood:
If there is only one backup PE for a given ES, the remote PE MAY use
the primary PE's withdrawal of its set of Ethernet A-D per ES routes
as a trigger to update its forwarding entries, for the associated MAC
addresses, to point towards the backup PE. As the backup PE starts
learning the MAC addresses over its attached ES, it will start
sending MAC/IP Advertisement routes while the failed PE withdraws its
routes. This mechanism minimizes the flooding of traffic during
fail-over events.
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.
[JORGE] In RFC8214 there is a single backup PE, even with more than 2 PEs in
the ES, and that condition is signaled. We’ve had some discussions to re-use
this backup signaling in RFC7432 based EVIs, but it is not there in existing
RFC7432 networks.
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.
[JORGE] IMO it doesn’t matter much if you use a label per MAC-VRF (or per-BD)
on the ES PEs, since the labels will be the same anyway and at the egress you
do a mac-lookup anyway…
Regards
Anush
On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View)
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>>
Date: Thursday, October 4, 2018 at 1:14 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)"
<[email protected]<mailto:[email protected]>>
Cc:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
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)
<[email protected]<mailto:[email protected]>> wrote:
In-line.
Thx
Jorge
From: Jaikumar Somasundaram
<[email protected]<mailto:[email protected]>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Cc: Jiang He <[email protected]<mailto:[email protected]>>, P Muthu
Arul Mozhi
<[email protected]<mailto:[email protected]>>
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)
<[email protected]<mailto:[email protected]>>
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: Jiang He <[email protected]<mailto:[email protected]>>; P Muthu
Arul Mozhi
<[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>> on behalf of
Jaikumar Somasundaram
<[email protected]<mailto:[email protected]>>
Date: Thursday, October 4, 2018 at 10:03 AM
To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Cc: Jiang He <[email protected]<mailto:[email protected]>>, P Muthu
Arul Mozhi
<[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bess
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
