The change I submitted continues the original use of NHT information for Idle (start event) and Active (retry) states, i.e., just removes NHT info in Connect state.
Keeping these event sources seems fine (at least based on testing) and not clear to me very significant, but I haven't traced through all the possible generation of NHT events. I have no strong option on keeping the original event mapping code or the intro of an NHT event - I can see arguments for/against both. But I'm not comfortable with the into of the new transitions at this point - certainly I'm skeptical about the change in Connect and OpenXXX states. Lou On 9/30/2016 10:17 AM, Paul Jakma wrote: > On Fri, 30 Sep 2016, Lou Berger wrote: > >> It's unclear to me why an NHT should *ever* trigger a state machine >> change. At this point, I'm more comfortable with going back to not >> changing BGP FSM state than introducing the three new FSM changes you >> have in the code... > The 3 FSM changes are basically the exact same as the NHT code was > doing, except without calling connect_check on Connect. > > I.e. the major functional difference to yours is that it retains going > through the ConnectRetry_timer_expired event on Connect as the prior NHT > code was doing. > > The other differences are cosmetic, to just do it via the existing FSM, > so it's obvious. If one FSM is hard to understand, two different > interacting FSMs is harder still. > >> Why do you think the state transitions are are appropriate based on an >> NHT_Update? What are the real sources of NHT_Updates? If BGP itself, >> as the prior case, these should certainly be ignored. > The source is a message from zebra. > > If connections that are OpenSent+ can ignore NHT events, then those > events can also be ignored for Connect and Active. Trying to optimise > for bringing up links and short-circuit the connect-retry timer in case > of some link event pertinent to the peer address, I assume. > > Remove that and simplify it all, or keep? > > regards, _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
