I understand OSPF default calculation for cost doesn't include delay. I am looking for a formula that I can use to manually set the OSPF costs that factors in delay. When using OSPF's default costs, the shortest path is not always the optimal path. Example New York to Los Angeles. Assuming all links are the same bandwidth and have a ospf cost of 1. Path 1 (75ms) - OSPF Cost 2 - New York > Dallas > Los Angeles Path 2 (65ms) - OSPF Cost 3 - New York > Chicago > Denver > Los Angeles If I left the default cost's alone then path 1 would win because it has a lower ospf cost, however it take traffic 10ms longer to get there. However I would like traffic to take Path 2 by adjusting the OSPF cost. I am looking for a formula that other people are using .p Thanks Erik -----Original Message----- From: Randy [mailto:randy_94108@yahoo.com] Sent: Thursday, January 23, 2014 9:03 PM To: Erik Sundberg; nanog@nanog.org Subject: Re: OSPF Costs Formula that include delay. ----- Original Message -----

From: Erik Sundberg <ESundberg@nitelusa.com> To: "nanog@nanog.org" <nanog@nanog.org> Cc: Sent: Thursday, January 23, 2014 4:47 PM Subject: OSPF Costs Formula that include delay.

What is everyone using for an OSPF cost formula that factors in a circuits delay and bandwidth (10M-100G)???

Thanks in advance

umm..are you sure your question is not about EIGRP? OSPF has no concept of interface-delays. The default reference bandwidth for OSPF is 100M In your case if you set your reference bandwidth to 100000 your 100G links would have a link cost of 1, 10G - 10, 1G-100, 100M-1000 and 10M-10000 A vendor specific list would be a better place to ask. ./Randy ________________________________ CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

Some networks I have worked with took the average latency of each link and assigned that (with some constant multiple) as the interface cost.

Of course this all fails miserably if you are using anything like MPLS underneath your OSPF.

But then when using MPLS underneath, then MPLS Traffic Engineering can be used to do some interesting path computations and resiliency configurations. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

On Friday, January 24, 2014 10:59:19 PM Owen DeLong wrote:

I wasn’t attempting to promote or discourage use of MPLS. I was merely endeavoring to point out that in an MPLS world, OSPF costs are not how you want to manage your traffic.

Again, only an issue when using RSVP-TE. I'd recommend MPLS-TE (especially core-to-core, as that is more scalable) when looking at making more aggregate routing decisions when dealing with a bandwidth vs. latency conundrum. Adjusting IGP costs in favour of latency works well, but can have pile-on effects behind or in front of the links being worked on, which can be confusing to troubleshoot when taking other PoP-specific factors into account. It also obliterates any sane cost-assignment mechanism you might have developed (or at best, makes it overly complex). There is room for both options, typically depending on network size, number of links, rate of topology change in your network and skill level of your network engineering team. Mark.

+1 On Jan 24, 2014 12:41 PM, "Owen DeLong" <owen@delong.com> wrote:

Some networks I have worked with took the average latency of each link and assigned that (with some constant multiple) as the interface cost.

Of course this all fails miserably if you are using anything like MPLS underneath your OSPF.

Owen

On Jan 24, 2014, at 12:26 PM, Erik Sundberg <ESundberg@nitelusa.com> wrote:

...

I understand OSPF default calculation for cost doesn't include delay. I am looking for a formula that I can use to manually set the OSPF costs that factors in delay.

When using OSPF's default costs, the shortest path is not always the optimal path.

Example

New York to Los Angeles. Assuming all links are the same bandwidth and have a ospf cost of 1.

Path 1 (75ms) - OSPF Cost 2 - New York > Dallas > Los Angeles

Path 2 (65ms) - OSPF Cost 3 - New York > Chicago > Denver > Los Angeles

If I left the default cost's alone then path 1 would win because it has a lower ospf cost, however it take traffic 10ms longer to get there.

However I would like traffic to take Path 2 by adjusting the OSPF cost.

I am looking for a formula that other people are using .p

Thanks

Erik

-----Original Message----- From: Randy [mailto:randy_94108@yahoo.com] Sent: Thursday, January 23, 2014 9:03 PM To: Erik Sundberg; nanog@nanog.org Subject: Re: OSPF Costs Formula that include delay.

----- Original Message -----

...

From: Erik Sundberg <ESundberg@nitelusa.com> To: "nanog@nanog.org" <nanog@nanog.org> Cc: Sent: Thursday, January 23, 2014 4:47 PM Subject: OSPF Costs Formula that include delay.

What is everyone using for an OSPF cost formula that factors in a circuits delay and bandwidth (10M-100G)???

Thanks in advance

umm..are you sure your question is not about EIGRP? OSPF has no concept of interface-delays.

The default reference bandwidth for OSPF is 100M

In your case if you set your reference bandwidth to 100000 your 100G links would have a link cost of 1, 10G - 10, 1G-100, 100M-1000 and 10M-10000

A vendor specific list would be a better place to ask.

./Randy

________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error please notify the sender immediately by replying to this e-mail. You must destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

On Fri, Jan 24, 2014 at 2:58 PM, Jeff Tantsura <jeff.tantsura@ericsson.com>wrote:

Eric, Issues: 1.OSPF (SPF) can only produce a SPT based on cost (metric). Anything else would require CSPF rather than SPF.

A CSPF based protocol would be a suitable algorithm for adding hard constraints, instead of preference, such as path delay must be less than X, instead of just a weight for each edge of the graph. However, if you like: you can use a manually set cost for every link ------- manually figure a weight based on bandwidth or delay at ideal utilization (but not both delay and bandwidth simultaneously). For example, if you equate cost to delay, then you might decide that the greatest delay any path through your AS/routing domain should ever see, from any pair of routers end-to-end is 120 milliseconds. Then you can scribble that down, and figure out what fraction of 120ms the delay for every IGP link is, under ideal conditions, to set your weight to the corresponding fraction of your chosen maximum weight. Then decide on a reference scale, for example: 100% = cost of 16384 Within that model, a link with 120 milliseconds delay, traversing that link costs 16384. Traversing a link with 10 milliseconds delay should have cost 1366, etc. Over multiple hops, the costs will then sum together, to give delay under idealized conditions.

2. Delay is not distributed as part of an IGP update

Typical constrains distributed are: bandwidth, color, some others

[snip]

RSVP-TE (computation result is an ERO) however theoretically nothing precludes one (implementation) to use those for more comprehensive computation, i.e. delay could be taken into consideration as long as the path is loop free. So it would look like - compute all loop free paths to a destination and then choose one with the smallest cumulative delay.

What I would like to see is dynamic computation of Delay and Utilization. Instead of merely "choose the one with the smallest cumulative delay" ----- choose the one with the smallest cumulative delay, BUT, offer load balancing over the N lowest delay links in proportion to the available utilization. For instance... if one of the paths has a link somewhere in it is that 90% congested, load balance unequally, and send a majority of packets over the path with the maximum 25% utilization, that has less than 10% in additional delay. BTW - segment routing will give you this functionality day one :)

Cheers, Jeff

-- -JH

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.