Hi James,
Thank you for your comments. Please see replies inline below.
Thanks,
Wen
From: "UTTARO, JAMES"
Date: Wednesday, March 27, 2019 at 12:20 PM
To: "draft-rbickhart-evpn-ip-mac-proxy-...@ietf.org"
Cc: "bess@ietf.org"
Subject: Mail regarding draft-rbickhart-evpn-ip-mac-proxy-adv
Resent-From:
Resent-To: , , ,
Resent-Date: Wednesday, March 27, 2019 at 12:20 PM
Wen,
A few comments.
I think I understand the why of this draft. One could take the
view that a MAC/IP learned via a single PE on an ESI has actually gone away and
will not be re-learned via other PEs on said ESI.. In that case incorrectness
is being injected into the VPN state machine for said customer for as long as
it takes the timer to expire. Is that right??
Wen: This solution is more useful if the MAC/IP can be re-learned through the
data plane by other PE(s) attached to the same multihoming ES.
Generally speaking state learned via the control plane is never allowed to be
re-advertised so PE1->PE2->PEX is disallowed. I am assuming that split horizon
will be disabled for a MAC/IP learned from PE1 advertised to PE2, subsequently
advertised to PE3 ( Actually everywhere ) as the ESI is in common.
Wen: This is about PE2 originates, instead of re-advertising, a type-2 MAC+IP
advertisement based on the knowledge that the said MAC is learned in the data
plane from its locally attached multihomed ES, but through its peer PE(s).
Also in this case PE2 sets a proxy bit for the type2 MAC+IP route it originates.
You could also use BGP Persistence on PE3.. PE3 would enable persistence on
MAC/IP:NH=PE1, ESI10 if ESI10 is also available at PE2.. In this manner PE3
would continue sending traffic to MAC/IP via PE2 as long as the ESI is valid
and the timer on PE3 did not expire.
Wen: Yes, other mechanism(s) can be used to close this gap and avoid traffic
loss. The proposed solution in this draft uses EVPN method among multihomed PEs
and it does not rely on actions of other remote PEs that are not attached to
the same multihomed ES while at the same avoid traffic loss for traffic
destined to that MAC (assuming this MAC is not moved.)
Thanks,
Jim Uttaro
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
