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 protected]" <[email protected]> Organization: Orange Date: Friday, March 27, 2015 at 4:08 PM To: Jorge Rabadan <[email protected]>, Haoweiguo <[email protected]>, "Satya Mohanty (satyamoh)" <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm >Hi Jorge, > >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 > > > >Rabadan, Jorge : >> 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. >> >> >> >> >> 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.htm >>>>>>>>>l> >>>>>>>>> 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.htm >>>>>>>>>l> >>>>>>>>> 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 > > >__________________________________________________________________________ >_______________________________________________ > >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
