Re: [bess] About draft-brissette-bess-evpn-l2gw-proto-03

[John E Drake <[e-mail]>]

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 <[e-mail]> On Behalf Of Patrice Brissette
> (pbrisset)
> Sent: Monday, November 5, 2018 7:49 PM
> To: Rabadan, Jorge (Nokia - US/Mountain View)
> <[e-mail]>; [e-mail]; draft-brissette-bess-evpn-
> [e-mail]
> 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)"
> <[e-mail]> 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
> [e-mail]
> 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=