Subject: RE: [Isis-wg] IS-IS metrics: in search for a sound way

From: "Metz, Eduard" <[email-masked]>
Date: Wed, 13 Mar 2002 10:11:02 +0100

AFAIK, the default metric is more or less 'dimensionless' in current
implementations, and therefor not derived from interface bandwidth directly.
So you can put any value in there (based on any formula you wish).
 
In general something like: long, narrow pipes => large metric, and short,
fat pipes => small metric tends to work. Use the math of your choice to get
from one end to the other.
 
cheers,
    Eduard

-----Original Message-----
From: Nikos Leontsinis [mailto:[email-masked]]
Sent: Monday, 11 March, 2002 23:10
To: [email-masked]
Subject: [Isis-wg] IS-IS metrics: in search for a sound way

ISO 10589 states in 7.2.2. that the following 4 isis metrics are defined:

1.Default: Each link is given a metric value based on its throughput 
2.Delay metric . It measures the transit delay of the circuit. (pretty
common-sensical higher value longer delay)
3. Expense metric. It measures the monetary cost of the network's
utilsation-higher value larger expense-.(very unclear to me how this is
done) 

4 Error metric.It measures the residual (êáôÜëïéðï, õðüëïéðï) error
probability of the asociated circuit (also unclear but makes sense as a
concept). 

If you look at the IS-IS  LSP format's analysis i.e. p.638 Doyle, Routing
TCP/IP Volume1 you will see that IOS supports
 only the default metric (bit 4) Bits 5-7  which are delay, expense & error
are not supported and they will always be zero.
This is a major IOS caveat as bandwidth alone is by no means sufficient to
account for metric assignment.
However, looking at the LSP format is not the only way to reach the above
conclusion.
These 3 factors would be brought into consideration on a discussion on how
to tune isis metrics by someone
who was building his/her argumentation on pure operational experience. 
The main objective behind metric tuning is network performance improvement.
Performance is an umbrella
which incorporates the configuration and measurement of distinct areas. It
is not clear to me how the ietf engineers
calculate delay, expense and error as part of their (non Cisco supported)
isis impl! ementation. What it is indubitable is that
availability, response time, accuracy and utilisation will be key indicators
for the performance of a network and these are the
ones that should also be added as key decision parameters in the metric
assignment process.

        In conclusion, I am looking for a good way to measeure metrics
either based on bandwidth or geographical distance eventhough I don't think
there is one formula which can be used as a panacea. My feeling is that this
is a context based approach. One can come to an agreement on what issues to
consider but the
decision should be taken on the individual links rather than make it matter
of correct application of a specific formula.
For a more detailed analysis on these 4 areas of performance: availability,
response time, accuracy and utilisation see
Performance
<http://www.amazon.co.uk/exec/obidos/ASIN/1578701805/026-9746975-6180426>
and Fault Management  Della Magiora, et al p.74-85. 

Best,

Nikos Leontsinis

  _____  

Join the world's largest e-mail service with MSN Hotmail. Click
<http://g.msn.com/1HM100901/s> Here
_______________________________________________ Isis-wg mailing list -
[email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Fri, 15 Mar 2002 11:20:52 -0500

Nikos,

Eduard is correct, all metrics are dimensionless values and can be
set to represent whatever you think works best for your network.
bandwidth is simply the simplest choice that works very well under
most circumstances, and assuming that hop-by-hop router-induced delays
(other than for queuing) are insignificant.

In addition, multiple metrics allows defining of different classes
(up to 4) of traffic to be routed using different criteria.  The category
of traffic must be selected at the source by setting TOS bits (or for
CLNS, QoS bits).  Unless the source systems set these bits, all traffic
is routed using the Default metric.  For this reason, many networks use
other means of classifying packets and handling QoS and differential
services, and this is one of the driving factors behind MPLS and TE,
if I my very limited understanding of those topics serves me correctly.
Hopefully those who know these subjects well will correct me if I'm
wrong!

Furthermore, there is a pitfall to using multiple metrics.  Unless
all routers in the domain support and are properly configured to use
the other metrics, you can get very nonintuitive results, as pointed
out in Radia Perlman's "Interconnections".  For example, let's assume
that you (as the originating system) choose to take a path that
optimizes "expense" and set the TOS bits accordingly.  Also, assume
that some routers support the expense metric and others don't.
If there any paths between source and destination (within a subdomain,
i.e. area or L2 bbone) the shortest of these paths are taken.  Even
if there is a single 1-cost hop between source and destination, where
the router doesn't support the expense metric.

All this means is that

  1) multiple metrics doesn't give you better routing for default traffic
  2) multiple metrics can give better routing for different TOS classes,
       if end systems set the bits
  3) but ONLY if the non-default metrics are very carefully managed
       in the network.

In my experience, the best use of multiple metrics has been in networks
where all the traffic is generated by a limited number of applications
that understand the domain's rules for metrics, i.e., a network
that exists for a specific purpose.  The example I have in mind was an
electrical power management network.  In this case, three metrics were
used: default (capacity), delay, and "expense" was set to 1 for every
link, so that certain traffic would always use the fewest hops regardless
of other circuit properties.  Default was used for bulk data transfer,
Delay was used for interactive applications, and expense was used for
various technical purposes including measurement of link behavior.

While I'm on my soapbox, I'll include a warning about use of real-time
data to set the delay metric.  While this can be done successfully in
certain cases, it's very difficult and requires a deep understanding
of the network and application data traffic.  The problem is that if
you measure delays and set the delay metric in real time, you typically
get into an unstable situation where, as soon as you lower the delay
on a link, it starts attracting more traffic and the delays go up,
so you must then raise it's metric, etc.  IS-IS was designed with
relatively static metric values in mind, to avoid this kind of problem.

This doesn't answer your original question, which is "what's the best
way to calculate the metric?"  This is a very interesting topic that
I believe has been studied extensively in various contexts.  However,
it's beyond the scope of this forum, which pertains to standards issues.
The means of setting a metric value is not a matter for a standards
committee because it's done entirely within an autonomous system
(domain), and can be done any way the administrator thinks will
provide the best results in his or her network.  No standards are
required.  If you do find any good texts on the subject, we'd certainly
be interested to hear of them, but a detailed discussion of the
subject is probably not appropriate here.

Regards,
Jeff

At 04:11 AM 3/13/2002, Metz, Eduard wrote:
>AFAIK, the default metric is more or less 'dimensionless' in current implementations, and therefor not derived from interface bandwidth directly. So you can put any value in there (based on any formula you wish).
> 
>In general something like: long, narrow pipes => large metric, and short, fat pipes => small metric tends to work. Use the math of your choice to get from one end to the other.
> 
>cheers,
>    Eduard  
>2.Delay metric . It measures the transit delay of the circuit. (pretty common-sensical higher value longer delay) 
>3. Expense metric. It measures the monetary cost of the network's utilsation-higher value larger expense-.(very unclear to me how this is done) 
>
>4 Error metric.It measures the residual (êáôÜëïéðï, õðüëïéðï) error probability of the asociated circuit (also unclear but makes sense as a concept). 
>
>If you look at the IS-IS  LSP format's analysis i.e. p.638 Doyle, Routing TCP/IP Volume1 you will see that IOS supports 
> only the default metric (bit 4) Bits 5-7  which are delay, expense & error are not supported and they will always be zero. 
>This is a major IOS caveat as bandwidth alone is by no means sufficient to account for metric assignment. 
>However, looking at the LSP format is not the only way to reach the above conclusion. 
>These 3 factors would be brought into consideration on a discussion on how to tune isis metrics by someone 
>The main objective behind metric tuning is network performance improvement. Performance is an umbrella 
>which incorporates the configuration and measurement of distinct areas. It is not clear to me how the ietf engineers 
>calculate delay, expense and error as part of their (non Cisco supported) isis impl! ementation. What it is indubitable is that 
>availability, response time, accuracy and utilisation will be key indicators for the performance of a network and these are the 
>ones that should also be added as key decision parameters in the metric assignment process.
>
>        In conclusion, I am looking for a good way to measeure metrics either based on bandwidth or geographical distance eventhough I don't think there is one formula which can be used as a panacea. My feeling is that this is a context based approach. One can come to an agreement on what issues to consider but the 
>decision should be taken on the individual links rather than make it matter of correct application of a specific formula. 
>For a more detailed analysis on these 4 areas of performance: availability, response time, accuracy and utilisation see 
><http://www.amazon.co.uk/exec/obidos/ASIN/1578701805/026-9746975-6180426>Performance and Fault Management  Della Magiora, et al p.74-85. 
>
>Best, 
>Nikos Leontsinis
> 
>
>
> 
>
>
> 
>----------
>Join the world's largest e-mail service with MSN Hotmail. <http://g.msn.com/1HM100901/s>Click Here 
>_______________________________________________ Isis-wg mailing list - [email-masked] http://spider.juniper.net/mailman/listinfo/isis-wg