Hi Kishore/Sudhin, From: Kishore Tiruveedhula <[email protected]<mailto:[email protected]>> Date: Tuesday, November 24, 2015 12:42 PM To: smohanty mohanty <[email protected]<mailto:[email protected]>>, "Patrice Brissette (pbrisset)" <[email protected]<mailto:[email protected]>>, sudeep g ggg <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 other redundant 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
