Hi Jorge, Let me thank you for the mail. Since this mail thread is for one particular draft. I think it is good to open a new thread for discussing another draft. May I request you to give me some time to go through it and I get back.I will open a new thread for discussing your draft.Appreciate your support.
Regards, Sudhin Jacob On Wed, 25 Nov 2015 16:29:29 +0530 "Rabadan, Jorge (Jorge)" wrote > Hi Sudhin, You may want to have a look at this draft: https://tools.ietf.org/html/draft-rabadan-bess-evpn-ac-df-02 Provides a solution for your use-case in EVPN, without any control plane changes compared to RFC7432. There are already implementations doing that. Thanks. Jorge From: BESS on behalf of sudeep g ggg Date: Wednesday, November 25, 2015 at 11:18 AM To: "satya...@cisco.com" Cc: "pbris...@cisco.com" , "bess@ietf.org" , "kisho...@juniper.net" Subject: Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02 Hi Satya, Let me thank you for your mail,it is much appreciated.You will take this in to account in next revision, much appreciated so that all will be in same page. One more thought though just a random thought.I would like to bring your kind attention.Since section 7.1 you clearly explains that you are not taking in to consideration about vlan mis configuration. My thought requires no answers from your side.But I would like to bring one case in to your frame of mind just sharing it.Once again big thank you for your reply. Section 7.1 Observe that currently the VLANs are derived from local configuration and the FSM does not provide any protection against misconfiguration where same EVI,ESI combination has different set of VLANs on different participating PEs or one of the PEs elects to consider VLANs as VLAN bundle and another as separate VLANs for election purposes (service type mismatch). for example PE1 loopback 150.1.1.1 PE2 loopback 150.1.2.2 PE1 has vlan 2,3,4 PE2 has vlan 3,4 so DF election at present V mod N so PE1 will be DF in PE1 calculation. in PE2 DF calculation V mod N. PE2 will be DF. So in short both PE will be DF for a EVI. Regards, Sudhin Jacob On Wed, 25 Nov 2015 03:42:00 +0530 "Satya Mohanty (satyamoh)" wrote > Hi Kishore/Sudhin, From: Kishore Tiruveedhula Date: Tuesday, November 24, 2015 12:42 PM To: smohanty mohanty , "Patrice Brissette (pbrisset)" , sudeep g ggg , "bess@ietf.org" Subject: Re: [bess] REG: draft-mohanty-bess-evpn-df-election-02 Please see below inline…[Kishore]. 1. When a new PE comes in the MH segment. [Satya] Yes, New PE needs to wait for 3 sec. According to RFC 7438, the receiving PEs also need to wait for 3 secs. But, ideally, a PE that is going from DF to non-DF or non-DF to non-DF should become the non-DF rightaway. Only the PE that is going DF really needs to wait for 3 secs. This is not explicitly spelled out in the draft but we are thinking along these lines. [Kishore] Yes. The new PE need to wait for 3 seconds, but if new PE receives the type 4 route from the redundant PE before 3 seconds, the new PE can just move to DF immediately (if it becomes DF) just after receiving the type 4 without waiting for the 3 seconds timer expiry because the otherredundant PE might have moved to Non-DF as there is no 3 seconds timer on the other PE which is moving from DF to Non-DF. It is good idea to explicitly spell out this in this draft. [Satya] Right. We will spell this out in the next version. [Satya]Now, delay of BGP updates is not dependent on the above behavior. That depends on the network topology and queueing/processing at intermediate nodes. With HRW, a PE coming up will result in minimal disruption of the established DF for various vlans (bundles) as opposed to RFC 7438 mod-based. [Kishore] If the BGP update processing takes more time on one PE and receives less time from RR on the other PE, then it may be possible of both PE may become DF or Non-DF, so the timer value should be chosen large enough in this case. [Satya] The problem is there is no "cure-all" timer value that will guarantee this behavior. There was a ack based draft sometime back, but it would have introduced considerable overhead that caused complications. Thanks, Kishore Thanks, --Satya _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess Get your own FREE website, FREE domain & FREE mobile app with Company email. Know More > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
