Hi Thomas, Pls see inline with [weiguo]. Thanks, weiguo
________________________________________ From: BESS [[email protected]] on behalf of [email protected] [[email protected]] Sent: Friday, March 27, 2015 10:50 To: [email protected] Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm Hi, Let me attempt at clarifying the exchange between the few of you. My understanding is that: - RFC7432 already does a good job of avoiding forwarding loops thanks to the split-horizon procedure that does not depend on DF election and has no transient state - 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(In my draft, i described it into short time traffic disruption, no state consistency between PEs is blamed for the transient loop or traffic disruption). John and patrice think current DF election has no transiet loop problem. * the transient period correspond to BGP route propagation times (not to the DF election delay, although the wording in RFC 7432 could be made clearer) [weiguo]: Based on the assumption of strict timer clock synchronization on different PEs, the transiet period is BGP route propagation timer. In real world, no strict timer clock sync. If NTP is used for timer sync, timer difference will be large,say A seconds. So in NTP case, the transiet period is A+ BGP route propagation timer or A- BGP route propagation timer. Up to the transiet timer difference traffic loop is normally not allowed in etherent network, because unlike IP frame, ethernet header has no TTL, Up to 1 second or multiple seconds transiet loop will cause whole network crashes. * during this period, if PEs do not block BUM traffic, some traffic may be lost * during this period, if PEs do not block BUM traffic, some traffic may be duplicated, but this is not considered very harmful and hence preferred to packet loss [weiguo]: During this period, dual DF PE will exist during DF re-election period, traffic loop and duplication will happen. When a PE fails and recover again, it will trigger DF re-election. The opinion, as I understand, that has been expressed by some is that the reduction of the transient period where duplicates may arise, is not worth the cost of an handshaking approach. [weiguo]: I think at any time in any case, traffic loop is not allowed although the transiet timer maybe very short. In ethernet network, no traffic loop is not allowed. HTH, -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-route/ > > -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 _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
