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 ________________________________________ From: John E Drake [[email protected]] Sent: Friday, March 27, 2015 23:22 To: Haoweiguo; Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT - [email protected]; [email protected] Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm 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 > -----Original Message----- > From: BESS [mailto:[email protected]] On Behalf Of Haoweiguo > Sent: Friday, March 27, 2015 11:12 AM > To: Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT - > [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.h > tml> > >>>>> 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.h > tml> > >>>>> 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-r > >>>>>out > >>>>>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 _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
