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 protected]> wrote: > > 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 protected]> > Date: Friday, March 27, 2015 at 9:00 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, >> 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 >> >> ________________________________________ >> From: Rabadan, Jorge (Jorge) [[email protected]] >> Sent: Friday, March 27, 2015 23:39 >> 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, >> >> 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-ro >>>>>>>> u >>>>>>>> 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 > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
