On Wed, 11 Nov 2015, Daniel Walton wrote:
but quagga is doing this check earlier then I could see you getting into a situation similar to the one you describe below. So then you would need a bestpath knob that controls where in the decision algorithm this comparison happens. There are already so many knobs in bgp...this might be more trouble than it is worth (and confusing for the end user).
Agreed on BGP already having way too many knobs to twiddle. :)
How about a followup patch that provides a knob to disable this comparison in bestpath?
Hmm, that still allows for operators to mismatch it and have subtle probs? It took a long time for BGP engineers and academics to understand oscillation and figure out how to provably prevent it. Most operators probably would struggle to even recognise it if it happens, never mind debug.
I wonder could we add a capability to describe the routing decision steps and their ordering, e.g. as a list of code-points (each code-point being some recognised decision process), and refuse to connect when there is divergence in the min(length(their list),length(our list)) initial set of that list. (i.e. it doesn't matter if one speaker implements additional tie-breakers, as long as both are agreed on the sequence before that).
That would let changes to the decision ordering be made and rolled out in a planned fashion, without risk of undetected weird problems, at least.
regards, -- Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A Fortune: The only real advantage to punk music is that nobody can whistle it. _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
