Thanks for the reference Thomas. As I was saying in my email, this prevents the loop in Weiguo’s diagram, since only single-active is supported in Weiguo’s example.
Thank you. Jorge -----Original Message----- From: "[email protected]" <[email protected]> Organization: Orange Date: Friday, March 27, 2015 at 8:40 AM To: "[email protected]" <[email protected]> Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm >HI Weigo, all, > >Let me try to help again... > >RFC7432, section 8.5 says: > > If a bridged network is multihomed to more than one PE in an EVPN > network via switches, then the support of All-Active redundancy mode > requires the bridged network to be connected to two or more PEs using > a LAG. > > If a bridged network does not connect to the PEs using a LAG, then > only one of the links between the bridged network and the PEs must be > the active link for a given <ES, VLAN> or <ES, VLAN bundle>. In this > case, the set of Ethernet A-D per ES routes advertised by each PE > MUST have the "Single-Active" bit in the flags of the ESI Label > extended community set to 1. > >My understanding was that the above excludes the kind of topology in >which you exclude a possible loop. > >-Thomas > > > >Weiguo : >> Hi John, >> If you can tolerate indefinite forwarding loop during transiet time, i >>have no problem. If the community think it is a serious problem, i think >>we must propose an applicable solution for it, maybe there are other >>solutions better than handshaking mechanism. >> >> Thanks, >> weiguo >> >> ________________________________________ >> From: John E Drake [[email protected]] >> Sent: Friday, March 27, 2015 23:22 >> To: Haoweiguo; Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT - >>[email protected]; [email protected] >> Subject: RE: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>algorithm >> >> I think we have beaten this topic to death. For the numerous reason >>I've given, I'm not interested in you proposal. >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: BESS [mailto:[email protected]] On Behalf Of Haoweiguo >>> Sent: Friday, March 27, 2015 11:12 AM >>> To: Rabadan, Jorge (Jorge); Satya Mohanty (satyamoh); EXT - >>> [email protected]; [email protected] >>> Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>> algorithm >>> >>> Hi Jorge, >>> Let give you another indefinitely forwarding loop case, the picture is >>>as >>> follows: >>> >>> CE3------------CE4 >>> | | >>> PE3 PE4 >>> >>> >>> >>> PE1 PE2 >>> | | >>> CE1------------CE2 >>> >>> If PE1 and PE2 are dual DF PE in transiet time, assuing PE3 and PE4 >>>are in >>> stable state ,PE3 is DF PE, PE4 is non-DF PE, the BUM traffic from CE3 >>>to CE1, >>> the forwarding loop path is as follows; >>> >>>CE3--->PE3------>PE2--->CE2---->CE1---->PE1---->PE3-->CE3-->CE4--->PE4-- >>>-- >>>> forever...... >>> Do you think the harm is enough? >>> Thanks, >>> weiguo >>> ________________________________________ >>> From: Rabadan, Jorge (Jorge) [[email protected]] >>> Sent: Friday, March 27, 2015 22:59 >>> To: Haoweiguo; Satya Mohanty (satyamoh); [email protected]; >>> [email protected] >>> Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>> algorithm >>> >>> Hi Weiguo, >>> >>> OK, thanks for clarifying, that is the part I did not understand in >>>your loop :-) >>> >>> To me a loop means you send a frame and that frame keeps being >>>forwarded >>> by the same nodes indefinitely till you take a corrective action. >>> In this case, CE3 might get a few packets during the transient state, >>>but those >>> packets will have its own MAC SA so CE3 will discard them. I don't >>>think that is >>> harmful for CE3 in most of the cases. And if it is, you just need to >>>make sure >>> the timers are long enough and the DF election properly implemented to >>> avoid the transient DF-DF state. >>> >>> The handshaking is definitely overkilling IMHO. >>> >>> Thanks. >>> Jorge >>> >>> -----Original Message----- >>> From: Haoweiguo <[email protected]> >>> Date: Friday, March 27, 2015 at 7:29 AM >>> To: Jorge Rabadan <[email protected]>, "Satya Mohanty >>> (satyamoh)" <[email protected]>, "[email protected]" >>> <[email protected]>, "[email protected]" <[email protected]> >>> Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>> algorithm >>> >>>> Hi Jorge, >>>> Sorry, maybe i have not explain clearly, pls allow me to clarify it >>>> more clearly. >>>> In MHN case, assuming CE1 and CE2 are multti-homed to PE1 and PE2, CE2 >>>> is single homed to remote PE3. CE1 and CE2 forms one layer 2 network, >>>> so it multi-homed network scenario. >>>> CE3 >>>> | >>>> PE3 >>>> >>>> >>>> PE1 PE2 >>>> | | >>>> CE1-----------CE2 >>>> >>>> In transiet period, PE1 and PE2 are both DF PE. At this time, CE3 >>>>sends >>>> BUM traffic to CE1, the traffic will reach PE1 and PE2, CE1 will >>>> receive two copy of the traffic from CE3, also loop is formed, the >>>>form path: >>>> >>>> CE3---->PE3---->PE2---->CE2---->CE1---->PE1--->PE3--->CE3 >>>> >>>> I think the traffic loop is absolutely not allowed. In MHN case, the >>>> loop will formed due to dual-DF PE in transiet period. >>>> >>>> Thanks, >>>> weiguo >>>> >>>> >>>> >>>> ________________________________________ >>>> From: Rabadan, Jorge (Jorge) [[email protected]] >>>> Sent: Friday, March 27, 2015 20:26 >>>> To: Haoweiguo; Satya Mohanty (satyamoh); [email protected]; >>>> [email protected] >>>> Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>>> algorithm >>>> >>>> Hi Weiguo, >>>> >>>> About this: >>>> >>>> [weiguo]: Traffic duplication and loop issue both exist in dual DF PE >>>> case. In multi-homed device case, say CE1 is multi-homed to PE1 and >>>>PE2 >>>> and both PE are DF PE. When CE1 sends traffic to PE1, the traffic will >>>> loop back to CE1 through PE2. If CE1 can filter and drop the traffic , >>>> it is fortunate, maybe no loop. >>>> For multi-homed network scenario, say local network1(CE1 and CE2) is >>>> multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop >>>> back through PE1-->PE2-->CE2, it is very serious. It is absolutely >>>>not allowed. >>>> >>>> >>>> [JORGE] In a MH device case: CE1->BUM->PE1->(ESI-label+BUM)->PE2. PE2 >>>> will not send the traffic back to CE1 due to the ESI-label and >>>> split-horizon procedures. >>>> In MH network case PE2 will NOT send the traffic to CE2 for the same >>>> reason. >>>> >>>> Let me know if you disagree please. >>>> >>>> Thanks. >>>> Jorge >>>> >>>> -----Original Message----- >>>> From: Haoweiguo <[email protected]> >>>> Date: Thursday, March 26, 2015 at 9:55 PM >>>> To: "Satya Mohanty (satyamoh)" <[email protected]>, >>>> "[email protected]" <[email protected]>, >>> "[email protected]" >>>> <[email protected]> >>>> Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos >>>> algorithm >>>> >>>>> Hi Satya, >>>>> Pls see inline. >>>>> >>>>> Thanks, >>>>> weiguo >>>>> >>>>> ________________________________________ >>>>> From: Satya Mohanty (satyamoh) [[email protected]] >>>>> Sent: Friday, March 27, 2015 12:11 >>>>> To: Haoweiguo; [email protected]; [email protected] >>>>> Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on >>>>>Paxos >>>>> algorithm >>>>> >>>>> Thomas, >>>>> >>>>> Thanks for your summary. It captures the essence of the discussion. >>>>> [weiguo]: Yes, i agree. >>>>> >>>>> One feature of the HRW scheme is that it computes the Active and the >>>>> Backup DF upfront. >>>>> Whenever the Active PE, say PE1, dies; the Backup PE, PE2, can become >>>>> the Active immediately upon receiving the withdraw of the ES route >>>> >from PE1. >>>>> It need not even have to wait for the 3 seconds time. >>>>> [weiguo]: I think maybe your negligence, dies PE1 can't send withdraw >>>>> message:) But when PE1 leaves ESI, it can withdraw the ES route >>>>> immediately. >>>>> When PE1 dies and recovers, assuming PE1 is DF PE, then PE1 and PE2 >>>>> will both act as PE for some transiet time. >>>>> >>>>> On the other hand, the 3 second timer will serve as a bulk and batch >>>>> mechanism for the case when new PE(s) is(are) coming up, so we don¹t >>>>> have to do a DF election ever so often. >>>>> >>>>> Haoweiguo, I think the "loop" scenario is speculative. >>>>> I think everybody understands that, yes, there may be some transient >>>>> duplication of bum traffic; however, there is no "loop" problem to be >>>>> solved. >>>>> [weiguo]: Traffic duplication and loop issue both exist in dual DF PE >>>>> case. In multi-homed device case, say CE1 is multi-homed to PE1 and >>>>> PE2 and both PE are DF PE. When CE1 sends traffic to PE1, the traffic >>>>> will loop back to CE1 through PE2. If CE1 can filter and drop the >>>>> traffic , it is fortunate, maybe no loop. >>>>> For multi-homed network scenario, say local network1(CE1 and CE2) is >>>>> multi-homed to PE1 and PE2. Similarly, the traffic from CE1 will loop >>>>> back through PE1-->PE2-->CE2, it is very serious. It is absolutely >>>>>not >>>>> allowed. >>>>> >>>>> Thanks, >>>>> --Satya >>>>> >>>>> >>>>> >>>>> On 3/26/15 9:08 PM, "Haoweiguo" <[email protected]> wrote: >>>>> >>>>>> Hi Thomas, >>>>>> I know you are neutral, sorry for my reply vulnerable to be >>>>>> miunderstood. >>>>>> >>>>>> Thanks, >>>>>> weiguo >>>>>> >>>>>> ________________________________________ >>>>>> From: [email protected] [[email protected]] >>>>>> Sent: Friday, March 27, 2015 11:59 >>>>>> To: Haoweiguo; [email protected] >>>>>> Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on >>>>>> Paxos algorithm >>>>>> >>>>>> Hi Weiguo, >>>>>> >>>>>> 2015-03-26, Haoweiguo: >>>>>>> Thomas: >>>>>>>> - RFC7432 may have transient periods where the DF election state >>>>>>>> is not yet synchronized between the two peers: >>>>>>> [weiguo]: Yes, i think RFC 7432 has transient periods of traffic >>>>>>> loop >>>>>> Note well that I didn't write that there can be transient _loops_ . >>>>>> I tried to capture the exchange you had all, and what I gather is >>>>>> that the split-horizon procedure _prevents_loops_, independently of >>>>>> any transient period where DF state is not synchronized and which >>>>>>may >>>>>> lead to transient _duplicates_. >>>>>> >>>>>> -Thomas >>>>>> >>>>>>> 26/03/2015 20:05, John E Drake : >>>>>>>> Weiguo, >>>>>>>> >>>>>>>> I guess I wasn¹t clear. I think you draft, for the reasons I have >>>>>>>> detailed, is a non-solution to a non-problem with tremendous >>>>>>>> control plane cost. >>>>>>>> >>>>>>>> Yours Irrespectively, >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> *From:*Haoweiguo [mailto:[email protected]] >>>>>>>> *Sent:* Thursday, March 26, 2015 6:17 PM >>>>>>>> *To:* John E Drake; Patrice Brissette (pbrisset) >>>>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] >>>>>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on >>>>>>>> Paxos algorithm >>>>>>>> >>>>>>>> Pls see below. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> weiguo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>------------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - >>>>>>>> >>>>>>>> *From:*John E Drake [[email protected]] >>>>>>>> *Sent:* Friday, March 27, 2015 6:00 >>>>>>>> *To:* Haoweiguo; Patrice Brissette (pbrisset) >>>>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]> >>>>>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on >>>>>>>> Paxos algorithm >>>>>>>> >>>>>>>> To recap, >>>>>>>> >>>>>>>> We have established that your proposal is untenable because of its >>>>>>>> control plane load. >>>>>>>> >>>>>>>> We have established that your proposal is based upon a flawed >>>>>>>> understanding of the DF election in RFC 7432. >>>>>>>> >>>>>>>> [weiguo]: In ethernet world, traffic loop is serious than short >>>>>>>> timer traffic disruption. If you want to implement transiet >>>>>>>> traffic loop process, i will modify my draft to solve your issue. >>>>>>>> >>>>>>>> If i am the developer, i will prefer short timer traffic >>>>>>>> disruption based on current EVPN protocol. >>>>>>>> >>>>>>>> What you are now arguing is that your draft prevents two or more >>>>>>>> PEs from being DF simultaneously. This is clearly nonsense. >>>>>>>> >>>>>>>> [weiguo]: I will modify the draft problem statements, and use the >>>>>>>> same handshaking solution to solve it. >>>>>>>> >>>>>>>> Furthermore, we have established that having two or more DFs for >>>>>>>> what even you admit is a brief transient leads to duplicate >>>>>>>> traffic, which is acceptable, but not loops, your assertion to the >>> contrary. >>>>>>>> [weiguo]: It is transient loop and traffic duplication issue. >>>>>>>> >>>>>>>> Yours Irrespectively, >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> *From:*Haoweiguo [mailto:[email protected]] >>>>>>>> *Sent:* Thursday, March 26, 2015 5:37 PM >>>>>>>> *To:* John E Drake; Patrice Brissette (pbrisset) >>>>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]> >>>>>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on >>>>>>>> Paxos algorithm >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> As your understanding of the EVPN draft, the DF election mechanism >>>>>>>> has more serious side effect, it will have short time traffic >>>>>>>> loop,i.e., dual DF PEs will exist for a short time. I think dual >>>>>>>> DF PEs is absolutely not tolerated, because native ethernet >>>>>>>>header >>>>>>>> has no TTL, up to several hundred ms traffic loop normally not >>>>>>>> tolerated in commertial networks. >>>>>>>> >>>>>>>> As your understanding, the PEs should do as following: >>>>>>>> >>>>>>>> 1. Accurate timer sync. NTP accuracy is bad, 1588v2 is good but >>>>>>>> have rarely deployment. >>>>>>>> >>>>>>>> Assuming PE1,PE2 and PE3 have consistent timer clock, when PE3 >>>>>>>> joins ESI and trigger DF re-election. When reception timer >>>>>>>>expires: >>>>>>>> >>>>>>>> PE1 upgrades to DF PE. >>>>>>>> >>>>>>>> After reception timer+ ES route transmission timer: >>>>>>>> >>>>>>>> PE2 downloads to non-DF PE. >>>>>>>> >>>>>>>> So in timer clock sync case, dual DF PEs will exist at least >>>>>>>> transmission timer. >>>>>>>> >>>>>>>> If NTP is used for timer sync, because it has bad accuracy, dual >>>>>>>> DF PEs will exist more longer timer. >>>>>>>> >>>>>>>> So as your understanding for DF election, the drawback is more >>>>>>>>clear. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> weiguo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>------------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - >>>>>>>> >>>>>>>> *From:*John E Drake [[email protected]] >>>>>>>> *Sent:* Friday, March 27, 2015 4:41 >>>>>>>> *To:* Haoweiguo; Patrice Brissette (pbrisset) >>>>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]> >>>>>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on >>>>>>>> Paxos algorithm >>>>>>>> >>>>>>>> Weiguo, >>>>>>>> >>>>>>>> We have already established that your proposal is untenable >>>>>>>> because of its control plane load. >>>>>>>> >>>>>>>> What we are now discussing is that your proposal is based upon a >>>>>>>> misunderstanding of the algorithm in RFC 7432. You are assuming >>>>>>>> that >>>>>>>> PE1 will advertise an ES route and then wait for the configured >>>>>>>> interval before performing the DF election while PE2 and PE3 will >>>>>>>> perform the DF election as soon as they receive the ES route from >>>>>>>> PE1. >>>>>>>> This is not what RFC 7432 says. >>>>>>>> >>>>>>>> Rather, what is says is that the advertisement of the ES route by >>>>>>>> PE1 and its receipt by PE2 and PE3 causes all three PEs to start >>>>>>>> the configured interval timer - ³3. When the timer expires, each >>>>>>>> PE builds an ordered list of the IP addresses of all the PE nodes >>>>>>>> connected to the Ethernet segment (including itself), in >>>>>>>> increasing numeric value.² >>>>>>>> >>>>>>>> Yours Irrespectively, >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> *From:*Haoweiguo [mailto:[email protected]] >>>>>>>> *Sent:* Thursday, March 26, 2015 3:26 PM >>>>>>>> *To:* John E Drake; Patrice Brissette (pbrisset) >>>>>>>> *Cc:* Ali Sajassi (sajassi); [email protected] <mailto:[email protected]> >>>>>>>> *Subject:* RE: [bess] Handshaking among PEs in an EVPN ES based on >>>>>>>> Paxos algorithm >>>>>>>> >>>>>>>> Pls read my detail replies to Satya. If you still can't catch it, >>>>>>>> pls read my draft and EVPN base protocol, thanks >>>>>>>> >>>>>>>> weiguo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>------------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - >>>>>>>> >>>>>>>> *From:*John E Drake [[email protected]] >>>>>>>> *Sent:* Friday, March 27, 2015 1:28 >>>>>>>> *To:* Patrice Brissette (pbrisset) >>>>>>>> *Cc:* Haoweiguo; Ali Sajassi (sajassi); [email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> *Subject:* Re: [bess] Handshaking among PEs in an EVPN ES based on >>>>>>>> Paxos algorithm >>>>>>>> >>>>>>>> I think Patrice is correct. Your proposal doesn't solve the >>>>>>>> problem and it does so at huge cost. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> >>>>>>>> On Mar 26, 2015, at 10:34 AM, Patrice Brissette (pbrisset) >>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> Weiguo, >>>>>>>> >>>>>>>> I¹m not sure I¹m following here. >>>>>>>> >>>>>>>> Don¹t you have the same issue with your handshaking >>>>>>>>mechanism? >>>>>>>> >>>>>>>> If you don¹t know your peer, how can you handshake? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Patrice >>>>>>>> >>>>>>>> Image removed by sender. >>>>>>>> >>>>>>>> *Patrice Brissette* >>>>>>>> TECHNICAL LEADER.ENGINEERING >>>>>>>> >>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>> Phone: *+1 613 254 3336* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE* >>>>>>>> Canada >>>>>>>> Cisco.com <http://www.cisco.com/global/CA/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Image removed by sender.Think before you print. >>>>>>>> >>>>>>>> This email may contain confidential and privileged material >>>>>>>>for >>>>>>>> the sole use of the intended recipient. Any review, use, >>>>>>>> distribution or disclosure by others is strictly >>>>>>>>prohibited. If >>>>>>>> you are not the intended recipient (or authorized to >>>>>>>>receive for >>>>>>>> the recipient), please contact the sender by reply email and >>>>>>>> delete all copies of this message. >>>>>>>> >>>>>>>> Please click here >>>>>>>> >>>>>>>> <http://www.cisco.com/web/about/doing_business/legal/cri/index.h >>> tml> >>>>>>>> for Company Registration Information. >>>>>>>> >>>>>>>> >>>>>>>> *From: *Haoweiguo <[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>> *Date: *Thursday, March 26, 2015 at 10:24 AM >>>>>>>> *To: *Patrice Brissette <[email protected] >>>>>>>> <mailto:[email protected]>>, John E Drake >>>>>>>><[email protected] >>>>>>>> <mailto:[email protected]>>, Ali Sajassi <[email protected] >>>>>>>> <mailto:[email protected]>>, "[email protected] >>>>>>>> <mailto:[email protected]>" <[email protected] >>>>>>>><mailto:[email protected]>> >>>>>>>> *Subject: *RE: [bess] Handshaking among PEs in an EVPN ES >>>>>>>> based on >>>>>>>> Paxos algorithm >>>>>>>> >>>>>>>> Hi Patrice, >>>>>>>> >>>>>>>> Up to reception timer traffic disruption in transient >>>>>>>> phase is >>>>>>>> one of the issues. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> weiguo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>------------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - >>>>>>>> >>>>>>>> *From:*Patrice Brissette (pbrisset) [[email protected] >>>>>>>> <mailto:[email protected]>] >>>>>>>> *Sent:* Thursday, March 26, 2015 20:54 >>>>>>>> *To:* Haoweiguo; John E Drake; Ali Sajassi (sajassi); >>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>> *Subject:* Re: [bess] Handshaking among PEs in an EVPN >>>>>>>>ES >>>>>>>> based on Paxos algorithm >>>>>>>> >>>>>>>> Weiguo, >>>>>>>> >>>>>>>> You mention "But if your draft have not solved all >>>>>>>> issues², >>>>>>>> >>>>>>>> Can you explain what Satya¹s draft is not solving? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Patrice >>>>>>>> >>>>>>>> Image removed by sender. >>>>>>>> >>>>>>>> *Patrice Brissette* >>>>>>>> TECHNICAL LEADER.ENGINEERING >>>>>>>> >>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>> Phone: *+1 613 254 3336* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Cisco Systems Canada Co. / Les Systemes Cisco Canada >>>>>>>>CIE* >>>>>>>> Canada >>>>>>>> Cisco.com <http://www.cisco.com/global/CA/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Image removed by sender.Think before you print. >>>>>>>> >>>>>>>> This email may contain confidential and privileged >>>>>>>>material >>>>>>>> for the sole use of the intended recipient. Any review, >>>>>>>>use, >>>>>>>> distribution or disclosure by others is strictly >>>>>>>>prohibited. >>>>>>>> If you are not the intended recipient (or authorized to >>>>>>>> receive for the recipient), please contact the sender by >>>>>>>> reply >>>>>>>> email and delete all copies of this message. >>>>>>>> >>>>>>>> Please click here >>>>>>>> >>>>>>>> <http://www.cisco.com/web/about/doing_business/legal/cri/index.h >>> tml> >>>>>>>> for Company Registration Information. >>>>>>>> >>>>>>>> >>>>>>>> *From: *Haoweiguo <[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>> *Date: *Wednesday, March 25, 2015 at 10:38 PM >>>>>>>> *To: *John E Drake <[email protected] >>>>>>>> <mailto:[email protected]>>, Ali Sajassi >>>>>>>><[email protected] >>>>>>>> <mailto:[email protected]>>, "[email protected] >>>>>>>> <mailto:[email protected]>" <[email protected] >>>>>>>> <mailto:[email protected]>> >>>>>>>> *Subject: *Re: [bess] Handshaking among PEs in an EVPN >>>>>>>>ES >>>>>>>> based on Paxos algorithm >>>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> Firstly i think EVPN community should reach >>>>>>>> consensus on >>>>>>>> the issues of current DF election mechanism. All >>>>>>>>these >>>>>>>> issues should be resolved in a single new DF >>>>>>>>election >>>>>>>> draft,rather than in multiple separate drafts. If >>>>>>>>your >>>>>>>> draft can solve all these issues and stable, i have >>>>>>>>no >>>>>>>> question for its progressing. But if your draft >>>>>>>>have not >>>>>>>> solved all issues, i think it had better combine >>>>>>>>with >>>>>>>> other drafts to provide a comprehensive solution. I >>>>>>>> think >>>>>>>> the issues listed in >>>>>>>>draft-rabadan-bess-evpn-ac-df-01 >>>>>>>> and >>>>>>>> draft-hao-bess-evpn-df-handshaking-00 is valid, it >>>>>>>> should >>>>>>>> be resolved. So i think although your new Hash >>>>>>>>algorithm >>>>>>>> for DF election is good, it only includes partial >>>>>>>> enhancements, maybe it still needs some time for >>>>>>>> consensus. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> weiguo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>------------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - >>>>>>>> >>>>>>>> *From:*John E Drake [[email protected] >>>>>>>> <mailto:[email protected]>] >>>>>>>> *Sent:* Thursday, March 26, 2015 7:16 >>>>>>>> *To:* Haoweiguo; Ali Sajassi (sajassi); >>>>>>>>[email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> *Subject:* RE: [bess] Handshaking among PEs in an >>>>>>>> EVPN ES >>>>>>>> based on Paxos algorithm >>>>>>>> >>>>>>>> Weiguo, >>>>>>>> >>>>>>>> Your proposal introduces a control plane processing >>>>>>>>load >>>>>>>> that is O(#EVIs * PEs) per DF election and given >>>>>>>>that >>>>>>>> there can be 4K EVIs per ES, this looks like a >>>>>>>> **substantial** load. Furthermore, >>>>>>>> >>>>>>>> you can¹t use the ES route to co-ordinate DF >>>>>>>>election >>>>>>>> because you would need to carry your new extended >>>>>>>> community for each EVI and they would not all fit. >>>>>>>>You >>>>>>>> also can¹t use the Per EVI Ethernet AD route because >>>>>>>> that >>>>>>>> is processed by all PEs in the EVI. >>>>>>>> >>>>>>>> I think that from a practical perspective the new DF >>>>>>>> election proposed in Satya¹s draft is sufficiently >>>>>>>> stable >>>>>>>> that it renders your draft moot, even if it could be >>>>>>>> made >>>>>>>> to work. >>>>>>>> >>>>>>>> Yours Irrespectively, >>>>>>>> >>>>>>>> John >>>>>>>> >>>>>>>> *From:*BESS [mailto:[email protected]] *On >>>>>>>>Behalf Of >>>>>>>> *Haoweiguo >>>>>>>> *Sent:* Wednesday, March 25, 2015 5:34 PM >>>>>>>> *To:* Ali Sajassi (sajassi); [email protected] >>>>>>>> <mailto:[email protected]> >>>>>>>> *Subject:* Re: [bess] Handshaking among PEs in an >>>>>>>> EVPN ES >>>>>>>> based on Paxos algorithm >>>>>>>> >>>>>>>> Hi Ali, >>>>>>>> >>>>>>>> Thanks for your information. I scanned through this >>>>>>>> draft, >>>>>>>> it really introduces inter-chassis message for DF >>>>>>>> election >>>>>>>> handshaking, the requirements in this draft is to >>>>>>>> eliminate transiet Loop and traffic duplication. >>>>>>>>Current >>>>>>>> EVPN DF election mechanism already eliminated loop >>>>>>>>and >>>>>>>> traffic duplication by configuring long reception >>>>>>>> timer on >>>>>>>> each multi-homed PE, but up to reception timer >>>>>>>>traffic >>>>>>>> disruption issue still exist. EVPN for DCI is an >>>>>>>> important >>>>>>>> use case for EVPN, up to reception timer traffic >>>>>>>> disruption can't be tolerated for service >>>>>>>>providers, it >>>>>>>> should be improved. >>>>>>>> >>>>>>>> Also for accuracy, i think handshaking state >>>>>>>>machine on >>>>>>>> each multi-homed PE is also needed. From solution >>>>>>>> perspective, in my draft, no inter-chassis message >>>>>>>>is >>>>>>>> introduced, only one new extended community is >>>>>>>> introduced, >>>>>>>> i think the process is comparatively simple than >>>>>>>>your >>>>>>>> following draft. >>>>>>>> >>>>>>>> Current EVPN DF election has some drawbacks, so >>>>>>>>there >>>>>>>> are >>>>>>>> three new drafts about DF election emerged. I think >>>>>>>>BESS >>>>>>>> WG can consider these three drafts in global view, a >>>>>>>> single,comprehensive new DF election draft is hoped. >>>>>>>> >>>>>>>> thanks. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> weiguo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>------------------------------------------------------------------- >>>>>>>> --- >>>>>>>> - >>>>>>>> - >>>>>>>> >>>>>>>> *From:*BESS [[email protected] >>>>>>>> <mailto:[email protected]>] on behalf of Ali >>>>>>>>Sajassi >>>>>>>> (sajassi) [[email protected] >>>>>>>><mailto:[email protected]>] >>>>>>>> *Sent:* Thursday, March 26, 2015 0:21 >>>>>>>> *To:* [email protected] <mailto:[email protected]> >>>>>>>> *Subject:* [bess] Handshaking among PEs in an EVPN >>>>>>>>ES >>>>>>>> based on Paxos algorithm >>>>>>>> >>>>>>>> FYI- First published July 4, 2011 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>https://datatracker.ietf.org/doc/draft-sajassi-l2vpn-evpn-segment-r >>>>>>>> out >>>>>>>> e >>>>>>>> / >>>>>>>> >>>>>>>> -Ali >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> BESS mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/bess >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ______________________________________________________ >>> ______________ >>>>>>> ___ >>>>>>> _ >>>>>>> _ >>>>>>> ________________________________________________ >>>>>>> >>>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>>>>> ce message par erreur, veuillez le signaler a l'expediteur et le >>>>>>> detruire ainsi que les pieces jointes. Les messages electroniques >>>>>>> etant susceptibles d'alteration, Orange decline toute >>>>>>> responsabilite si ce message a ete altere, deforme ou falsifie. >>>>>>> Merci. >>>>>>> >>>>>>> This message and its attachments may contain confidential or >>>>>>> privileged information that may be protected by law; they should >>>>>>> not be distributed, used or copied without authorisation. >>>>>>> If you have received this email in error, please notify the sender >>>>>>> and delete this message and its attachments. >>>>>>> As emails may be altered, Orange is not liable for messages that >>>>>>> have been modified, changed or falsified. >>>>>>> Thank you. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> BESS mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/bess >>>>>>> >>>>>> >>>>>> _______________________________________________________ >>> ______________ >>>>>> ___ >>>>>> _ >>>>>> _ >>>>>> _______________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>>>>diffuses, >>>>>> exploites ou copies sans autorisation. Si vous avez recu ce message >>>>>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >>>>>> que les pieces jointes. Les messages electroniques etant >>>>>>susceptibles >>>>>> d'alteration, Orange decline toute responsabilite si ce message a >>>>>>ete >>>>>> altere, deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or >>>>>> privileged information that may be protected by law; they should not >>>>>> be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender >>>>>> and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that >>>>>>have >>>>>> been modified, changed or falsified. >>>>>> Thank you. > > >__________________________________________________________________________ >_______________________________________________ > >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
