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

["UTTARO, JAMES" <[e-mail]>]

Ryan,

              My take here is that we are trying to approach the notion of routing to the "customer" without actually routing.. PE2 and PE3 never receive the MAC as expected in data plane learning.. This is forcing the MAC via the origination at PE2 and PE3 to seem like it was "learned" there. The notion of EVPN was Data Plane learning to the customer, control plane learning to in the EVPN signaling domain. Why can't the state simple be persisted if there are still valid PEs ( PE2, PE3 ) the ESI.. IMO this seems to accomplish your goal without changing the paradigm. I believe the draft below comes close to what you want.. addl text would be needed to persist if ESI is valid..

Thanks,
              Jim Uttaro

https://www.ietf.org/archive/id/draft-uttaro-idr-bgp-persistence-04.txt

From: BESS <[e-mail]> On Behalf Of Ryan Bickhart
Sent: Friday, March 29, 2019 3:38 PM
To: Sandy Breeze <sandy.breeze=[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]<mailto:[e-mail]>> On Behalf Of Sandy Breeze
Sent: Thursday, March 28, 2019 3:53 AM
To: [e-mail]<mailto:[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