OSPF Costs Formula that include delay.
mark.tinka at seacom.mu
Sat Jan 25 17:47:18 UTC 2014
On Saturday, January 25, 2014 08:10:54 AM Graham Beneke
> The auto-cost capability in some vendors devices seems to
> have left many people ignoring the link metrics within
> their IGP. From what I recall in the standards -
> bandwidth is one possible link metric but certainly not
> the only one. Network designers are free (and I would
> encourage to) pick whatever metric is relevant to them.
I think hard-coding cost on every link is better than
relying on automatic application of the same by the IGP.
Folk that use IS-IS have had to do this since the beginning.
But given OSPF implementations support the manual setting of
cost as well, you get the same benefits.
> * The traditional auto-cost calculation based on a
> 100Gbps reference which gives far more useful values
> than the old 100Mbps reference.
We use a reference bandwidth of 1Tbps, and manually
calculate cost based on that. Admittedly, in 2014, bandwidth
is probably less of a useful metric than latency, given
10Gbps links are "relatively" easy to get if you take the
global capacity average into account, as well as the
proliferation of CDN edge extensions and the data-centre-of-
things rampage going on at the moment.
> * An average or nominal link latency multiplied by a
> factor of 200. Sometimes adjusted if I want two
> geographically diverse paths between the same endpoints
> to have equivalent costs.
> * Path length in km multiplied by 2. This accounts for
> situations when the nominal latency is too small to
> accurately determine and assumes 1 ms per 100 km.
We are toying with a couple of models for doing this
scalably in the IGP. The idea is to find a model that is as
generic as possible, and doesn't take too many environmental
considerations into account, but allows for them at a mid
level. It is also equally important to use a model which
will survive staffing churn and ease training/understanding,
particularly in multi-vendor networks.
Of course, in the worst of cases, MPLS-TE will be deployed
to smoothen all of this out; and in fairness, barring any
major developments in IS-IS and OSPF, may be the most
scalable solution until SR (Segment Routing) takes hold.
I hope to report back, say in a year from now, once the dust
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the NANOG