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

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

Hi,

I agree w/ Jorge's proposal.

Yours Irrespectively,

John


> -----Original Message-----
> From: BESS <[e-mail]> On Behalf Of Rabadan, Jorge (Nokia -
> US/Mountain View)
> Sent: Monday, November 5, 2018 4:45 AM
> To: [e-mail]; [e-mail]
> 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
> [e-mail]
> 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=