Hi Satya, Pls see below with [weiguo]. Further discussions are welcome.
Thanks, weiguo ________________________________ From: Satya Mohanty (satyamoh) [[email protected]] Sent: Thursday, March 26, 2015 17:40 To: Haoweiguo; John E Drake; Ali Sajassi (sajassi); [email protected] Subject: Re: [bess] Handshaking among PEs in an EVPN ES based on Paxos algorithm Hi Weiguo, I read your draft. Your proposal introduces quite a bit of overhead as John has pointed out. [weiguo]; More AD routes advertisements overhead is introduced,but i think it's not so much. I think the benefit deserves for the overhead. It can effectively reduce traffic disruption during transiet time. It is indeed bringing the role of AD routes into the DF election which has been intentionally kept separate so far. [weiguo]: Yes, AD routes are re-used for DF election handshaking process. As draft draft-rabadan-bess-evpn-ac-df-01 points out, DF election on each multi-homed PE also should consider AD route, not just ES route. As John points out, the AD routes will now be advertised ever so often, even to remote PEs that do not host the same Ethernet Segment. [weiguo]: Not so often, only in the DF election and re-election phase, one more copy of AD routes per PE are advertised. The per ES AD route also carries all the Route-Targets of all the EVIs, so anytime you want to advertise it again, it will need to be advertised with all these Route-Targets. It imposes quite a processing overhead as far as the extended communities are concerned. [weiguo]: Only when VLAN configuration change, PE joins or leaves ESI and etc will trigger the DF election and re-election, in normal operating envionment, these events will not happen frequently. By this proposed feedback mechanism, it is going to delay the DF election. [weiguo]: Yes, to ensure that all PEs of one ESI take action consistently. If DF PE and non-DF PE take action independantly, there will be some time traffic disruption. Handshaking mechanism is common in native ethernet world, such as MSTP. EVPN access network belongs to native ethernet world, it needs a more accurate mechanism. In section 3 of https://tools.ietf.org/html/draft-hao-bess-evpn-df-handshaking-00 you mention a sequence number but it is not clear how you use it. [weiguo]: The seq number is generated at DF PE. When a PE is elected as DF PE, it should generate a seq number. Each handshaking message will use the seq number to ensure it is for same DF election process , it is used to avoid message interaction disorder. Assuming PE1 is DF PE, it generates seq number 5, PE2 and PE3 use seq 5 to communicate with PE1. Before the handshaking negotication ends, another PE4 joins same ESI, PE1 is still DF, so PE1 wants to start a new handshaking process, it needs to generate a new seq number 6 to avoid message interaction confusing. I think the seq number mechanism can enhance reliability. If you and the comunity experts have better mechanism, i can also change it. How does the scheme work when the PE reboots ? [weiguo]: When PE reboots, the process: 1. Local ESI discovery 2.Multi-homed PE auto-discovery 3.When reception timer expires, DF election handshaking. 4. DF PE and non-DF PE take effect, and enters into stable state. How will it remember the sequence number? [weiguo]: Don't need remember the seq. When PE restarts, the seq is generated from the start. Normally a device reboot timer needs several min. Its a bit uncooked in the draft. Best, --Satya From: Haoweiguo <[email protected]<mailto:[email protected]>> Date: Wednesday, March 25, 2015 8:38 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Ali Sajassi (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
