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,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
There is no delight the equal of dread. As long as it is somebody else's.
--Clive Barker
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
