[168438] in North American Network Operators' Group
Re: OSPF Costs Formula that include delay.
daemon@ATHENA.MIT.EDU (Mark Tinka)
Sat Jan 25 12:47:47 2014
From: Mark Tinka <mark.tinka@seacom.mu>
To: nanog@nanog.org
Date: Sat, 25 Jan 2014 19:47:18 +0200
In-Reply-To: <52E3556E.4060705@apolix.co.za>
Reply-To: mark.tinka@seacom.mu
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--nextPart2254847.X6iIEuqh0n
Content-Type: Text/Plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
On Saturday, January 25, 2014 08:10:54 AM Graham Beneke=20
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=20
relying on automatic application of the same by the IGP.
=46olk that use IS-IS have had to do this since the beginning.=20
But given OSPF implementations support the manual setting of=20
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=20
calculate cost based on that. Admittedly, in 2014, bandwidth=20
is probably less of a useful metric than latency, given=20
10Gbps links are "relatively" easy to get if you take the=20
global capacity average into account, as well as the=20
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.
>=20
> * 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=20
scalably in the IGP. The idea is to find a model that is as=20
generic as possible, and doesn't take too many environmental=20
considerations into account, but allows for them at a mid=20
level. It is also equally important to use a model which=20
will survive staffing churn and ease training/understanding,=20
particularly in multi-vendor networks.
Of course, in the worst of cases, MPLS-TE will be deployed=20
to smoothen all of this out; and in fairness, barring any=20
major developments in IS-IS and OSPF, may be the most=20
scalable solution until SR (Segment Routing) takes hold.
I hope to report back, say in a year from now, once the dust=20
settles.
Mark.
--nextPart2254847.X6iIEuqh0n
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
iQIcBAABAgAGBQJS4/ipAAoJEGcZuYTeKm+GN0AQAIvFlTvC1PaFbp0Q7wNclIjy
7FYwwh+kCupGTOl4wH+dRTERL4dr1w5LobU2IgdLKNMJ07Kf8yCJCPOgLLcQXUic
gCqfKJDjVLxZx8opNYQPk34p9t8kKDQ57xoM1Y6Pa8SOLaE6EWLSaxUx7HX9Omp9
Do2NDIPJxBy7UWconvwsXXi0P48Upe3wcdA5VlAZ3ZDel2lSpa7EZh8Jg2C49sck
UJhJit0ON+E8gixeXpGiZOSX0BX4B88oXecQLDnDgwk6OiCj/BKiedWwgPG51+dT
4EP9+PBz2A4jU7ExBJTVGje/LKqM7EjN7p4LrVMDfeNTZ/Q+A7kLZMZG1zWrd25O
93I6BMuYWFFiAiePWh1My1WxbGBm+MmMF1nBJJbSS3ysmxrn30qGcMlV8MsoD2SE
q7t9ZavrJOhtPXHhCcVgy+p14saJajqhlZT2SdJ49XsHpKVjQOFmzM+Y1MAyR4FA
39Uul1jQIU6qSpGQxcV/td704atD26RZr9xpCA8CCpRfNMoq9ZHd+ca45mXEcMAb
7XGQHzyIvT4Cxg72eRG1EuNJBBaJ1f84i7YUijAxDvm9H9/nEqgEiUaD510dtCRP
SFQjcguqQYo6uYOrSP/LSRU58mvveVZcFlMuxfCUT31GJm7DxKRjkpIQ110YLhHi
KjD0eTa934PsLh1gf8YS
=f2lt
-----END PGP SIGNATURE-----
--nextPart2254847.X6iIEuqh0n--
