Muthu and all, Quoting from Section 14.1.1 “Single-Active Redundancy Mode” of RFC 7432:
If the primary PE encounters a failure, it MAY withdraw its set of Ethernet A-D per ES routes for the affected ES prior to withdrawing its set of MAC/IP Advertisement routes. 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. So there are actually three sub-cases in the single-active redundancy mode use case: 1. The single-active multi-homed ES has been advertised by exactly two PEs. In this case withdrawal of the per-ES Ethernet A-D route by the primary PE may result in other PEs sending the unicast traffic for MAC addresses learned from this ES to the secondary PE using the alias labels advertised for the corresponding EVI in the per-EVI Ethernet A-D routes. 2. The single-active multi-homed ES has been advertised by three or more PEs, and flooding of unknown unicast is allowed. In this case withdrawal of the per-ES Ethernet A-D route by the primary PE MUST result in flooding of the unicast traffic with unlearned MAC addresses using the common scheme for BUM traffic. The Aliasing labels are not relevant for this use case. 3. The single-active multi-homed ES has been advertised by three or more PEs, and flooding of unknown unicast is not allowed. In this case withdrawal of the per-ES Ethernet A-D route by the primary PE MUST in just local flooding of the unicast traffic with unlearned MAC addresses. Hope this helps. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: [email protected] From: BESS <[email protected]> On Behalf Of Muthu Arul Mozhi Perumal Sent: Thursday, March 7, 2019 8:53 AM To: Luc Andre Burdet (lburdet) <[email protected]> Cc: chalapathi andhe <[email protected]>; Sean Wu <[email protected]>; Jaikumar Somasundaram <[email protected]>; [email protected]; [email protected] Subject: Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming My understanding: For the single-active case in the diagram below, when PE4 receives the A-D per ES route withdraw it won't know whether PE2 or PE3 will become the new primary/DF for the <ES, VLAN>, so it will start flooding the traffic destined to MAC1. Then either PE2 or PE3 will become the new primary/DF for the <ES, VLAN> and advertise the MAC/IP route for MAC1. PE4 will then start sending the traffic destined to MAC1 to the new primary. For the all-active case, when PE4 receives the A-D per ES route withdraw it will update the nexthop list for MAC1 by removing PE1 from that list. PE4 will then load balance the traffic destined to MAC1 by send it to PE2 and PE3 using alias label. Regards, Muthu On Wed, Mar 6, 2019 at 7:51 PM Luc Andre Burdet (lburdet) <[email protected]<mailto:[email protected]>> wrote: Hi Chalu, Please read 7432 s.8.4: in single-active it is not an aliasing label/procedure but a backup-path procedure. It will answer your questions (both, actually). There is no flooding once the MAC is learnt & distributed: cf. that’s the point. [http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png] Luc André Burdet [email protected]<mailto:[email protected]> Tel: +1 613 254 4814 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Cisco.com<http://www.cisco.com/web/CA/> From: BESS <[email protected]<mailto:[email protected]>> on behalf of chalapathi andhe <[email protected]<mailto:[email protected]>> Date: Wednesday, March 6, 2019 at 04:15 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: Sean Wu <[email protected]<mailto:[email protected]>>, Jaikumar Somasundaram <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming Hi All, Can you please help us on the following issue. In the following diagram, PE1, PE2, PE3 are connected to the same ES [ES1] in Single active mode, and PE4 is a remote PE. Let’s say PE1 is advertising the MAC1 route, PE4 will install the MAC1 with the PE1 as primary path with MAC Label, and PE2, PE3 as backup with the Alias Label. Now if the PE1 to CE1 link goes down, then PE1 withdraw the EAD/ES route which will be processed by PE4. Now what should the forwarding state at PE4 ?, PE4 should update the forwarding state of MAC1 with the PE2, PE3 Alias label and any traffic destined to MAC1 should be flooded to PE2, PE3 with the Alias labels ? Or packet should be flooded to PE2, PE3 with the Flood labels ? Or should it be some other method ? In similar if the ES is operating in all active mode, what should be the forwarding state at PE4 ? PE4 should update the forwarding state of MAC1 with the PE2, PE3 Alias label and any traffic destined to MAC1 should be sent to either PE2 or PE3 with the Alias labels [ not flood to both] ? Or packet should be flooded to PE2, PE3 with the Flood labels or Alias Label ? Or should it be some other method ? [cid:1695247dcc04ce8e91] Thanks, Chalapathi. _______________________________________________ BESS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/bess ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
