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 protected]> Date: Friday, March 27, 2015 at 8:11 AM To: Jorge Rabadan <[email protected]>, "Satya Mohanty (satyamoh)" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm >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 protected]] >Sent: Friday, March 27, 2015 22:59 >To: Haoweiguo; Satya Mohanty (satyamoh); [email protected]; >[email protected] >Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >algorithm > >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 protected]> >Date: Friday, March 27, 2015 at 7:29 AM >To: Jorge Rabadan <[email protected]>, "Satya Mohanty >(satyamoh)" <[email protected]>, "[email protected]" ><[email protected]>, "[email protected]" <[email protected]> >Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >algorithm > >>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 protected]] >>Sent: Friday, March 27, 2015 20:26 >>To: Haoweiguo; Satya Mohanty (satyamoh); [email protected]; >>[email protected] >>Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>algorithm >> >>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 protected]> >>Date: Thursday, March 26, 2015 at 9:55 PM >>To: "Satya Mohanty (satyamoh)" <[email protected]>, >>"[email protected]" <[email protected]>, "[email protected]" >><[email protected]> >>Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>algorithm >> >>>Hi Satya, >>>Pls see inline. >>> >>>Thanks, >>>weiguo >>> >>>________________________________________ >>>From: Satya Mohanty (satyamoh) [[email protected]] >>>Sent: Friday, March 27, 2015 12:11 >>>To: Haoweiguo; [email protected]; [email protected] >>>Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>>algorithm >>> >>>Thomas, >>> >>>Thanks for your summary. It captures the essence of the discussion. >>>[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. >>> >>>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. >>>[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 >>> >>> >>> >>>On 3/26/15 9:08 PM, "Haoweiguo" <[email protected]> wrote: >>> >>>>Hi Thomas, >>>>I know you are neutral, sorry for my reply vulnerable to be >>>>miunderstood. >>>> >>>>Thanks, >>>>weiguo >>>> >>>>________________________________________ >>>>From: [email protected] [[email protected]] >>>>Sent: Friday, March 27, 2015 11:59 >>>>To: Haoweiguo; [email protected] >>>>Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>>>algorithm >>>> >>>>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 >>>> >>>>> >>>>> 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 protected]] >>>>>> *Sent:* Thursday, March 26, 2015 6:17 PM >>>>>> *To:* John E Drake; Patrice Brissette (pbrisset) >>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] >>>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on >>>>>> Paxos algorithm >>>>>> >>>>>> Pls see below. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> weiguo >>>>>> >>>>>> >>>>>>--------------------------------------------------------------------- >>>>>>- >>>>>>- >>>>>>- >>>>>> >>>>>> *From:*John E Drake [[email protected]] >>>>>> *Sent:* Friday, March 27, 2015 6:00 >>>>>> *To:* Haoweiguo; Patrice Brissette (pbrisset) >>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]> >>>>>> *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. >>>>>> >>>>>> 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 >>>>>> >>>>>> *From:*Haoweiguo [mailto:[email protected]] >>>>>> *Sent:* Thursday, March 26, 2015 5:37 PM >>>>>> *To:* John E Drake; Patrice Brissette (pbrisset) >>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]> >>>>>> *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. >>>>>> >>>>>> 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 protected]] >>>>>> *Sent:* Friday, March 27, 2015 4:41 >>>>>> *To:* Haoweiguo; Patrice Brissette (pbrisset) >>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]> >>>>>> *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. >>>>>> >>>>>> 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 protected]] >>>>>> *Sent:* Thursday, March 26, 2015 3:26 PM >>>>>> *To:* John E Drake; Patrice Brissette (pbrisset) >>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]> >>>>>> *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 protected]] >>>>>> *Sent:* Friday, March 27, 2015 1:28 >>>>>> *To:* Patrice Brissette (pbrisset) >>>>>> *Cc:* Haoweiguo; Ali Sajassi (sajassi); [email protected] >>>>>> <mailto:[email protected]> >>>>>> *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 protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> 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 >>>>>> >>>>>> Image removed by sender. >>>>>> >>>>>> *Patrice Brissette* >>>>>> TECHNICAL LEADER.ENGINEERING >>>>>> >>>>>> [email protected] <mailto:[email protected]> >>>>>> 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 protected] >>>>>><mailto:[email protected]>> >>>>>> *Date: *Thursday, March 26, 2015 at 10:24 AM >>>>>> *To: *Patrice Brissette <[email protected] >>>>>> <mailto:[email protected]>>, John E Drake <[email protected] >>>>>> <mailto:[email protected]>>, Ali Sajassi <[email protected] >>>>>> <mailto:[email protected]>>, "[email protected] >>>>>> <mailto:[email protected]>" <[email protected] <mailto:[email protected]>> >>>>>> *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 protected] >>>>>> <mailto:[email protected]>] >>>>>> *Sent:* Thursday, March 26, 2015 20:54 >>>>>> *To:* Haoweiguo; John E Drake; Ali Sajassi (sajassi); >>>>>> [email protected] <mailto:[email protected]> >>>>>> *Subject:* Re: [bess] Handshaking among PEs in an EVPN ES >>>>>> based on Paxos algorithm >>>>>> >>>>>> 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* >>>>>> TECHNICAL LEADER.ENGINEERING >>>>>> >>>>>> [email protected] <mailto:[email protected]> >>>>>> 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 protected] >>>>>> <mailto:[email protected]>> >>>>>> *Date: *Wednesday, March 25, 2015 at 10:38 PM >>>>>> *To: *John E Drake <[email protected] >>>>>> <mailto:[email protected]>>, Ali Sajassi >>>>>><[email protected] >>>>>> <mailto:[email protected]>>, "[email protected] >>>>>> <mailto:[email protected]>" <[email protected] >>>>>><mailto:[email protected]>> >>>>>> *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 protected] >>>>>> <mailto:[email protected]>] >>>>>> *Sent:* Thursday, March 26, 2015 7:16 >>>>>> *To:* Haoweiguo; Ali Sajassi (sajassi); [email protected] >>>>>> <mailto:[email protected]> >>>>>> *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 protected]] *On Behalf >>>>>>Of >>>>>> *Haoweiguo >>>>>> *Sent:* Wednesday, March 25, 2015 5:34 PM >>>>>> *To:* Ali Sajassi (sajassi); [email protected] >>>>>> <mailto:[email protected]> >>>>>> *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 protected] >>>>>> <mailto:[email protected]>] on behalf of Ali >>>>>>Sajassi >>>>>> (sajassi) [[email protected] >>>>>><mailto:[email protected]>] >>>>>> *Sent:* Thursday, March 26, 2015 0:21 >>>>>> *To:* [email protected] <mailto:[email protected]> >>>>>> *Subject:* [bess] Handshaking among PEs in an EVPN ES >>>>>> based on Paxos algorithm >>>>>> >>>>>> FYI- First published July 4, 2011 >>>>>> >>>>>> >>>>>>https://datatracker.ietf.org/doc/draft-sajassi-l2vpn-evpn-segment-rou >>>>>>t >>>>>>e >>>>>>/ >>>>>> >>>>>> -Ali >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> BESS mailing list >>>>>> [email protected] >>>>>> 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. >>>>> >>>>> _______________________________________________ >>>>> BESS mailing list >>>>> [email protected] >>>>> 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. >>>>_______________________________________________ >>>>BESS mailing list >>>>[email protected] >>>>https://www.ietf.org/mailman/listinfo/bess >>>_______________________________________________ >>>BESS mailing list >>>[email protected] >>>https://www.ietf.org/mailman/listinfo/bess >>_______________________________________________ >>BESS mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
