Hi, Given the interest and technical discussions on the topic of the EVPN DF Election, and the favorable response of the community to the benefits of the HRW scheme, I would like to request the WG to adopt draft-mohanty-bess-evpn-df-election.
Thanks to Jakob Heitz for presentation of slides at the IETF. Best regards, --Satya On 3/27/15 8:52 PM, "Rabadan, Jorge (Jorge)" <[email protected]> wrote: >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.ht >>>>>>>>>>m >>>>>>>>>>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.ht >>>>>>>>>>m >>>>>>>>>>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
