On Thu, 3 Dec 2015, Paul Jakma wrote:
There are some simple mathematical rules that can be followed in designing a
path-vector routing protocol and its metrics which will _ensure_ the protocol
converges, always, on any network. What I'd love is if we could embrace those
rules and start figuring if and how we can bend BGP into following those
rules.
1. Make paths map to a weight (lowest weight == most preferred), and do so
without reference to any other path (MED fails on that)
2. Ensure that the weight of a path always increases when propagated
(many BGP metrics fail on this, but saved by IGP cost hopefully
reflecting this, except if iBGP and IGP topologies are at
cross-purposes / not aligned, in which case you can have oscillation on
IGP costs alone; or if you don't run an IGP at all - seems more common
today; the CLUSTER_LIST length check is good though, it always
increases with reflection - lift that earlier into the decision process
and bingo...).
That's it. Do that, or something that can be shown to be equivalent, and you
can be _sure_ your iBGP will converge. No tweaking needed.
Oh, the weight increase should purely be a function of the path. No
looking at other paths. The same path should reliably map to the same
weight.
You could implement this by:
1. making the selection process (some equiv of bgp_info_cmp) come up with
a number, the weight of the route.
2. Adding that number to an accumulative weight attribute sent with the
route through iBGP.
3. The selection process (bgp_best_selection) deciding based simply on
that number
Note that you could do _whatever_ you wanted in #1. It wouldn't even need
to be consistent across hosts anymore. If Cumulus wanted to calculate
their weights one way, Vendor C another, etc. and Quagga wanted to just
sum up the (path-specific) bytes of the route, that'd be fine! They would
still all work together. If one vendor didn't want to take MED into
consideration in calculating weight - fine. If another just wanted to
multiply the AS_PATH hop count by the birthday of their favourite
offspring - not a problem.
They'd all still be compatible and work together, as long as they did so
consistently for paths (least, so long as they had routes advertised), and
they always incremented the accumulator attr with the calculated weight.
1. Calculate a number from the path (consistently) - whatever way you want
2. Add it to a path metric
3. iBGP will Just Work
That's "all" we need to do, says the math.
(If the above is too radical, then maybe there's other ways. E.g.,
re-arranging the order of evaluation of the existing BGP metrics and
minisming/deprecating evaluation of ones that are problematic; e.g.
lifting Cluster-List can also get us provably correct, converging iBGP).
Not everything that comes out of academia is great, not even close, but
the path-vector routing algebra work really is worth taking to heart.
Who would _not_ want *provably* correct BGP? :)
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Money is its own reward.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
