Hi Weiguo,

As I said:
"Even if CE3 forwards to CE4->PE4, PE4 is NDF and will discard the frame.
Remember MH network ES' as per your diagram below, only support
single-active MH.”

So there is NO LOOP.

If you have any other scenario, let’s talk offline. We are boring people
;-)


Thanks.
Jorge

-----Original Message-----
From: Haoweiguo <[email protected]>
Date: Friday, March 27, 2015 at 9:00 AM
To: Jorge Rabadan <[email protected]>, "Satya Mohanty
(satyamoh)" <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>
Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos
algorithm

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

_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess

Reply via email to