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 <bess-boun...@ietf.org> On Behalf Of Ryan Bickhart
Sent: Friday, March 29, 2019 3:38 PM
To: Sandy Breeze <sandy.breeze=40eu.clara....@dmarc.ietf.org>; bess@ietf.org
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 <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of
Sandy Breeze
Sent: Thursday, March 28, 2019 3:53 AM
To: bess@ietf.org<mailto:bess@ietf.org>
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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
