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

[John E Drake]

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  On Behalf Of Patrice Brissette
> (pbrisset)
> Sent: Monday, November 5, 2018 7:49 PM
> To: Rabadan, Jorge (Nokia - US/Mountain View)
> ; 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 ... 
> 
> 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
> =DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk
> Tvj0=UkHEfjNPy44C3HNNU8QiEPpRGRJ6_gabZewtSN-cmqQ=> / EVPN
> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__app.smartsheet.com_b_form_136bd5c3a22641bf92316523e79d6f22
> =DwIGaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE=JHaM715XuaFLBHtFogTkvMBGX9FJpdhm01YpjAk
> Tvj0=cwPTHa9AP_hSi_jkXTbFtTcE1lujDqRDYXOaUWuUM7U=>
> 
> 
> 
> On 2018-11-05, 4:44 PM, "Rabadan, Jorge (Nokia - US/Mountain View)"
>  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.
>  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.
> 
>  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"
>  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)
> 
>  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.
> 
>  As we demonstrated yesterday, there many cases where single-
> active or all-active are simply not wo

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi Patrice,

Thank you. Please see more in-line with [JORGE].

Thx
Jorge

-Original Message-
From: "Patrice Brissette (pbrisset)" 
Date: Tuesday, November 6, 2018 at 7:49 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" , 
"bess@ietf.org" , 
"draft-brissette-bess-evpn-l2gw-proto.auth...@ietf.org" 

Subject: Re: About draft-brissette-bess-evpn-l2gw-proto-03

Hi Jorge,

Please see my comments below ... 

Regards,
 
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment Routing 
 / EVPN 

 
 

On 2018-11-05, 4:44 PM, "Rabadan, Jorge (Nokia - US/Mountain View)" 
 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.
 Will do
[JORGE] thank you.

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.

 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"
[JORGE] Sure, this is what I mean: A PE that receives a non-zero ESI AD per-ES 
route is REQUIRED to process the route as per RFC7432. The route MUST include 
the extended community. The PE also needs to check the single-active bit, which 
can be 0 or 1. Depending on that bit, a non-upgraded PE will either behave as 
all-active or single-active. If you use a different bit, in the best case 
scenario the PE will ignore it and will behave as all-active, so your solution 
won't work. In the worst case scenario, the PE may 'treat as withdraw' the 
route.


 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?
[JORGE] I don't think you should sync MAC/ARPs in this scenario. In your figure 
1, if you have MAC1 connected to CE2, and PE1 advertises MAC1, you don't want 
to sync MAC1 in PE2 against the ring ESI because PE2 can't reach MAC1 through 
AC2, right? 


3- Section 6 - why do you define yet another extended community for mac 
flush, when we already have one? (RFC7623)

 It is true that we can reuse the MAC mobility from RFC7623. Note 
taken
[JORGE] thanks!

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.

 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. 
[JORGE] see my comment above. Sorry that I missed your presentation yesterday. 
Could you please clarify for me how you do ARP/MAC sync so that it 

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

[Patrice Brissette (pbrisset)]

Hi Jorge,

Please see my comments below ... 

Regards,
 
Patrice Brissette, Principal Engineer
Cisco Systems
Help us track your SP SR/EVPN Customer Opportunity/Status by filling these 
forms: Segment Routing 
 / EVPN 

 
 

On 2018-11-05, 4:44 PM, "Rabadan, Jorge (Nokia - US/Mountain View)" 
 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.
 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.

 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"
 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)

 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.

 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).

 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://www.ietf.org/mailman/listinfo/bess

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

[John E Drake]

Hi,

I agree w/ Jorge's proposal.

Yours Irrespectively,

John


> -Original Message-
> From: BESS  On Behalf Of Rabadan, Jorge (Nokia -
> US/Mountain View)
> Sent: Monday, November 5, 2018 4:45 AM
> To: bess@ietf.org; draft-brissette-bess-evpn-l2gw-proto.auth...@ietf.org
> 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
> BESS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_bess=DwICAg=HAkYuh63rsuhr6Sc
> bfh0UjBXeMK-ndb3voDTXcWzoCI=CRB2tJiQePk0cT-h5LGhEWH-
> s_xXXup3HzvBSMRj5VE=kfwh59Pugrm0xKNQhDY5GPyy_bmYJpBOz8qJlix
> Yj7w=5lQsLyRE7AmY0gkMA3vUe8midV3e4qx80blF1vr6snY=

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

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
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess