Subject: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 25 Mar 2015 16:21:09 +0000

FYI- First published July 4, 2011

https://datatracker.ietf.org/doc/draft-sajassi-l2vpn-evpn-segment-route/

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Wed, 25 Mar 2015 21:34:04 +0000

Hi Ali,

Thanks for your information. I scanned through this draft, it really introduces inter-chassis message for DF election handshaking, the requirements in this draft is to eliminate transiet Loop and traffic duplication. Current EVPN DF election mechanism already eliminated loop and traffic duplication by configuring long reception timer on each multi-homed PE, but up to reception timer traffic disruption issue still exist. EVPN for DCI is an important use case for EVPN, up to reception timer traffic disruption can't be tolerated for service providers, it should be improved.

Also for accuracy, i think handshaking state machine on each multi-homed PE is also needed. From solution perspective, in my draft, no inter-chassis message is introduced, only one new extended community is introduced, i think the process is comparatively simple than your following draft.

Current EVPN DF election has some drawbacks, so there are three new drafts about DF election emerged. I think BESS WG can consider these three drafts in global view,  a single,comprehensive new DF election draft is hoped.

thanks.

Thanks,

weiguo

________________________________
From: BESS [[email-masked]] on behalf of Ali Sajassi (sajassi) [[email-masked]]
Sent: Thursday, March 26, 2015 0:21
To: [email-masked]
Subject: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

-Ali

---

From: John E Drake <[email-masked]>
Date: Wed, 25 Mar 2015 23:16:47 +0000

Weiguo,

Your proposal introduces a control plane processing load that is O(#EVIs * PEs) per DF election and given that there can be 4K EVIs per ES, this looks like a *substantial* load.  Furthermore,
you can't  use the ES route to co-ordinate DF election because you would need to carry your new extended community for each EVI and they would not all fit.  You also can't use the Per EVI Ethernet AD route because that is processed by all PEs in the EVI.

I think that from a practical perspective the new DF election proposed in Satya's draft is sufficiently stable that it renders your draft moot, even if it could be made to work.
Yours Irrespectively,

John

From: BESS [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Wednesday, March 25, 2015 5:34 PM
To: Ali Sajassi (sajassi); [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Ali,

thanks.

Thanks,

weiguo

To: [email-masked]<mailto:[email-masked]>

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Thu, 26 Mar 2015 03:38:30 +0000

Hi John,

 Firstly i think EVPN community should reach consensus on the issues of current DF election mechanism. All these issues should be resolved in a single new DF election draft,rather than in multiple separate drafts. If your draft can solve all these issues and stable, i have no question for its progressing. But if your draft have not solved all issues, i think it had better combine with other drafts to provide a comprehensive solution. I think the issues listed in draft-rabadan-bess-evpn-ac-df-01 and draft-hao-bess-evpn-df-handshaking-00 is valid, it should be resolved. So i think although your new Hash algorithm for DF election is good, it only includes partial enhancements, maybe it still needs some time for consensus.

Thanks,

weiguo

________________________________
From: John E Drake [[email-masked]]
Sent: Thursday, March 26, 2015 7:16
To: Haoweiguo; Ali Sajassi (sajassi); [email-masked]
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Weiguo,

Your proposal introduces a control plane processing load that is O(#EVIs * PEs) per DF election and given that there can be 4K EVIs per ES, this looks like a *substantial* load.  Furthermore,
you can’t  use the ES route to co-ordinate DF election because you would need to carry your new extended community for each EVI and they would not all fit.  You also can’t use the Per EVI Ethernet AD route because that is processed by all PEs in the EVI.

I think that from a practical perspective the new DF election proposed in Satya’s draft is sufficiently stable that it renders your draft moot, even if it could be made to work.
Yours Irrespectively,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Thu, 26 Mar 2015 09:40:59 +0000

Hi Weiguo,

I read your draft.

Your proposal introduces quite a bit of overhead as John has pointed out.
It is indeed bringing the role of AD routes into the DF election which has been intentionally kept separate so far.
As John points out, the AD routes will now be advertised ever so often, even to remote PEs  that do not host the same Ethernet Segment.
The per ES AD route also carries all the Route-Targets of all the EVIs, so anytime you want to advertise it again, it will need to be advertised with all these Route-Targets.
It imposes quite a processing overhead as far as the extended communities are concerned.

By this proposed feedback mechanism, it is going to delay the DF election.
In section 3 of https://tools.ietf.org/html/draft-hao-bess-evpn-df-handshaking-00 you mention a sequence number but it is not clear how you use it.
How does the scheme work when the PE reboots ?
How will it remember the sequence number?
Its a bit uncooked in the draft.

Best,
--Satya

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 25, 2015 8:38 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi John,

Thanks,

weiguo

________________________________
From: John E Drake [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 26, 2015 7:16
To: Haoweiguo; Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Weiguo,

John

From: BESS [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Wednesday, March 25, 2015 5:34 PM
To: Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Ali,

thanks.

Thanks,

weiguo

From: BESS [[email-masked]<mailto:[email-masked]>] on behalf of Ali Sajassi (sajassi) [[email-masked]<mailto:[email-masked]>]

-Ali

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Thu, 26 Mar 2015 12:54:22 +0000

Weiguo,

You mention "But if your draft have not solved all issues”,
Can you explain what Satya’s draft is not solving?

Regards,

Patrice

   [http://www.cisco.com/web/europe/images/email/signature/est2014/logo_06.png?ct=1406640631632]

Patrice Brissette
TECHNICAL LEADER.ENGINEERING

[email-masked]<mailto:[email-masked]>
Phone: +1 613 254 3336

Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Canada
Cisco.com<http://www.cisco.com/global/CA/>

[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Please click here<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for Company Registration Information.

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 25, 2015 at 10:38 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>, Ali Sajassi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi John,

Thanks,

weiguo

Weiguo,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Thu, 26 Mar 2015 15:12:57 +0000

Hi Satya,

Pls see below with [weiguo]. Further discussions are welcome.

Thanks,

weiguo

________________________________
From: Satya Mohanty (satyamoh) [[email-masked]]
Sent: Thursday, March 26, 2015 17:40
To: Haoweiguo; John E Drake; Ali Sajassi (sajassi); [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Weiguo,

I read your draft.

Your proposal introduces quite a bit of overhead as John has pointed out.
[weiguo]; More AD routes advertisements overhead is introduced,but i think it's not so much. I think the benefit deserves for the overhead. It can effectively reduce traffic disruption during transiet time.

It is indeed bringing the role of AD routes into the DF election which has been intentionally kept separate so far.
[weiguo]: Yes, AD routes are re-used for DF election handshaking process. As draft draft-rabadan-bess-evpn-ac-df-01 points out, DF election on each multi-homed PE also should consider AD route, not just ES route.

As John points out, the AD routes will now be advertised ever so often, even to remote PEs  that do not host the same Ethernet Segment.
[weiguo]: Not so often, only in the DF election and re-election phase, one more copy of AD routes per PE are advertised.

The per ES AD route also carries all the Route-Targets of all the EVIs, so anytime you want to advertise it again, it will need to be advertised with all these Route-Targets.
It imposes quite a processing overhead as far as the extended communities are concerned.
[weiguo]: Only when VLAN configuration change, PE joins or leaves ESI and etc will trigger the DF election and re-election, in normal operating envionment, these events will not happen frequently.

By this proposed feedback mechanism, it is going to delay the DF election.
[weiguo]: Yes, to ensure that all PEs of one ESI take action consistently. If DF PE and non-DF PE take action independantly, there will be some time traffic disruption. Handshaking mechanism is common in native ethernet world, such as MSTP. EVPN access network belongs to native ethernet world, it needs a more accurate mechanism.

In section 3 of https://tools.ietf.org/html/draft-hao-bess-evpn-df-handshaking-00 you mention a sequence number but it is not clear how you use it.
[weiguo]:  The seq number is generated at DF PE. When a PE is elected as DF PE, it should generate a seq number. Each handshaking message will use the seq number to ensure it is for same DF election process , it is used to avoid message interaction disorder.
Assuming PE1 is DF PE, it generates seq number 5, PE2 and PE3 use seq 5 to communicate with PE1. Before the handshaking negotication ends, another PE4 joins same ESI, PE1 is still DF, so PE1 wants to start a new handshaking process, it needs to generate a new seq number 6 to avoid message interaction confusing. I think the seq number mechanism can enhance reliability. If you and the comunity experts have better mechanism, i can also change it.

How does the scheme work when the PE reboots ?
[weiguo]: When PE reboots,  the process:
1. Local ESI discovery
2.Multi-homed PE auto-discovery
3.When reception timer expires, DF election handshaking.
4. DF PE and non-DF PE take effect, and enters into stable state.

How will it remember the sequence number?
[weiguo]: Don't need remember the seq. When PE restarts, the seq is generated from the start. Normally a device reboot timer needs several min.

Best,
--Satya

Hi John,

Thanks,

weiguo

Weiguo,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Thu, 26 Mar 2015 15:24:26 +0000

Hi Patrice,

Up to reception timer traffic disruption in transient phase is one of the issues.

Thanks,

weiguo

________________________________
From: Patrice Brissette (pbrisset) [[email-masked]]
Sent: Thursday, March 26, 2015 20:54
To: Haoweiguo; John E Drake; Ali Sajassi (sajassi); [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

Weiguo,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Thu, 26 Mar 2015 15:34:25 +0000

Weiguo,

I’m not sure I’m following here.
Don’t you have the same issue with your handshaking mechanism?
If you don’t know your peer, how can you handshake?

Regards,

Patrice

Patrice Brissette

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2015 at 10:24 AM
To: Patrice Brissette <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>, Ali Sajassi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Patrice,

Thanks,

weiguo

________________________________
From: Patrice Brissette (pbrisset) [[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 26, 2015 20:54
To: Haoweiguo; John E Drake; Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

Weiguo,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: John E Drake <[email-masked]>
Date: Thu, 26 Mar 2015 17:28:30 +0000

I think Patrice is correct.  Your proposal doesn't solve the problem and it does so at huge cost.

Sent from my iPhone

On Mar 26, 2015, at 10:34 AM, Patrice Brissette (pbrisset) <[email-masked]<mailto:[email-masked]>> wrote:

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

Weiguo,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Thu, 26 Mar 2015 19:23:57 +0000

Handshaking process happens after PEs auto-discovery using ES route,  it can be used to avoid traffic disruption. Handshaking mechanism should be combined with PEs auto-discovery defined in current EVPN base protocol.

weiguo

________________________________
From: BESS [[email-masked]] on behalf of Patrice Brissette (pbrisset) [[email-masked]]
Sent: Thursday, March 26, 2015 23:34
To: Haoweiguo; John E Drake; Ali Sajassi (sajassi); [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

Weiguo,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Thu, 26 Mar 2015 19:25:32 +0000

Pls read my detail replies to Satya. If you still can't catch it, pls read my draft and EVPN base protocol,  thanks

weiguo

________________________________
From: John E Drake [[email-masked]]
Sent: Friday, March 27, 2015 1:28
To: Patrice Brissette (pbrisset)
Cc: Haoweiguo; Ali Sajassi (sajassi); [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Sent from my iPhone

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

Weiguo,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 26 Mar 2015 20:02:13 +0000

Weiguo,

Since you mention https://tools.ietf.org/html/draft-rabadan-bess-evpn-ac-df-00 let me point at a few differences with your draft:

- In our draft we are NOT using AD routes for the DF election. The DF election is still based on RFC7432. I fully agree with Patrice/John/Satya that doing this handshaking is an unnecessary control plane overhead. It also slows down significantly the DF election process, at the expense of maybe avoiding a few duplicate packets (loops are resolved in the RFC7432) if the timers in RFC7432 were not configured properly.

- In our draft, for EVPN, we are not adding any new attribute or modifying the DF election. We are only using the existing information from the AD per-EVI routes to modify the candidate list for a given EVI. But note that those AD routes per-EVI are part of RFC7432 and are sent any way. So our draft is fully compatible with RFC7432 and Satya’s draft.

- In your draft, it is not clear if you use AD routes per-ES or per-EVI.
a) If it is per-ES, it simply does not work - as John says you need the DF indication per EVI.
b) if it is per-EVI then it is a huge overhead as was mentioned below, and those routes get to every PE in the network.

- Also in your slides, you also seem to use a timer to allow time to discover the ESI… plus the additional time of sending the DF indication and receiving the DF notification. This is BGP, so assuming you have RRs and the min-route-advertisement-intervals recommended, plus the local additional processing you are introducing, the whole DF election process is significantly slowed down.

Thank you.
Jorge

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2015 at 12:25 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>, "Patrice Brissette (pbrisset)" <[email-masked]<mailto:[email-masked]>>
Cc: "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

weiguo

Cc: Haoweiguo; Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>

Sent from my iPhone

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

Weiguo,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: John E Drake <[email-masked]>
Date: Thu, 26 Mar 2015 20:41:11 +0000

Weiguo,

We have already established that your proposal is untenable because of its control plane load.

What we are now discussing is that your proposal is based upon a misunderstanding of the algorithm in RFC 7432.  You are assuming that PE1 will advertise an ES route and then wait for the configured interval before performing the DF election while PE2 and PE3 will perform the DF election as soon as they receive the ES route from PE1.  This is not what RFC 7432 says.

Rather, what is says is that the advertisement of the ES route by PE1 and its receipt by PE2 and PE3 causes all three PEs to start the configured interval timer  - "3. When the timer expires, each PE builds an ordered list of the IP addresses of all the PE nodes connected to the Ethernet segment (including itself), in increasing numeric value."

Yours Irrespectively,

John

From: Haoweiguo [mailto:[email-masked]]
Sent: Thursday, March 26, 2015 3:26 PM
To: John E Drake; Patrice Brissette (pbrisset)
Cc: Ali Sajassi (sajassi); [email-masked]
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

weiguo

Sent from my iPhone

I'm not sure I'm following here.
Don't you have the same issue with your handshaking mechanism?
If you don't know your peer, how can you handshake?

Regards,

Patrice
   [Image removed by sender.]

Patrice Brissette

[Image removed by sender.]Think before you print.

Hi Patrice,

Thanks,

weiguo

You mention "But if your draft have not solved all issues",
Can you explain what Satya's draft is not solving?

Regards,

Patrice
   [Image removed by sender.]

Patrice Brissette

[Image removed by sender.]Think before you print.

Hi John,

Thanks,

weiguo

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Thu, 26 Mar 2015 21:17:06 +0000

Hi Jorge,

I understood your draft. Pls see below other replies with [weiguo].

Thanks,

weiguo

________________________________
From: Rabadan, Jorge (Jorge) [[email-masked]]
Sent: Friday, March 27, 2015 4:02
To: Haoweiguo; John E Drake; Patrice Brissette (pbrisset)
Cc: Ali Sajassi (sajassi); [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Weiguo,

- In our draft we are NOT using AD routes for the DF election. The DF election is still based on RFC7432.
[weiguo]: I know your draft don't using AD routes for DF election, but your DF election needs to consider AD-route not just ES route.

I fully agree with Patrice/John/Satya that doing this handshaking is an unnecessary control plane overhead. It also slows down significantly the DF election process, at the expense of maybe avoiding a few duplicate packets (loops are resolved in the RFC7432) if the timers in RFC7432 were not configured properly.
[weiguo]: It's not slowing down DF election, it is to make DF PE and non-DF take effect at the same time. If you think it is slowing down, it just slowing down one handshaking message transmission timer, the transmission timer is very short comparing to reception timer value. And i think the slowing down have no side effect to network forwarding behaviour, traffic disruption timer is the matter.

- In your draft, it is not clear if you use AD routes per-ES or per-EVI.
a) If it is per-ES, it simply does not work - as John says you need the DF indication per EVI.
b) if it is per-EVI then it is a huge overhead as was mentioned below, and those routes get to every PE in the network.
[weiguo]: I think the per-EVI handshaking message overhead is acceptable, it is transmitted between multi-homed PE belonging to same ESI. It doesn't need to be transmitted to other remote PEs.

- Also in your slides, you also seem to use a timer to allow time to discover the ESI… plus the additional time of sending the DF indication and receiving the DF notification. This is BGP, so assuming you have RRs and the min-route-advertisement-intervals recommended, plus the local additional processing you are introducing, the whole DF election process is significantly slowed down.
[weiguo]: I think the message transmission timer normally is very short. The handshaking mechanism is a common mechanism used in native ethernet world, all handshaking mechanism has message transmission timer traffic loss, i think it is acceptable.
Thank you.
Jorge

weiguo

Sent from my iPhone

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Weiguo,

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

Weiguo,

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Thu, 26 Mar 2015 21:36:50 +0000

John,

As your understanding of the EVPN draft, the DF election mechanism has more serious side effect, it will have short time traffic loop,i.e., dual DF PEs will exist for a short time. I think dual DF PEs is absolutely not tolerated, because native ethernet header has no TTL, up to several hundred ms traffic loop normally not tolerated in commertial networks.

As your understanding, the PEs should do as following:

1. Accurate timer sync. NTP accuracy is bad, 1588v2 is good but have rarely deployment.

Assuming PE1,PE2 and PE3 have consistent timer clock, when PE3 joins ESI and trigger DF re-election. When reception timer expires:

PE1 upgrades to DF PE.

After reception timer+ ES route transmission timer:

PE2 downloads to non-DF PE.

So in timer clock sync case, dual DF PEs will exist at least transmission timer.

If NTP is used for timer sync, because it has bad accuracy, dual DF PEs will exist more longer timer.

So as your understanding for DF election, the drawback is more clear.

Thanks,

weiguo

________________________________
From: John E Drake [[email-masked]]
Sent: Friday, March 27, 2015 4:41
To: Haoweiguo; Patrice Brissette (pbrisset)
Cc: Ali Sajassi (sajassi); [email-masked]
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Weiguo,

Rather, what is says is that the advertisement of the ES route by PE1 and its receipt by PE2 and PE3 causes all three PEs to start the configured interval timer  - “3. When the timer expires, each PE builds an ordered list of the IP addresses of all the PE nodes connected to the Ethernet segment (including itself), in increasing numeric value.”

Yours Irrespectively,

John

weiguo

Sent from my iPhone

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Thu, 26 Mar 2015 21:56:37 +0000

Weiguo,

I sent already too much time of this so I hope this is the last email.
I read again one more time your draft and it is NOT addressing the issue that you keep coming back to.
See, if you don’t want any loop, simply bring your interface in blocked state until DF election converge.

Regards,

Patrice

Patrice Brissette

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2015 at 4:36 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>, Patrice Brissette <[email-masked]<mailto:[email-masked]>>
Cc: Ali Sajassi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

John,

PE1 upgrades to DF PE.

Thanks,

weiguo

Cc: Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>

Weiguo,

Yours Irrespectively,

John

Cc: Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>

weiguo

Sent from my iPhone

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: John E Drake <[email-masked]>
Date: Thu, 26 Mar 2015 22:00:04 +0000

To recap,

We have established that your proposal is untenable because of its control plane load.

We have established that your proposal is based upon a flawed understanding of the DF election in RFC 7432.

What you are now arguing is that your draft prevents two or more PEs from being DF simultaneously.  This is clearly nonsense.

Furthermore, we have established that having two or more DFs for what even you admit is a brief transient leads to duplicate traffic, which is acceptable, but not loops, your assertion to the contrary.

Yours Irrespectively,

John

Sent: Thursday, March 26, 2015 5:37 PM

John,

PE1 upgrades to DF PE.

Thanks,

weiguo

Yours Irrespectively,

John

weiguo

Sent from my iPhone

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Thu, 26 Mar 2015 22:07:45 +0000

Patrice,

Pls see below with [weiguo].

weiguo

________________________________
From: Patrice Brissette (pbrisset) [[email-masked]]
Sent: Friday, March 27, 2015 5:56
To: Haoweiguo; John E Drake
Cc: Ali Sajassi (sajassi); [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Weiguo,

I read again one more time your draft and it is NOT addressing the issue that you keep coming back to.
[weiguo]: Sorry, maybe more time is needed to reach consensus.

See, if you don’t want any loop, simply bring your interface in blocked state until DF election converge.
[weiguo]: When EVPN PE boots up, the access interface should be set blocked state, this is common sense and i have doubt. But in DF re-election case, PE1 and PE2 are in steady state, PE1 is non-DF and PE2
is DF. After some time, PE3 joins the same ESI, PE3 is elected as DF PE, only when PE3 upgrades to DF PE, PE2 can degrade to non-DF PE to avoid traffic disruption. This is node failure and recovery scenario(PE3 fails and recovers again). Traffic disruption and loop should be avoided in this scenario.

Regards,

Patrice

Patrice Brissette

John,

PE1 upgrades to DF PE.

Thanks,

weiguo

Weiguo,

Yours Irrespectively,

John

weiguo

Sent from my iPhone

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 26 Mar 2015 22:12:03 +0000

Weiguo,

I don’t understand why you talk about loops. There are no loops in EVPN with the use of the ESI label and split-horizon. Even if you have transient states with more than one DF for a given EVI, the split-horizon procedure prevents any loops.

Thanks.
Jorge

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2015 at 3:07 PM
To: "Patrice Brissette (pbrisset)" <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: "Ali Sajassi (sajassi)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Patrice,

weiguo

Weiguo,

Regards,

Patrice

Patrice Brissette

John,

PE1 upgrades to DF PE.

Thanks,

weiguo

Weiguo,

Yours Irrespectively,

John

weiguo

Sent from my iPhone

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Thu, 26 Mar 2015 22:13:22 +0000

Weiguo,

"only when PE3 upgrades to DF PE, PE2 can degrade to non-DF PE to avoid traffic disruption”

If you follow that, a loop is being created! For some time, PE3 and PE2 will be both DF.

Regards,

Patrice

Patrice Brissette

From: Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 26, 2015 at 5:07 PM
To: Patrice Brissette <[email-masked]<mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Ali Sajassi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Patrice,

weiguo

Weiguo,

Regards,

Patrice

Patrice Brissette

John,

PE1 upgrades to DF PE.

Thanks,

weiguo

Weiguo,

Yours Irrespectively,

John

weiguo

Sent from my iPhone

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: Haoweiguo <[email-masked]>
Date: Thu, 26 Mar 2015 22:16:58 +0000

Pls see below.

Thanks,

weiguo

Sent: Friday, March 27, 2015 6:00

To recap,

We have established that your proposal is based upon a flawed understanding of the DF election in RFC 7432.
[weiguo]:  In ethernet world, traffic loop is serious than short timer traffic disruption. If you want to implement  transiet traffic loop process, i will modify my draft to solve your issue.
If i am the developer, i will prefer short timer traffic disruption based on current EVPN protocol.

What you are now arguing is that your draft prevents two or more PEs from being DF simultaneously.  This is clearly nonsense.
[weiguo]: I will modify the draft problem statements, and use the same handshaking solution to solve it.

Furthermore, we have established that having two or more DFs for what even you admit is a brief transient leads to duplicate traffic, which is acceptable, but not loops, your assertion to the contrary.
[weiguo]: It is transient loop and traffic duplication issue.
Yours Irrespectively,

John

John,

PE1 upgrades to DF PE.

Thanks,

weiguo

Yours Irrespectively,

John

weiguo

Sent from my iPhone

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: John E Drake <[email-masked]>
Date: Fri, 27 Mar 2015 01:05:42 +0000

Weiguo,

I guess I wasn't clear.  I think you draft, for the reasons I have detailed, is a non-solution to a non-problem with tremendous control plane cost.

Yours Irrespectively,

John

Sent: Thursday, March 26, 2015 6:17 PM

Pls see below.

Thanks,

weiguo

John

John,

PE1 upgrades to DF PE.

Thanks,

weiguo

Yours Irrespectively,

John

weiguo

Sent from my iPhone

Regards,

Patrice

Patrice Brissette

Hi Patrice,

Thanks,

weiguo

Regards,

Patrice

Patrice Brissette

Hi John,

Thanks,

weiguo

John

Hi Ali,

thanks.

Thanks,

weiguo

-Ali

---

From: <[email-masked]>
Date: Thu, 26 Mar 2015 21:50:35 -0500

Hi,

Let me attempt at clarifying the exchange between the few of you.

My understanding is that:
- RFC7432 already does a good job of avoiding forwarding loops thanks to 
the split-horizon procedure that does not depend on DF election and has 
no transient state
- RFC7432 may have transient periods where the DF election state is not 
yet synchronized between the two peers:
   * the transient period correspond to BGP route propagation times  
(not to the DF election delay, although the wording in RFC 7432 could be 
made clearer)
   * during this period, if PEs do not block BUM traffic, some traffic 
may be lost
   * during this period, if PEs do not block BUM traffic, some traffic 
may be duplicated, but this is not considered very harmful and hence 
preferred to packet loss

The opinion, as I understand, that has been expressed by some is that 
the reduction of the transient period where duplicates may arise, is not 
worth the cost of an handshaking approach.

HTH,

-Thomas

26/03/2015 20:05, John E Drake :
>
> Weiguo,
>
> I guess I wasn’t clear.  I think you draft, for the reasons I have 
> detailed, is a non-solution to a non-problem with tremendous control 
> plane cost.
>
> Yours Irrespectively,
>
> John
>
> *From:*Haoweiguo [mailto:[email-masked]]
> *Sent:* Thursday, March 26, 2015 6:17 PM
> *To:* John E Drake; Patrice Brissette (pbrisset)
> *Cc:* Ali Sajassi (sajassi); [email-masked]
> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on 
> Paxos algorithm
>
> Pls see below.
>
> Thanks,
>
> weiguo
>
> ------------------------------------------------------------------------
>
> *From:*John E Drake [[email-masked]]
> *Sent:* Friday, March 27, 2015 6:00
> *To:* Haoweiguo; Patrice Brissette (pbrisset)
> *Cc:* Ali Sajassi (sajassi); [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on 
> Paxos algorithm
>
> To recap,
>
> We have established that your proposal is based upon a flawed 
> understanding of the DF election in RFC 7432.
>
> [weiguo]: In ethernet world, traffic loop is serious than short timer 
> traffic disruption. If you want to implement  transiet traffic loop 
> process, i will modify my draft to solve your issue.
>
> What you are now arguing is that your draft prevents two or more PEs 
> from being DF simultaneously. This is clearly nonsense.
>
> Furthermore, we have established that having two or more DFs for what 
> even you admit is a brief transient leads to duplicate traffic, which 
> is acceptable, but not loops, your assertion to the contrary.
>
> *From:*Haoweiguo [mailto:[email-masked]]
> *Sent:* Thursday, March 26, 2015 5:37 PM
> *To:* John E Drake; Patrice Brissette (pbrisset)
> *Cc:* Ali Sajassi (sajassi); [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on 
> Paxos algorithm
>
> John,
>
> As your understanding of the EVPN draft, the DF election mechanism has 
> more serious side effect, it will have short time traffic loop,i.e., 
> dual DF PEs will exist for a short time. I think dual DF PEs is 
> absolutely not tolerated, because native ethernet header has no TTL, 
> up to several hundred ms traffic loop normally not tolerated in 
> commertial networks.
>
> Assuming PE1,PE2 and PE3 have consistent timer clock, when PE3 joins 
> ESI and trigger DF re-election. When reception timer expires:
>
> PE1 upgrades to DF PE.
>
> ------------------------------------------------------------------------
>
> *From:*John E Drake [[email-masked]]
> *Sent:* Friday, March 27, 2015 4:41
> *To:* Haoweiguo; Patrice Brissette (pbrisset)
> *Cc:* Ali Sajassi (sajassi); [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on 
> Paxos algorithm
>
> Weiguo,
>
> What we are now discussing is that your proposal is based upon a 
> misunderstanding of the algorithm in RFC 7432.  You are assuming that 
> PE1 will advertise an ES route and then wait for the configured 
> interval before performing the DF election while PE2 and PE3 will 
> perform the DF election as soon as they receive the ES route from PE1. 
> This is not what RFC 7432 says.
>
> Rather, what is says is that the advertisement of the ES route by PE1 
> and its receipt by PE2 and PE3 causes all three PEs to start the 
> configured interval timer  - “3. When the timer expires, each PE 
> builds an ordered list of the IP addresses of all the PE nodes 
> connected to the Ethernet segment (including itself), in increasing 
> numeric value.”
>
> Yours Irrespectively,
>
> John
>
> *From:*Haoweiguo [mailto:[email-masked]]
> *Sent:* Thursday, March 26, 2015 3:26 PM
> *To:* John E Drake; Patrice Brissette (pbrisset)
> *Cc:* Ali Sajassi (sajassi); [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on 
> Paxos algorithm
>
> Pls read my detail replies to Satya. If you still can't catch it, pls 
> read my draft and EVPN base protocol,  thanks
>
> weiguo
>
> ------------------------------------------------------------------------
>
> *From:*John E Drake [[email-masked]]
> *Sent:* Friday, March 27, 2015 1:28
> *To:* Patrice Brissette (pbrisset)
> *Cc:* Haoweiguo; Ali Sajassi (sajassi); [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [bess] Handshaking among PEs in an EVPN ES based on 
> Paxos algorithm
>
> On Mar 26, 2015, at 10:34 AM, Patrice Brissette (pbrisset) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Weiguo,
>
>     Image removed by sender.
>     *Patrice Brissette*
>     [email-masked] <mailto:[email-masked]>
>     Phone: *+1 613 254 3336*
>
>     	
>
>     *Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE*
>     Canada
>     Cisco.com <http://www.cisco.com/global/CA/>
>
>     	
>
>     Image removed by sender.Think before you print.
>
>     This email may contain confidential and privileged material for
>     the sole use of the intended recipient. Any review, use,
>     distribution or disclosure by others is strictly prohibited. If
>     you are not the intended recipient (or authorized to receive for
>     the recipient), please contact the sender by reply email and
>     delete all copies of this message.
>
>     Please click here
>     <http://www.cisco.com/web/about/doing_business/legal/cri/index.html>
>     for Company Registration Information.
>
>
>     *From: *Haoweiguo <[email-masked] <mailto:[email-masked]>>
>     *Date: *Thursday, March 26, 2015 at 10:24 AM
>     *To: *Patrice Brissette <[email-masked]
>     <mailto:[email-masked]>>, John E Drake <[email-masked]
>     <mailto:[email-masked]>>, Ali Sajassi <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Subject: *RE: [bess] Handshaking among PEs in an EVPN ES based on
>     Paxos algorithm
>
>         Hi Patrice,
>
>         ------------------------------------------------------------------------
>
>         *From:*Patrice Brissette (pbrisset) [[email-masked]
>         <mailto:[email-masked]>]
>         *Sent:* Thursday, March 26, 2015 20:54
>         *To:* Haoweiguo; John E Drake; Ali Sajassi (sajassi);
>         [email-masked] <mailto:[email-masked]>
>         *Subject:* Re: [bess] Handshaking among PEs in an EVPN ES
>         based on Paxos algorithm
>
>         Weiguo,
>
>         Image removed by sender.
>         *Patrice Brissette*
>         [email-masked] <mailto:[email-masked]>
>         Phone: *+1 613 254 3336*
>
>         	
>
>         *Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE*
>         Canada
>         Cisco.com <http://www.cisco.com/global/CA/>
>
>         	
>
>         Image removed by sender.Think before you print.
>
>         This email may contain confidential and privileged material
>         for the sole use of the intended recipient. Any review, use,
>         distribution or disclosure by others is strictly prohibited.
>         If you are not the intended recipient (or authorized to
>         receive for the recipient), please contact the sender by reply
>         email and delete all copies of this message.
>
>         Please click here
>         <http://www.cisco.com/web/about/doing_business/legal/cri/index.html>
>         for Company Registration Information.
>
>
>         *From: *Haoweiguo <[email-masked]
>         <mailto:[email-masked]>>
>         *Date: *Wednesday, March 25, 2015 at 10:38 PM
>         *To: *John E Drake <[email-masked]
>         <mailto:[email-masked]>>, Ali Sajassi <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>         *Subject: *Re: [bess] Handshaking among PEs in an EVPN ES
>         based on Paxos algorithm
>
>             Hi John,
>
>              Firstly i think EVPN community should reach consensus on
>             the issues of current DF election mechanism. All these
>             issues should be resolved in a single new DF election
>             draft,rather than in multiple separate drafts. If your
>             draft can solve all these issues and stable, i have no
>             question for its progressing. But if your draft have not
>             solved all issues, i think it had better combine with
>             other drafts to provide a comprehensive solution. I think
>             the issues listed in draft-rabadan-bess-evpn-ac-df-01 and
>             draft-hao-bess-evpn-df-handshaking-00 is valid, it should
>             be resolved. So i think although your new Hash algorithm
>             for DF election is good, it only includes partial
>             enhancements, maybe it still needs some time for consensus.
>
>             Thanks,
>
>             weiguo
>
>             ------------------------------------------------------------------------
>
>             *From:*John E Drake [[email-masked]
>             <mailto:[email-masked]>]
>             *Sent:* Thursday, March 26, 2015 7:16
>             *To:* Haoweiguo; Ali Sajassi (sajassi); [email-masked]
>             <mailto:[email-masked]>
>             *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES
>             based on Paxos algorithm
>
>             Weiguo,
>
>             Your proposal introduces a control plane processing load
>             that is O(#EVIs * PEs) per DF election and given that
>             there can be 4K EVIs per ES, this looks like a
>             **substantial** load. Furthermore,
>
>             you can’t  use the ES route to co-ordinate DF election
>             because you would need to carry your new extended
>             community for each EVI and they would not all fit.  You
>             also can’t use the Per EVI Ethernet AD route because that
>             is processed by all PEs in the EVI.
>
>             I think that from a practical perspective the new DF
>             election proposed in Satya’s draft is sufficiently stable
>             that it renders your draft moot, even if it could be made
>             to work.
>
>             Yours Irrespectively,
>
>             John
>
>             *From:*BESS [mailto:[email-masked]] *On Behalf Of
>             *Haoweiguo
>             *Sent:* Wednesday, March 25, 2015 5:34 PM
>             *To:* Ali Sajassi (sajassi); [email-masked]
>             <mailto:[email-masked]>
>             *Subject:* Re: [bess] Handshaking among PEs in an EVPN ES
>             based on Paxos algorithm
>
>             Hi Ali,
>
>             Thanks for your information. I scanned through this draft,
>             it really introduces inter-chassis message for DF election
>             handshaking, the requirements in this draft is to
>             eliminate transiet Loop and traffic duplication. Current
>             EVPN DF election mechanism already eliminated loop and
>             traffic duplication by configuring long reception timer on
>             each multi-homed PE, but up to reception timer traffic
>             disruption issue still exist. EVPN for DCI is an important
>             use case for EVPN, up to reception timer traffic
>             disruption can't be tolerated for service providers, it
>             should be improved.
>
>             Also for accuracy, i think handshaking state machine on
>             each multi-homed PE is also needed. From solution
>             perspective, in my draft, no inter-chassis message is
>             introduced, only one new extended community is introduced,
>             i think the process is comparatively simple than your
>             following draft.
>
>             Current EVPN DF election has some drawbacks, so there are
>             three new drafts about DF election emerged. I think BESS
>             WG can consider these three drafts in global view, a
>             single,comprehensive new DF election draft is hoped.
>
>             thanks.
>
>             Thanks,
>
>             weiguo
>
>             ------------------------------------------------------------------------
>
>             *From:*BESS [[email-masked]
>             <mailto:[email-masked]>] on behalf of Ali Sajassi
>             (sajassi) [[email-masked] <mailto:[email-masked]>]
>             *Sent:* Thursday, March 26, 2015 0:21
>             *To:* [email-masked] <mailto:[email-masked]>
>             *Subject:* [bess] Handshaking among PEs in an EVPN ES
>             based on Paxos algorithm
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 03:47:44 +0000

Hi Thomas,
Pls see inline with [weiguo].

Thanks,
weiguo

________________________________________
From: BESS [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Friday, March 27, 2015 10:50
To: [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi,

[weiguo]: Yes, i think RFC 7432 has transient periods of traffic loop(In my draft, i described it into short time traffic disruption, no state consistency between PEs is blamed for the transient loop or traffic disruption).  John and patrice think current DF election has no transiet loop problem.

   * the transient period correspond to BGP route propagation times
(not to the DF election delay, although the wording in RFC 7432 could be
made clearer)
[weiguo]: Based on the assumption of strict timer clock synchronization on different PEs, the transiet period is BGP route propagation timer. In real world, no strict timer clock sync. If NTP is used for timer sync, timer difference will be large,say A seconds. So in NTP case, the transiet period is A+ BGP route propagation timer or A- BGP route propagation timer. Up to the transiet timer difference traffic loop is normally not allowed in etherent network, because unlike IP frame, ethernet header has no TTL, Up to 1 second or multiple seconds transiet loop will cause whole network crashes.

   * during this period, if PEs do not block BUM traffic, some traffic
may be lost
   * during this period, if PEs do not block BUM traffic, some traffic
may be duplicated, but this is not considered very harmful and hence
preferred to packet loss
[weiguo]: During this period,  dual DF PE will exist during DF re-election period, traffic loop and duplication will happen. When a PE fails and recover again, it will trigger DF re-election.

The opinion, as I understand, that has been expressed by some is that
the reduction of the transient period where duplicates may arise, is not
worth the cost of an handshaking approach.
[weiguo]: I think at any time in any case, traffic loop is not allowed although the transiet timer maybe very short. In ethernet network, no traffic loop is not allowed.

HTH,

-Thomas

---

From: <[email-masked]>
Date: Thu, 26 Mar 2015 22:59:18 -0500

Hi Weiguo,

2015-03-26, Haoweiguo:
 > Thomas:
> > - RFC7432 may have transient periods where the DF election state is
> > not yet synchronized between the two peers:
 >
> [weiguo]: Yes, i think RFC 7432 has transient periods of traffic loop

Note well that I didn't write that there can be transient _loops_ .
I tried to capture the exchange you had all, and what I gather is that 
the split-horizon procedure _prevents_loops_, independently of any 
transient period where DF state is not synchronized and which may lead 
to transient _duplicates_.

-Thomas

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 04:08:38 +0000

Hi Thomas,
I know you are neutral, sorry for my reply vulnerable to be miunderstood.

Thanks,
weiguo

________________________________________
From: [email-masked] [[email-masked]]
Sent: Friday, March 27, 2015 11:59
To: Haoweiguo; [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Weiguo,

-Thomas

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Fri, 27 Mar 2015 04:10:41 +0000

Hi Thomas and Weiguo,

Agree with the below statement. I don’t see any loops in EVPN with the ESI
label, that is recommended to be used for single-active/all-active and
also not only from NDF to DF but also from DF to NDF. Hence even in
transient states with more than one DF - if at all possible -
split-horizon takes care of the loops. The only thing you might get in
that case is a few duplicate packets.

Weiguo, please let me know if I am missing something.

Thank you.
Jorge

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Organization: Orange
Date: Thursday, March 26, 2015 at 8:59 PM
To: Haoweiguo <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

>>_________________________________________________________________________
>>________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>>confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>messages electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or privileged
>>information that may be protected by law;
>__________________________________________________________________________
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Fri, 27 Mar 2015 04:11:57 +0000

Thomas,

Thanks for your summary. It captures the essence of the discussion.

One feature of the HRW scheme is that it computes the Active and the
Backup DF upfront.
Whenever the Active PE, say PE1, dies; the Backup PE, PE2, can become the
Active immediately upon receiving the withdraw of the ES route from PE1.
It need not even have to wait for the 3 seconds time.

On the other hand, the 3 second timer will serve as a bulk and batch
mechanism for the case when new PE(s) is(are) coming up, so we don¹t have
to do a DF election ever so often.

Haoweiguo,  I think the "loop" scenario is speculative.
I think everybody understands that, yes, there may be some transient
duplication of bum traffic; however, there is no "loop" problem to be
solved.

Thanks,
--Satya

On 3/26/15 9:08 PM, "Haoweiguo" <[email-masked]> wrote:

>>> I guess I wasn¹t clear.  I think you draft, for the reasons I have
>>> configured interval timer  - ³3. When the timer expires, each PE
>>> numeric value.²
>>>      I¹m not sure I¹m following here.
>>>
>>>      Don¹t you have the same issue with your handshaking mechanism?
>>>
>>>      If you don¹t know your peer, how can you handshake?
>>>
>>>      Regards,
>>>
>>>      Patrice
>>>
>>>      Image removed by sender.
>>>
>>>      *Patrice Brissette*
>>>          You mention "But if your draft have not solved all issues²,
>>>
>>>          Can you explain what Satya¹s draft is not solving?
>>>
>>>          Regards,
>>>
>>>          Patrice
>>>
>>>          Image removed by sender.
>>>
>>>          *Patrice Brissette*
>>>              you can¹t  use the ES route to co-ordinate DF election
>>>              also can¹t use the Per EVI Ethernet AD route because that
>>>              election proposed in Satya¹s draft is sufficiently stable

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 04:55:43 +0000

Hi Satya,
Pls see inline.

Thanks,
weiguo

________________________________________
From: Satya Mohanty (satyamoh) [[email-masked]]
Sent: Friday, March 27, 2015 12:11
To: Haoweiguo; [email-masked]; [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Thomas,

[weiguo]: Yes, i agree.

One feature of the HRW scheme is that it computes the Active and the
Backup DF upfront.
Whenever the Active PE, say PE1, dies; 
the Backup PE, PE2, can become the
Active immediately upon receiving the withdraw of the ES route from PE1.
It need not even have to wait for the 3 seconds time.
[weiguo]: I think maybe your negligence, dies PE1 can't send withdraw message:) But when PE1 leaves ESI, it can withdraw the ES route immediately.
When PE1 dies and recovers, assuming PE1 is DF PE, then PE1 and PE2 will both act as PE for some transiet time.

Haoweiguo,  I think the "loop" scenario is speculative.
I think everybody understands that, yes, there may be some transient
duplication of bum traffic; however, there is no "loop" problem to be
solved.
[weiguo]: Traffic duplication and loop issue both exist in dual DF PE case. In multi-homed device case, say CE1 is multi-homed to PE1 and PE2 and both PE are DF PE. When CE1 sends traffic to PE1, the traffic will loop back to CE1 through PE2. If CE1 can filter and drop the traffic , it is fortunate, maybe no loop. 
For multi-homed network scenario, say local network1(CE1 and CE2) is multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop back through PE1-->PE2-->CE2, it is very serious. It is absolutely not allowed.

Thanks,
--Satya

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Fri, 27 Mar 2015 05:12:47 +0000

Hi Haoweiguo,

On 3/26/15 9:55 PM, "Haoweiguo" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Satya,
Pls see inline.

Thanks,
weiguo

________________________________________
From: Satya Mohanty (satyamoh) [[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 27, 2015 12:11
To: Haoweiguo; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Thomas,

[Satya] Not really negligence. What I meant is the following without getting into details. In most topologies PEs will be connected via an RR. So when the PE1 dies, the routes that have been advertised by the RR to other PEs will be withdrawn by the RR once the PE1 session with RR is broken. Alternatively, if there is no RR and PE1 and pE2 have a peering, PE2 is going to purge the routes learnt from PE1 once the hold timer expires. Net effect as far as DF election in PE2 is concerned is a "withdraw" of the ES route.

[Satya] Shouldn't the split-horizon procedure not kick in here?

Thanks,
--Satya

On 3/26/15 9:08 PM, "Haoweiguo" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Thomas,

Thanks,
weiguo

________________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 27, 2015 11:59
To: Haoweiguo; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

Hi Weiguo,

-Thomas

Weiguo,

Yours Irrespectively,

John

*Cc:* Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>

Pls see below.

Thanks,

weiguo

*From:*John E Drake [[email-masked]<mailto:[email-masked]>]
*Sent:* Friday, March 27, 2015 6:00
*To:* Haoweiguo; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm

To recap,

We have established that your proposal is untenable because of its
control plane load.

If i am the developer, i will prefer short timer traffic disruption
based on current EVPN protocol.

[weiguo]: I will modify the draft problem statements, and use the same
handshaking solution to solve it.

Yours Irrespectively,

John

*Cc:* Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

John,

1. Accurate timer sync. NTP accuracy is bad, 1588v2 is good but have
rarely deployment.

PE1 upgrades to DF PE.

So in timer clock sync case, dual DF PEs will exist at least
transmission timer.

If NTP is used for timer sync, because it has bad accuracy, dual DF
PEs will exist more longer timer.

Thanks,

weiguo

*From:*John E Drake [[email-masked]<mailto:[email-masked]>]
*Sent:* Friday, March 27, 2015 4:41
*To:* Haoweiguo; Patrice Brissette (pbrisset)
*Cc:* Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
*Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm

Weiguo,

We have already established that your proposal is untenable because of
its control plane load.

Yours Irrespectively,

John

*Cc:* Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

weiguo

*From:*John E Drake [[email-masked]<mailto:[email-masked]>]
*Sent:* Friday, March 27, 2015 1:28
*To:* Patrice Brissette (pbrisset)
*Cc:* Haoweiguo; Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>
*Subject:* Re: [bess] Handshaking among PEs in an EVPN ES based on
Paxos algorithm

I think Patrice is correct.  Your proposal doesn't solve the problem
and it does so at huge cost.

Sent from my iPhone

On Mar 26, 2015, at 10:34 AM, Patrice Brissette (pbrisset)
<[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

      Weiguo,

      Regards,

      Patrice

      Image removed by sender.

      *Patrice Brissette*

      [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
      Phone: *+1 613 254 3336*

      Please click here

      *From: *Haoweiguo <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>>
      *Date: *Thursday, March 26, 2015 at 10:24 AM
      *To: *Patrice Brissette <[email-masked]<mailto:[email-masked]>
      <mailto:[email-masked]>>, John E Drake <[email-masked]<mailto:[email-masked]>
      <mailto:[email-masked]>>, Ali Sajassi <[email-masked]<mailto:[email-masked]>
      <mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>
      <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
      *Subject: *RE: [bess] Handshaking among PEs in an EVPN ES based on
      Paxos algorithm

          Hi Patrice,

          Up to reception timer traffic disruption in transient phase is
          one of the issues.

          Thanks,

          weiguo

          *From:*Patrice Brissette (pbrisset) [[email-masked]<mailto:[email-masked]>
          <mailto:[email-masked]>]
          *Sent:* Thursday, March 26, 2015 20:54
          *To:* Haoweiguo; John E Drake; Ali Sajassi (sajassi);
          [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
          *Subject:* Re: [bess] Handshaking among PEs in an EVPN ES
          based on Paxos algorithm

          Weiguo,

          Regards,

          Patrice

          Image removed by sender.

          *Patrice Brissette*

          [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
          Phone: *+1 613 254 3336*

          Please click here

          *From: *Haoweiguo <[email-masked]<mailto:[email-masked]>
          <mailto:[email-masked]>>
          *Date: *Wednesday, March 25, 2015 at 10:38 PM
          *To: *John E Drake <[email-masked]<mailto:[email-masked]>
          <mailto:[email-masked]>>, Ali Sajassi <[email-masked]<mailto:[email-masked]>
          <mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>
          <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
          *Subject: *Re: [bess] Handshaking among PEs in an EVPN ES
          based on Paxos algorithm

              Hi John,

              enhancements, maybe it still needs some time for
consensus.

              Thanks,

              weiguo

              *From:*John E Drake [[email-masked]<mailto:[email-masked]>
              <mailto:[email-masked]>]
              *Sent:* Thursday, March 26, 2015 7:16
              *To:* Haoweiguo; Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>
              <mailto:[email-masked]>
              *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES
              based on Paxos algorithm

              Weiguo,

              Yours Irrespectively,

              John

              *From:*BESS [mailto:[email-masked]] *On Behalf Of
              *Haoweiguo
              *Sent:* Wednesday, March 25, 2015 5:34 PM
              *To:* Ali Sajassi (sajassi); [email-masked]<mailto:[email-masked]>
              <mailto:[email-masked]>
              *Subject:* Re: [bess] Handshaking among PEs in an EVPN ES
              based on Paxos algorithm

              Hi Ali,

              thanks.

              Thanks,

              weiguo

              *From:*BESS [[email-masked]<mailto:[email-masked]>
              <mailto:[email-masked]>] on behalf of Ali Sajassi
              (sajassi) [[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>]
              *Sent:* Thursday, March 26, 2015 0:21
              *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
              *Subject:* [bess] Handshaking among PEs in an EVPN ES
              based on Paxos algorithm

              -Ali

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

Orange decline toute responsabilite si ce message a ete altere, deforme
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

Orange decline toute responsabilite si ce message a ete altere, deforme
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.
_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Fri, 27 Mar 2015 12:26:50 +0000

Hi Weiguo,

About this:

[weiguo]: Traffic duplication and loop issue both exist in dual DF PE
case. In multi-homed device case, say CE1 is multi-homed to PE1 and PE2
and both PE are DF PE. When CE1 sends traffic to PE1, the traffic will
loop back to CE1 through PE2. If CE1 can filter and drop the traffic , it
is fortunate, maybe no loop.
For multi-homed network scenario, say local network1(CE1 and CE2) is
multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop back
through PE1-->PE2-->CE2, it is very serious. It is absolutely not allowed.

[JORGE] In a MH device case: CE1->BUM->PE1->(ESI-label+BUM)->PE2. PE2 will
not send the traffic back to CE1 due to the ESI-label and split-horizon
procedures.
In MH network case PE2 will NOT send the traffic to CE2 for the same
reason.

Let me know if you disagree please.

Thanks.
Jorge

-----Original Message-----
From: Haoweiguo <[email-masked]>
Date: Thursday, March 26, 2015 at 9:55 PM
To: "Satya Mohanty (satyamoh)" <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

>[weiguo]: I think maybe your negligence, dies PE1 can't send withdraw
>message:) But when PE1 leaves ESI, it can withdraw the ES route
>immediately.
>[weiguo]: Traffic duplication and loop issue both exist in dual DF PE
>case. In multi-homed device case, say CE1 is multi-homed to PE1 and PE2
>and both PE are DF PE. When CE1 sends traffic to PE1, the traffic will
>loop back to CE1 through PE2. If CE1 can filter and drop the traffic , it
>is fortunate, maybe no loop.
>For multi-homed network scenario, say local network1(CE1 and CE2) is
>multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop
>back through PE1-->PE2-->CE2, it is very serious. It is absolutely not
>allowed.
>
>Thanks,
>--Satya
>
>
>
>>_

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Fri, 27 Mar 2015 13:02:06 +0000

Thomas, Satya,

Thanks for summarizing. It is very clear and we are all on the same page.

Regards,

Patrice

   Patrice Brissette

[email-masked]
Phone: +1 613 254 3336

 Think before you print.This
 email may contain confidential and privileged material for the sole use
 of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient
(or authorized to receive for the recipient), please contact the sender
by reply email and delete all copies of this message.
Please click here 
<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for
Company Registration Information.

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 14:29:39 +0000

Hi Jorge,
Sorry, maybe i have not explain clearly, pls allow me to clarify it more clearly.
In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE2 is single homed to remote PE3. CE1 and CE2 forms one layer 2 network, so it multi-homed network scenario.
           CE3
             |
            PE3

PE1                  PE2
  |                       |
CE1-----------CE2

In transiet period, PE1 and PE2 are both DF PE. At this time, CE3 sends BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will receive two copy of the traffic from CE3, also loop is formed, the form path:

CE3---->PE3---->PE2---->CE2---->CE1---->PE1--->PE3--->CE3

I think the traffic loop is absolutely not allowed. In MHN case, the loop will formed due to dual-DF PE in transiet period.

Thanks,
weiguo

________________________________________
From: Rabadan, Jorge (Jorge) [[email-masked]]
Sent: Friday, March 27, 2015 20:26
To: Haoweiguo; Satya Mohanty (satyamoh); [email-masked]; [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Weiguo,

About this:

Thanks.
Jorge

---

From: John E Drake <[email-masked]>
Date: Fri, 27 Mar 2015 14:40:09 +0000

Precisely

Yours Irrespectively,

John

> From: BESS [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, March 26, 2015 10:51 PM
> To: [email-masked]
> - RFC7432 already does a good job of avoiding forwarding loops thanks to the
> split-horizon procedure that does not depend on DF election and has no
> transient state
> - RFC7432 may have transient periods where the DF election state is not yet
> synchronized between the two peers:
>    * the transient period correspond to BGP route propagation times (not to
> the DF election delay, although the wording in RFC 7432 could be made
> clearer)
>    * during this period, if PEs do not block BUM traffic, some traffic may be lost
>    * during this period, if PEs do not block BUM traffic, some traffic may be
> duplicated, but this is not considered very harmful and hence preferred to
> packet loss
> 
> The opinion, as I understand, that has been expressed by some is that the
> reduction of the transient period where duplicates may arise, is not worth
> the cost of an handshaking approach.
> 
> HTH,
> 
> -Thomas
> 
> 
> __________________________________________________________
> __________________________________________________________
> _____
> 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
> ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> information that may be protected by law; they should not be distributed,
> used or copied without authorisation.

---

From: Kishore Tiruveedhula <[email-masked]>
Date: Fri, 27 Mar 2015 14:45:29 +0000

I agree with Satya.  If you compute the DF role and act upon just immediatly after receiving the ESI withdraw/advertisement, you can avoid the state of both PEs in DF or Non-DF.
Just after local ESI discovery, keep the ESI in the Non-DF state, advertise ESI route and start the 3 seconds the DF election timer. Just after receiving the ESI route from the remote PE, just compute the DF role immediately and no need to wait for 3 seconds. The 3 seconds is the max wait time. You could change this timer value if the receiving the ESI route from remote PE takes longer than 3 seconds.

Thanks,
Kishore

From: "Satya Mohanty (satyamoh)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 27, 2015 at 12:12 AM
To: Haoweiguo <[email-masked]<mailto:[email-masked]>>, "EXT - [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Haoweiguo,

Hi Satya,
Pls see inline.

Thanks,
weiguo

Thomas,

Thanks,
--Satya

Hi Thomas,

Thanks,
weiguo

Hi Weiguo,

-Thomas

Weiguo,

Yours Irrespectively,

John

Pls see below.

Thanks,

weiguo

To recap,

Yours Irrespectively,

John

John,

PE1 upgrades to DF PE.

Thanks,

weiguo

Weiguo,

Yours Irrespectively,

John

weiguo

Sent from my iPhone

      Weiguo,

      Regards,

      Patrice

      Image removed by sender.

      *Patrice Brissette*

      Please click here

          Hi Patrice,

          Thanks,

          weiguo

          Weiguo,

          Regards,

          Patrice

          Image removed by sender.

          *Patrice Brissette*

          Please click here

              Hi John,

              Thanks,

              weiguo

              Weiguo,

              Yours Irrespectively,

              John

              Hi Ali,

              thanks.

              Thanks,

              weiguo

              -Ali

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 14:53:26 +0000

Hi Jorge,
Sorry for sending again to correct some word error.

In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE3 is single homed to remote PE3. CE1 and CE2 forms one layer 2 network, so this is multi-homed network scenario. The picture is as follows:
           CE3
             |
            PE3

PE1                  PE2
  |                       |
CE1-----------CE2
In transiet period, PE1 and PE2 are both DF PE. At this time, CE3 sends BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will receive two copy of the traffic from CE3, also loop is formed, the Loop path is:

I think the traffic loop is absolutely not allowed. In MHN case, the loop will form due to dual-DF PE in transiet period.
Thanks,
weiguo

Hi Weiguo,

About this:

Thanks.
Jorge

---

From: John E Drake <[email-masked]>
Date: Fri, 27 Mar 2015 14:55:35 +0000

There's no loop.  Any BUM packet received from either CE1 or CE2 will not be forwarded back to them because of the ES label.

Yours Irrespectively,

John

> Sent: Friday, March 27, 2015 10:30 AM
> To: Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT -
> [email-masked]; [email-masked]
> In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE2 is
> single homed to remote PE3. CE1 and CE2 forms one layer 2 network, so it
> multi-homed network scenario.
>            CE3
>              |
>             PE3
> 
> 
> PE1                  PE2
>   |                       |
> CE1-----------CE2
> 
> In transiet period, PE1 and PE2 are both DF PE. At this time, CE3 sends BUM
> traffic to CE1, the traffic will reach PE1 and PE2, CE1 will receive two copy of
> the traffic from CE3, also loop is formed, the form path:
> 
> I think the traffic loop is absolutely not allowed. In MHN case, the loop will
> formed due to dual-DF PE in transiet period.
> 
> Thanks,
> weiguo
> 
> 
> 
> [weiguo]: Traffic duplication and loop issue both exist in dual DF PE case. In
> multi-homed device case, say CE1 is multi-homed to PE1 and PE2 and both PE
> are DF PE. When CE1 sends traffic to PE1, the traffic will loop back to CE1
> through PE2. If CE1 can filter and drop the traffic , it is fortunate, maybe no
> loop.
> For multi-homed network scenario, say local network1(CE1 and CE2) is multi-
> homed to PE1 and PE2. Similarly, the traffic from CE1 will loop back through
> PE1-->PE2-->CE2, it is very serious. It is absolutely not allowed.
> 
> 
> [JORGE] In a MH device case: CE1->BUM->PE1->(ESI-label+BUM)->PE2. PE2
> will not send the traffic back to CE1 due to the ESI-label and split-horizon
> procedures.
> In MH network case PE2 will NOT send the traffic to CE2 for the same reason.
> 
> >When PE1 dies and recovers, assuming PE1 is DF PE, then PE1 and PE2
> >will both act as PE for some transiet time.
> >
> >mechanism for the case when new PE(s) is(are) coming up, so we don¹t
> >have to do a DF election ever so often.
> >
> >loop back to CE1 through PE2. If CE1 can filter and drop the traffic ,
> >it is fortunate, maybe no loop.
> >>> > - RFC7432 may have transient periods where the DF election state
> >>> > is not yet synchronized between the two peers:
> >> >
> >>>> detailed, is a non-solution to a non-problem with tremendous
> >>>> control plane cost.
> >>>>
> >>>> Yours Irrespectively,
> >>>>
> >>>> John
> >>>>
> >>>>--------------------------------------------------------------------
> >>>>---
> >>>>-
> >>>>
> >>>> [weiguo]: In ethernet world, traffic loop is serious than short
> >>>> timer traffic disruption. If you want to implement  transiet
> >>>> traffic loop process, i will modify my draft to solve your issue.
> >>>>
> >>>> What you are now arguing is that your draft prevents two or more
> >>>> PEs from being DF simultaneously. This is clearly nonsense.
> >>>>
> >>>> Furthermore, we have established that having two or more DFs for
> >>>> what even you admit is a brief transient leads to duplicate
> >>>> traffic, which is acceptable, but not loops, your assertion to the
> contrary.
> >>>>
> >>>> As your understanding of the EVPN draft, the DF election mechanism
> >>>> has more serious side effect, it will have short time traffic
> >>>> loop,i.e., dual DF PEs will exist for a short time. I think dual DF
> >>>> PEs is absolutely not tolerated, because native ethernet header has
> >>>> no TTL, up to several hundred ms traffic loop normally not
> >>>> tolerated in commertial networks.
> >>>>
> >>>> Assuming PE1,PE2 and PE3 have consistent timer clock, when PE3
> >>>> joins ESI and trigger DF re-election. When reception timer expires:
> >>>>
> >>>> PE1 upgrades to DF PE.
> >>>>
> >>>>--------------------------------------------------------------------
> >>>>---
> >>>>-
> >>>>
> >>>> Rather, what is says is that the advertisement of the ES route by
> >>>> PE1 and its receipt by PE2 and PE3 causes all three PEs to start
> >>>> the configured interval timer  - ³3. When the timer expires, each
> >>>> PE builds an ordered list of the IP addresses of all the PE nodes
> >>>> Pls read my detail replies to Satya. If you still can't catch it,
> >>>> pls read my draft and EVPN base protocol,  thanks
> >>>>
> >>>> weiguo
> >>>>
> >>>>
> >>>>--------------------------------------------------------------------
> >>>>---
> >>>>-
> >>>>
> >>>>--------------------------------------------------------------------
> >>>>---
> >>>>-
> >>>>
> >>>>--------------------------------------------------------------------
> >>>>---
> >>>>-
> >>>>
> >>>>--------------------------------------------------------------------
> >>>>---
> >>>>-
> >>>>
> >>>>https://datatracker.ietf.org/doc/draft-sajassi-l2vpn-evpn-segment-ro
> >>>>ute
> >>>>/
> >>>>
> >>>>              -Ali
> >>>>
> >>>>
> >>>>
> >>>_______________________________________________________
> ______________
> >>>___
> >>>_
> >>>confidentielles ou privilegiees et ne doivent donc  pas etre
> >>>diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
> >>>message par erreur, veuillez le signaler  a l'expediteur et le
> >>>detruire ainsi que les pieces jointes. Les messages electroniques
> >>>etant susceptibles d'alteration,  Orange decline toute responsabilite
> >>>si ce message a ete altere, deforme ou falsifie. Merci.
> >>>
> >>> This message and its attachments may contain confidential or
> >>>privileged information that may be protected by law;  they should not
> >>>be distributed, used or copied without authorisation.
> >>> If you have received this email in error, please notify the sender
> >>>and delete this message and its attachments.
> >>> As emails may be altered, Orange is not liable for messages that
> >>>have been modified, changed or falsified.
> >>> Thank you.
> >>>
> >>________________________________________________________
> ______________
> >>___
> >>_
> >>confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> >>exploites ou copies sans autorisation. Si vous avez recu ce message
> >>par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> >>que les pieces jointes. Les messages electroniques etant susceptibles
> >>d'alteration, Orange decline toute responsabilite si ce message a ete
> >>altere, deforme ou falsifie. Merci.
> >>
> >>This message and its attachments may contain confidential or
> >>privileged information that may be protected by law; they should not
> >>be distributed, used or copied without authorisation.

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Fri, 27 Mar 2015 14:59:37 +0000

Hi Weiguo,

OK, thanks for clarifying, that is the part I did not understand in your
loop :-)

To me a loop means you send a frame and that frame keeps being forwarded
by the same nodes indefinitely till you take a corrective action.
In this case, CE3 might get a few packets during the transient state, but
those packets will have its own MAC SA so CE3 will discard them. I don’t
think that is harmful for CE3 in most of the cases. And if it is, you just
need to make sure the timers are long enough and the DF election properly
implemented to avoid the transient DF-DF state.

The handshaking is definitely overkilling IMHO.

Thanks.
Jorge

-----Original Message-----
From: Haoweiguo <[email-masked]>
Date: Friday, March 27, 2015 at 7:29 AM
To: Jorge Rabadan <[email-masked]>, "Satya Mohanty
(satyamoh)" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

>In transiet period, PE1 and PE2 are both DF PE. At this time, CE3 sends
>BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will receive
>two copy of the traffic from CE3, also loop is formed, the form path:
>
>I think the traffic loop is absolutely not allowed. In MHN case, the loop
>will formed due to dual-DF PE in transiet period.
>
>Thanks,
>weiguo
>
>
>
>>>>>----------------------------------------------------------------------
>>>>>-
>>>>>-
>>>>>
>>>>>has
>>>>>----------------------------------------------------------------------
>>>>>-
>>>>>-
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>-
>>>>>-
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>-
>>>>>-
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>-
>>>>>-
>>>>>
>>>>>----------------------------------------------------------------------
>>>>>-
>>>>>-
>>>>>
>>>>>https://datatracker.ietf.org/doc/draft-sajassi-l2vpn-evpn-segment-rout
>>>>>e
>>>>>/
>>>>>
>>>>>              -Ali
>>>>>
>>>>>
>>>>>
>>>>_______________________________________________________________________
>>>>_
>>>>_
>>>>privileged

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 15:11:30 +0000

Hi Jorge,
Let give you another indefinitely forwarding loop case, the picture is as follows:

CE3------------CE4
  |                        |
PE3                   PE4

PE1                   PE2
 |                         |
CE1------------CE2

If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4 are in stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic from CE3 to CE1, the forwarding loop path is as follows;
CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3-->CE4--->PE4---->forever......

Do you think the harm is enough?
Thanks,
weiguo
________________________________________
From: Rabadan, Jorge (Jorge) [[email-masked]]
Sent: Friday, March 27, 2015 22:59
To: Haoweiguo; Satya Mohanty (satyamoh); [email-masked]; [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Hi Weiguo,

Thanks.
Jorge

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 15:21:57 +0000

Hi John,
Thanks for your explanation.
Yes, there is no local loop relying on ESI label filtering in transiet period. But the traffic from remote PE to local mutli-homed network side, the loop will be formed. I have shown that in the relies to Jorge.

Thanks,
weiguo

________________________________________
From: John E Drake [[email-masked]]
Sent: Friday, March 27, 2015 22:55
To: Haoweiguo; Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT - [email-masked]; [email-masked]
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

Yours Irrespectively,

John

---

From: John E Drake <[email-masked]>
Date: Fri, 27 Mar 2015 15:22:20 +0000

I think we have beaten this topic to death.  For the numerous reason I've given, I'm not interested in you proposal.

Yours Irrespectively,

John

> Sent: Friday, March 27, 2015 11:12 AM
> If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4 are in
> stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic from CE3 to CE1,
> the forwarding loop path is as follows;
> CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3-->CE4--->PE4----
> >forever......
> 
> OK, thanks for clarifying, that is the part I did not understand in your loop :-)
> 
> In this case, CE3 might get a few packets during the transient state, but those
> packets will have its own MAC SA so CE3 will discard them. I don't think that is
> harmful for CE3 in most of the cases. And if it is, you just need to make sure
> the timers are long enough and the DF election properly implemented to
> avoid the transient DF-DF state.
> 
> >In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE2
> >is single homed to remote PE3. CE1 and CE2 forms one layer 2 network,
> >so it multi-homed network scenario.
> >           CE3
> >             |
> >            PE3
> >
> >
> >PE1                  PE2
> >  |                       |
> >CE1-----------CE2
> >
> >BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will
> >receive two copy of the traffic from CE3, also loop is formed, the form path:
> >
> >I think the traffic loop is absolutely not allowed. In MHN case, the
> >loop will formed due to dual-DF PE in transiet period.
> >
> >Thanks,
> >weiguo
> >
> >
> >
> >back through PE1-->PE2-->CE2, it is very serious. It is absolutely not allowed.
> >
> >
> >will not send the traffic back to CE1 due to the ESI-label and
> >split-horizon procedures.
> >>Whenever the Active PE, say PE1, dies; the Backup PE, PE2, can become
> >>the Active immediately upon receiving the withdraw of the ES route
> >>from PE1.
> >>case. In multi-homed device case, say CE1 is multi-homed to PE1 and
> >>PE2 and both PE are DF PE. When CE1 sends traffic to PE1, the traffic
> >>will loop back to CE1 through PE2. If CE1 can filter and drop the
> >>traffic , it is fortunate, maybe no loop.
> >>>I tried to capture the exchange you had all, and what I gather is
> >>>that the split-horizon procedure _prevents_loops_, independently of
> >>>any transient period where DF state is not synchronized and which may
> >>>lead to transient _duplicates_.
> >>>
> >>>-Thomas
> >>>
> >>>>
> >>>>> If i am the developer, i will prefer short timer traffic
> >>>>> disruption based on current EVPN protocol.
> >>>>>
> >>>>>loop,i.e.,  dual DF PEs will exist for a short time. I think dual
> >>>>>DF PEs is  absolutely not tolerated, because native ethernet header
> >>>>>has no TTL,  up to several hundred ms traffic loop normally not
> >>>>> connected to the Ethernet segment (including itself), in
> >>>>> increasing numeric value.²
> >>>>>
> >>>>> Yours Irrespectively,
> >>>>>
> >>>>> John
> >>>>>
> >>>>______________________________________________________
> ______________
> >>>>___
> >>>>_
> >>>>_
> >>>>diffuses, exploites ou copies sans autorisation. Si vous avez recu
> >>>>ce message par erreur, veuillez le signaler  a l'expediteur et le
> >>>>etant susceptibles d'alteration,  Orange decline toute
> >>>>privileged information that may be protected by law;  they should
> >>>>not be distributed, used or copied without authorisation.

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 15:27:41 +0000

Hi John,
If you can tolerate indefinite forwarding loop during transiet time, i have no problem. If the community think it is a serious problem, i think we must propose an applicable solution for it, maybe there are other solutions better than handshaking mechanism.

Thanks,
weiguo

Sent: Friday, March 27, 2015 23:22

Yours Irrespectively,

John

---

From: John E Drake <[email-masked]>
Date: Fri, 27 Mar 2015 15:37:13 +0000

It goes without saying that there are better solutions.  As Ali pointed out, he proposed one years ago and decided to drop it because he decided the problem wasn't worth solving.  This is a sentiment I share. 

Yours Irrespectively,

John

> Sent: Friday, March 27, 2015 11:28 AM
> To: John E Drake; Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT -
> If you can tolerate indefinite forwarding loop during transiet time, i have no
> problem. If the community think it is a serious problem, i think we must
> propose an applicable solution for it, maybe there are other solutions better
> than handshaking mechanism.
> 
> Thanks,
> weiguo
> 
> I think we have beaten this topic to death.  For the numerous reason I've
> given, I'm not interested in you proposal.
> 
> Yours Irrespectively,
> 
> John
> 
> > Let give you another indefinitely forwarding loop case, the picture is
> > as
> > follows:
> >
> > CE3------------CE4
> >   |                        |
> > PE3                   PE4
> >
> >
> >
> > PE1                   PE2
> >  |                         |
> > CE1------------CE2
> >
> > If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4
> > are in stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic
> > from CE3 to CE1, the forwarding loop path is as follows;
> > CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3-->CE4--->PE4
> > CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3-->CE4--->---
> > CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3-->CE4--->-
> > >forever......
> >
> > To me a loop means you send a frame and that frame keeps being
> > forwarded by the same nodes indefinitely till you take a corrective action.
> > In this case, CE3 might get a few packets during the transient state,
> > but those packets will have its own MAC SA so CE3 will discard them. I
> > don't think that is harmful for CE3 in most of the cases. And if it
> > is, you just need to make sure the timers are long enough and the DF
> > election properly implemented to avoid the transient DF-DF state.
> >
> > >In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2,
> > >CE2 is single homed to remote PE3. CE1 and CE2 forms one layer 2
> > >network, so it multi-homed network scenario.
> > >           CE3
> > >             |
> > >            PE3
> > >
> > >
> > >PE1                  PE2
> > >  |                       |
> > >CE1-----------CE2
> > >
> > >In transiet period, PE1 and PE2 are both DF PE. At this time, CE3
> > >sends BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1
> > >will receive two copy of the traffic from CE3, also loop is formed, the form
> path:
> > >
> > >>Whenever the Active PE, say PE1, dies; the Backup PE, PE2, can
> > >>become the Active immediately upon receiving the withdraw of the ES
> > >>route from PE1.
> > >>duplication of bum traffic; however, there is no "loop" problem to
> > >>be solved.
> > >>[weiguo]: Traffic duplication and loop issue both exist in dual DF
> > >>PE case. In multi-homed device case, say CE1 is multi-homed to PE1
> > >>and
> > >>PE2 and both PE are DF PE. When CE1 sends traffic to PE1, the
> > >>traffic will loop back to CE1 through PE2. If CE1 can filter and
> > >>drop the traffic , it is fortunate, maybe no loop.
> > >>multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will
> > >>loop back through PE1-->PE2-->CE2, it is very serious. It is
> > >>absolutely not allowed.
> > >>
> > >>Thanks,
> > >>--Satya
> > >>
> > >>
> > >>
> > >>>> > - RFC7432 may have transient periods where the DF election
> > >>>> > state is not yet synchronized between the two peers:
> > >>> >
> > >>>any transient period where DF state is not synchronized and which
> > >>>may lead to transient _duplicates_.
> > >>>
> > >>>-Thomas
> > >>>
> > >>>>
> > >>>>> I guess I wasn¹t clear.  I think you draft, for the reasons I
> > >>>>> have detailed, is a non-solution to a non-problem with
> > >>>>> tremendous control plane cost.
> > >>>>>
> > >>>>> Yours Irrespectively,
> > >>>>>
> > >>>>> John
> > >>>>>
> > >>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based
> > >>>>> on Paxos algorithm
> > >>>>>
> > >>>>> Pls see below.
> > >>>>>
> > >>>>> Thanks,
> > >>>>>
> > >>>>> weiguo
> > >>>>>
> > >>>>>
> > >>>>>-----------------------------------------------------------------
> > >>>>>--
> > >>>>>---
> > >>>>>-
> > >>>>>-
> > >>>>>
> > >>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based
> > >>>>> on Paxos algorithm
> > >>>>>
> > >>>>> To recap,
> > >>>>>
> > >>>>> [weiguo]: I will modify the draft problem statements, and use
> > >>>>>the same  handshaking solution to solve it.
> > >>>>>
> > >>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based
> > >>>>> on Paxos algorithm
> > >>>>>
> > >>>>> John,
> > >>>>>
> > >>>>> As your understanding of the EVPN draft, the DF election
> > >>>>>mechanism has  more serious side effect, it will have short time
> > >>>>>traffic loop,i.e.,  dual DF PEs will exist for a short time. I
> > >>>>>think dual DF PEs is  absolutely not tolerated, because native
> > >>>>>ethernet header has no TTL,  up to several hundred ms traffic
> > >>>>>loop normally not tolerated in  commertial networks.
> > >>>>>
> > >>>>>-----------------------------------------------------------------
> > >>>>>--
> > >>>>>---
> > >>>>>-
> > >>>>>-
> > >>>>>
> > >>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based
> > >>>>> on Paxos algorithm
> > >>>>>
> > >>>>> Weiguo,
> > >>>>>
> > >>>>> the configured interval timer  - ³3. When the timer expires,
> > >>>>> each PE builds an ordered list of the IP addresses of all the PE
> > >>>>> nodes connected to the Ethernet segment (including itself), in
> > >>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based
> > >>>>> on Paxos algorithm
> > >>>>>
> > >>>>> Pls read my detail replies to Satya. If you still can't catch
> > >>>>> it, pls read my draft and EVPN base protocol,  thanks
> > >>>>>
> > >>>>> weiguo
> > >>>>>
> > >>>>>
> > >>>>>-----------------------------------------------------------------
> > >>>>>--
> > >>>>>---
> > >>>>>-
> > >>>>>-
> > >>>>>
> > >>>>> *Subject:* Re: [bess] Handshaking among PEs in an EVPN ES based
> > >>>>> on Paxos algorithm
> > >>>>>
> > >>>>>-----------------------------------------------------------------
> > >>>>>--
> > >>>>>---
> > >>>>>-
> > >>>>>-
> > >>>>>
> > >>>>>-----------------------------------------------------------------
> > >>>>>--
> > >>>>>---
> > >>>>>-
> > >>>>>-
> > >>>>>
> > >>>>>-----------------------------------------------------------------
> > >>>>>--
> > >>>>>---
> > >>>>>-
> > >>>>>-
> > >>>>>
> > >>>>>https://datatracker.ietf.org/doc/draft-sajassi-l2vpn-evpn-segment
> > >>>>>-r
> > >>>>>out
> > >>>>>e
> > >>>>>/
> > >>>>>
> > >>>>>              -Ali
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>> Ce message et ses pieces jointes peuvent contenir des
> > >>>>informations confidentielles ou privilegiees et ne doivent donc
> > >>>>pas etre diffuses, exploites ou copies sans autorisation. Si vous
> > >>>>avez recu ce message par erreur, veuillez le signaler  a
> > >>>>l'expediteur et le detruire ainsi que les pieces jointes. Les
> > >>>>messages electroniques etant susceptibles d'alteration,  Orange
> > >>>>decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie.
> > >>>>Merci.
> > >>>>
> > >>>> If you have received this email in error, please notify the
> > >>>>sender and delete this message and its attachments.

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Fri, 27 Mar 2015 15:39:17 +0000

Hi Weiguo,

I disagree with your explanation below.

This is the flow assuming PE1-PE2 *might* be both DF and PE3 is DF:

CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3——>DROP

If the MAC SA of the frame is CE3’s MAC, CE3 will discard.
Even if CE3 forwards to CE4->PE4, PE4 is NDF and will discard the frame.
Remember MH network ES' as per your diagram below, only support
single-active MH.

Thanks.
Jorge

-----Original Message-----
From: Haoweiguo <[email-masked]>
Date: Friday, March 27, 2015 at 8:11 AM
To: Jorge Rabadan <[email-masked]>, "Satya Mohanty
(satyamoh)" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

>If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4 are
>in stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic from CE3
>to CE1, the forwarding loop path is as follows;
>>back
>>will
>>>>>>timer
>>>>>>what
>>>>>>PE1
>>>>>>pls
>>>>>avez
>>>>messages

---

From: <[email-masked]>
Date: Fri, 27 Mar 2015 10:40:10 -0500

HI Weigo, all,

Let me try to help again...

RFC7432, section 8.5 says:

    If a bridged network is multihomed to more than one PE in an EVPN
    network via switches, then the support of All-Active redundancy mode
    requires the bridged network to be connected to two or more PEs using
    a LAG.

    If a bridged network does not connect to the PEs using a LAG, then
    only one of the links between the bridged network and the PEs must be
    the active link for a given <ES, VLAN> or <ES, VLAN bundle>.  In this
    case, the set of Ethernet A-D per ES routes advertised by each PE
    MUST have the "Single-Active" bit in the flags of the ESI Label
    extended community set to 1.

My understanding was that the above excludes the kind of topology in 
which you exclude a possible loop.

-Thomas

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Fri, 27 Mar 2015 15:44:53 +0000

Thanks for the reference Thomas.
As I was saying in my email, this prevents the loop in Weiguo’s diagram,
since only single-active is supported in Weiguo’s example.

Thank you.
Jorge

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Organization: Orange
Date: Friday, March 27, 2015 at 8:40 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

>> If you can tolerate indefinite forwarding loop during transiet time, i
>>have no problem. If the community think it is a serious problem, i think
>>we must propose an applicable solution for it, maybe there are other
>>solutions better than handshaking mechanism.
>>
>> Thanks,
>> weiguo
>>
>> I think we have beaten this topic to death.  For the numerous reason
>>I've given, I'm not interested in you proposal.
>>
>> Yours Irrespectively,
>>
>> John
>>
>>>are in
>>>forwarded
>>>but those
>>>>sends
>>>>PE2
>>>>>>>>for
>>>>>>>>               the issues listed in
>>>>>>>>draft-rabadan-bess-evpn-ac-df-01
>>>>>>>> and
>>>>>>>>               Current EVPN DF election has some drawbacks, so
>>>>>>>>there
>>>>>>>> are
>>>>>>diffuses,

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 15:54:36 +0000

Hi Thomas,
Thanks for your reference.
Yes,if a bridged network does not connect to the PEs using a LAG, in stable state, only one link connect to one PE is active. But in transiet state, both PE1 and PE2 can forward traffic, so loop will occur.

We are talking the process in transiet period, i think in this period traffic loop is not allowed.
Thanks,
weiguo

________________________________________
From: BESS [[email-masked]] on behalf of [email-masked] [[email-masked]]
Sent: Friday, March 27, 2015 23:40
To: [email-masked]
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm

HI Weigo, all,

-Thomas

---

From: Haoweiguo <[email-masked]>
Date: Fri, 27 Mar 2015 16:00:27 +0000

Hi Jorge,
The picture in email is just for a simplified explanation. Source MAC can be the layer 3 device connecting to CE3, CE3 will not drop the frame so easily. This is an absolutely loop.

Thanks,
weiguo

Sent: Friday, March 27, 2015 23:39

Hi Weiguo,

Thanks.
Jorge

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Fri, 27 Mar 2015 16:54:22 +0000

Hi Weiguo,

As I said:
"Even if CE3 forwards to CE4->PE4, PE4 is NDF and will discard the frame.
Remember MH network ES' as per your diagram below, only support
single-active MH.”

So there is NO LOOP.

If you have any other scenario, let’s talk offline. We are boring people
;-)

Thanks.
Jorge

-----Original Message-----
From: Haoweiguo <[email-masked]>
Date: Friday, March 27, 2015 at 9:00 AM
To: Jorge Rabadan <[email-masked]>, "Satya Mohanty

>Hi Jorge,
>The picture in email is just for a simplified explanation. Source MAC can
>be the layer 3 device connecting to CE3, CE3 will not drop the frame so
>easily. This is an absolutely loop.
>
>Thanks,
>weiguo
>
>>>is
>>>loop
>>>>both act as PE for some transiet time.
>>>>
>>>>>>is
>>>>>>>control
>>>>>>>PEs
>>>>>>>joins
>>>>>>>If
>>>>>>>      *Subject: *RE: [bess] Handshaking among PEs in an EVPN ES
>>>>>>>based
>>>>>>>on
>>>>>>>      Paxos algorithm
>>>>>>>
>>>>>>>          Hi Patrice,
>>>>>>>
>>>>>>>          Up to reception timer traffic disruption in transient
>>>>>>>phase
>>>>>>>is
>>>>>>>          one of the issues.
>>>>>>>
>>>>>>>          Thanks,
>>>>>>>
>>>>>>>          weiguo
>>>>>>>
>>>>>>>
>>>>>>>              traffic duplication by configuring long reception
>>>>>>>timer
>>>>>>>on
>>>>>>>u
>>>>>>>t
>>>>>>_____________________________________________________________________
>>>>>>_
>>>>>>_
>>>>>>_
>>>>>>_

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 27 Mar 2015 17:13:41 +0000

LAG (Link Aggregation Group) is what stops the loop. The CE will not forward back to the PE.
PE-->CE-->PE is prevented, because the links from CE to PE is a LAG.

--
Jakob Heitz.

> On Mar 27, 2015, at 11:54 AM, Rabadan, Jorge (Jorge) <[email-masked]> wrote:
> 
> Hi Weiguo,
> 
> As I said:

---

From: <[email-masked]>
Date: Fri, 27 Mar 2015 19:08:45 -0400

Hi Jorge,

> If you have any other scenario, let’s talk offline. We are boring people

I think its nice to keep the discussion on the list, which is here for a 
reason (that is, not just for polls for adoption and WG last calls...).

I'm sure these clarifications can be useful for some of the 
participants, and the others can very much skip the thread.

And there is, I think, perhaps one more thing worth spelling out.

RFC7432 explains that for multi-homing in active-active mode, LAG is 
required.
My understanding of the reason why, in this case, it is not supported to 
connect the bridged
network via multiple CEs is that there is no technique to build a LAG 
between two CEs and two PEs.

Best,

-Thomas

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Sat, 28 Mar 2015 03:52:46 +0000

Hi Thomas,

You are right.

Kishore, Weiguo and I were discussing face-to-face the scenario drawn by
Weiguo below. And my conclusion is that there is no loop and there is
nothing new that it was not discussed in this thread. EVPN single-active
and split-horizon procedures take care of loops. If there are transient
DF-DF periods, you can get some duplicate packets, but not infinite loops.
And an implementation should allow a configurable timer that can be
adjusted to the scale of the network so that the dual DF transient risk
can be minimized or eliminated.

About why all-active is not supported in the scenario below, I agree with
your reasoning. RFC7432 only accepts LAG for all-active, since, otherwise,
duplicate packets could be forwarded in normal state.
draft-ietf-bess-dci-evpn-overlay-00 proposes an all-active MH network
solution, but that is because EVPN runs in the access network too.

Thanks.
Jorge

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Organization: Orange
Date: Friday, March 27, 2015 at 4:08 PM
To: Jorge Rabadan <[email-masked]>, Haoweiguo
<[email-masked]>, "Satya Mohanty (satyamoh)" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

>>>> Let give you another indefinitely forwarding loop case, the picture
>>>>is as
>>>> follows:
>>>>
>>>> CE3------------CE4
>>>>   |                        |
>>>> PE3                   PE4
>>>>
>>>>
>>>>
>>>> PE1                   PE2
>>>> |                         |
>>>> CE1------------CE2
>>>>
>>>>CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3-->CE4--->PE4-
>>>>--
>>>> -
>>>>> forever......
>>>>but
>>>>> Sorry, maybe i have not explain clearly, pls allow me to clarify it
>>>>>more
>>>>> clearly.
>>>>>CE2
>>>>>receive
>>>>>>be
>>>>>>PE
>>>>>>>that
>>>>>>>>>have
>>>>>>>>>mechanism
>>>>>>>>> We have already established that your proposal is untenable
>>>>>>>>>because
>>>>>>>>> of
>>>>>>>>> its control plane load.
>>>>>>>>>
>>>>>>>>>       you are not the intended recipient (or authorized to
>>>>>>>>>receive
>>>>>>>>> for
>>>>>>>>>           receive for the recipient), please contact the sender
>>>>>>>>>by
>>>>>>>>> reply
>>>>>>>>>                Firstly i think EVPN community should reach
>>>>>>>>>consensus
>>>>>>>>> on
>>>>>>>>>               question for its progressing. But if your draft
>>>>>>>>>have
>>>>>>>>> not
>>>>>>>>>               *Subject:* RE: [bess] Handshaking among PEs in an
>>>>>>>>>EVPN
>>>>>>>>> ES
>>>>>>>>>               based on Paxos algorithm
>>>>>>>>>
>>>>>>>>>               Weiguo,
>>>>>>>>>
>>>>>>>>>               also can¹t use the Per EVI Ethernet AD route
>>>>>>>>>because
>>>>>>>>> that
>>>>>>>>>               that it renders your draft moot, even if it could
>>>>>>>>>be
>>>>>>>>> made
>>>>>>>>>               to work.
>>>>>>>>>
>>>>>>>>>               Yours Irrespectively,
>>>>>>>>>
>>>>>>>>>               John
>>>>>>>>>
>>>>>>>>>               *From:*BESS [mailto:[email-masked]] *On
>>>>>>>>>Behalf
>>>>>>>>> Of
>>>>>>>>>               *Haoweiguo
>>>>>>>>>               *Subject:* Re: [bess] Handshaking among PEs in an
>>>>>>>>>EVPN
>>>>>>>>> ES
>>>>>>>>>               based on Paxos algorithm
>>>>>>>>>
>>>>>>>>>               Hi Ali,
>>>>>>>>>
>>>>>>>>>               disruption can't be tolerated for service
>>>>>>>>>providers,
>>>>>>>>> it
>>>>>>>>>               should be improved.
>>>>>>>>>
>>>>>>>>>               Also for accuracy, i think handshaking state
>>>>>>>>>machine
>>>>>>>>> on
>>>>>>>____________________________________________________________________
>>>>>>>__
>>>>>>> _
>>>>>>> _
>>>>>>> _
>>>>>>> _