Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming

[Alexander Vainshtein <[e-mail]>]

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: [phone]
Cell:      [phone]
Email:   [e-mail]

From: BESS <[e-mail]> On Behalf Of Muthu Arul Mozhi Perumal
Sent: Thursday, March 7, 2019 8:53 AM
To: Luc Andre Burdet (lburdet) <[e-mail]>
Cc: chalapathi andhe <[e-mail]>; Sean Wu <[e-mail]>; Jaikumar Somasundaram <[e-mail]>; [e-mail]; [e-mail]
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) <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
Tel: [phone]






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com<http://www.cisco.com/web/CA/>







From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of chalapathi andhe <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 6, 2019 at 04:15
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Sean Wu <[e-mail]<mailto:[e-mail]>>, Jaikumar Somasundaram <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
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.
___________________________________________________________________________