Re: OSPF Costs Formula that include delay.

[Mark Tinka <mark.tinka () seacom mu>]

On Saturday, January 25, 2014 08:10:54 AM Graham Beneke 
wrote:

> 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 
settles.

Mark.

Attachment: signature.asc
Description: This is a digitally signed message part.