Patrice, I think it is much cleaner to treat the attachment of a set of L2GW PEs to an L2 network as a set of individual ESes, one per L2GW PE, as Jorge suggests. This is because a remote PE accesses different parts of the L2 network through different L2GW PEs; i.e., to a remote PE the connectivity looks like different sets of destinations associated with different ESes.
Yours Irrespectively, John > -----Original Message----- > From: BESS <bess-boun...@ietf.org> On Behalf Of Patrice Brissette > (pbrisset) > Sent: Monday, November 5, 2018 7:49 PM > To: Rabadan, Jorge (Nokia - US/Mountain View) > <jorge.raba...@nokia.com>; bess@ietf.org; draft-brissette-bess-evpn- > l2gw-proto.auth...@ietf.org > Subject: Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03 > > Hi Jorge, > > Please see my comments below ... <PATRICE> > > Regards, > > Patrice Brissette, Principal Engineer > Cisco Systems > Help us track your SP SR/EVPN Customer Opportunity/Status by filling these > forms: Segment Routing <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__app.smartsheet.com_b_form_185833ace35b4894b324dfb8afbd2060&d > =DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk > Tvj0&s=UkHEfjNPy44C3HNNU8QiEPpRGRJ6_gabZewtSN-cmqQ&e=> / EVPN > <https://urldefense.proofpoint.com/v2/url?u=https- > 3A__app.smartsheet.com_b_form_136bd5c3a22641bf92316523e79d6f22&d > =DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk > Tvj0&s=cwPTHa9AP_hSi_jkXTbFtTcE1lujDqRDYXOaUWuUM7U&e=> > > > > On 2018-11-05, 4:44 PM, "Rabadan, Jorge (Nokia - US/Mountain View)" > <jorge.raba...@nokia.com> wrote: > > 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. > <PATRICE> Will do > > 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. > > <PATRICE> I'm not sure why you are mentioning the draft is NOT backward > compatible. You need to explain that one. May I should add "remote PE not > support single-flow-active bit may ignore this mode" > <PATRICE> It is true you can support ring using single-homed and you are > welcome to do so. However, there are important drawbacks. For example, > how do you achieve ARP and MAC sync? > > > 3- Section 6 - why do you define yet another extended community for mac > flush, when we already have one? (RFC7623) > > <PATRICE> It is true that we can reuse the MAC mobility from RFC7623. Note > taken > > 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. > > <PATRICE> As we demonstrated yesterday, there many cases where single- > active or all-active are simply not working. Relying on single-homed is not > sufficient even with an ESI. I already gave the example of ARP/MAC sync. > > > 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). > > <PATRICE> I think you are considering only failure visible by PE only. > > Please let me know your comments. > > Thank you. > Jorge > > > > > > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_bess&d=DwIGaQ&c=HAkYuh63rsuhr6S > cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk > Tvj0&s=jVZqzygBj1QGRyzGojoLzg7tmopo2gc7R5DzUh2hgOY&e= _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
