Hi, I agree w/ Jorge's proposal.
Yours Irrespectively, John > -----Original Message----- > From: BESS <[email protected]> On Behalf Of Rabadan, Jorge (Nokia - > US/Mountain View) > Sent: Monday, November 5, 2018 4:45 AM > To: [email protected]; [email protected] > Subject: [bess] About draft-brissette-bess-evpn-l2gw-proto-03 > > Dear authors, > > Some comments about this draft: > > 1- the draft uses some 'non-standard' terminology. Could you use RFC7432 > terminology please? An example of 'non-standard' term is EVLAG. > > 2- the draft proposes a solution for something that works today without the > need of a multi-homed Ethernet Segment or any new procedures: > - There are already EVPN deployments that use STP/G.8032 access rings. > - The two EVPN PEs that close the ring can participate of the ring protocol, > therefore the received mac flush messages will withdraw the required > MAC/IP routes. > - Since the remote PEs will forward normally based on their MAC FIB > (populated by MAC/IP routes), there is no need to specify a new "Single Flow > Active" forwarding mode. This is normal MAC based forwarding. Why do we > need to create a new mode?? Can you please explain? > - Besides, by adding a bit in the ESI-label ext community different than the > single-active bit, you make the solution non-backwards compatible. > > 3- Section 6 - why do you define yet another extended community for mac > flush, when we already have one? (RFC7623) > > 4- there is some value in the proposal though - the mass withdrawal (per-BD > or per-ES) as opposed to per-MAC withdrawal may speed up convergence. > Here is an alternative solution that can achieve the same thing and it's > backwards compatible with RFC7432: > > On the L2GWs: > a) Define a single-homed non-zero ESI per L2GW PW. The ESI can be auto- > derived easily as type 3/4 and be made unique in the network. > b) Since the ES is defined in a single PE, the ES routes will be filtered by > the RR > (use RTC) and won't ever reach other PEs. Alternatively you can disable the > ES routes. > c) This L2GW ES will be single-active mode (although it does not matter > much). > d) Since the ES is not shared across the L2GWs, each L2GW will always be DF > for all the local VLANs. > e) Each L2GW will send AD per-ES and per-EVI routes for its ESI. > f) When the L2GW receives a mac-flush notification (STP TCN, G.8032 mac- > flush, TLDP MAC withdrawal etc.), the L2GW sends an update of the AD per- > EVI route with the MAC Mobility extended community and a higher sequence > number - note that we borrow this well-known mac flush procedure from > RFC7623, only for AD per-EVI routes. > > On the remote PEs: > g) The MACs will be learned against the ESIs, but there will only be one next- > hop per ES. No aliasing or no backup. And RFC7432-compatible. > h) Upon receiving an AD per-EVI update with a higher SEQ number, the PE > flushes all the MACs for the BD. If the PE does not understand the MAC > Mobility ext comm in the AD per-EVI route, it won't do anything and will > simply flush MACs based on MAC/IP route withdrawals. > i) Upon receiving an AD per-ES route withdrawal the PE will do mass > withdrawal for all the affected BDs (this is the case where the L2GW local ES > goes down). > > Please let me know your comments. > > Thank you. > Jorge > > > > > _______________________________________________ > BESS mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_bess&d=DwICAg&c=HAkYuh63rsuhr6Sc > bfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=kfwh59Pugrm0xKNQhDY5GPyy_bmYJpBOz8qJlix > Yj7w&s=5lQsLyRE7AmY0gkMA3vUe8midV3e4qx80blF1vr6snY&e= _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
