Re: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv

[Wen Lin <[e-mail]>]

Hi Sandy,

Also for inter-subnet traffic, if there is no trace of MAC/IP in the EVPN network due PE1 node/access link failure, PE4 cannot just use flood to reach the destination host - PE4 has to ARP first to find out MAC/IP binding before it can send traffic to the destination host.

Thanks,
Wen

From: BESS <[e-mail]> on behalf of Ryan Bickhart <rbickhart=[e-mail]>
Date: Friday, March 29, 2019 at 3:39 PM
To: Sandy Breeze <sandy.breeze=[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv

Hi Sandy,

It is intentional that PE4 sees an RT2 for the CE1 MAC/IP advertised from PE2 and PE3 as well as PE1. The reason is that we want to cover the transition cases of link or node failure occurring on PE1. PE4 might be using CE1's IP carried in the RT2 for IRB or routing purposes and it is desirable for PE4 to maintain constant awareness of the existence of the CE1 IP across failures on PE1. Under normal 7432 behavior, if PE1 were the only PE advertising the RT2 for CE1's MAC/IP and PE1's link to the multihomed site goes down, PE1 might withdraw the RT2 before PE2/PE3 are able to learn the CE1 IP->MAC binding in the data plane and advertise it as a RT2 to PE4. By having PE2/PE3 originate the proxy advertisements, we avoid the case where the CE1 MAC/IP might completely disappear and later reappear in the EVPN when there is a failure on PE1. (Maybe a general L2 way of phrasing this concept is that you can do aliasing only for entities that you know about. If there is no trace of a MAC's existence left in the EVPN, you would flood rather than use aliasing.)

Thanks,
-Ryan




Juniper Internal
From: BESS <[e-mail]> On Behalf Of Sandy Breeze
Sent: Thursday, March 28, 2019 3:53 AM
To: [e-mail]
Subject: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv

Hi Wen,

First, thank you for this work, I see the problem you’re trying to solve and support trying to do that.  I have some questions.

Lets say for example, PEs: 1,2,3 have CE1 attached on the same all-active ES.  PE4 is a remote PE participating in the same EVPN.  CE1’s MAC/IP is learned in the dataplane by PE1 only, and PE1 originates the RT2 initially.

At this point, with standard 7432 mechanisms, PE4 can already have aliasing and backup paths to CE1 via PEs 2 and 3 without the need to see an RT2 from either PE2 or PE3.  What PE2 and PE3 might be missing locally, however, is ARP/ND state for CE1, which is and which your draft looks to solve in BGP.  (If my understanding is correct?)

Now if PE2 and PE3 support the proxy-adv mechanism, then they sync ARP/ND upon receipt of the RT2 from PE1.  Why do PE2 and PE3 then need to originate their own RT2?  If they originate RT2’s then this can influence the forwarding decisions at other remote PE’s like PE4, who lets say doesn’t understand the proxy-adv bit in the ARP/ND extended community and will see the RT2 as originating from 3 different PE’s.  Is that the intention of the draft or just a consequence?  Or is it the intention to keep the proxy-adv mechanism for use amongst the multihomed PE’s only?

Thanks
Sandy