OER Variance to solve Policy Conflicts

When you configure a policy for OER you can choose what metrics are most important to you (packet loss, delay, jitter, etc.). For example, you can configure a policy that will choose an exit path based on the following criteria:

1. Lowest Delay
2. Lowest Jitter
3. Lowest Packet Loss

Now imagine we have two exit paths with the following metrics:

1. Exit A:
   1. Delay is 80ms
   2. Jitter is 5ms
   3. Packet loss is 2000ppm
2. Exit B
   1. Delay is 90ms
   2. Jitter is 3ms
   3. Packet loss is 1500ppm

If we select exit A based on the lowest delay only, then we don’t make the best choice since the jitter and packet loss of exit A is worse than exit B. By using the variance, we can ensure that other exit paths fall within the “acceptable” criteria for a certain metric. This allows us to choose an exit path based on more than one metric.

Now let’s say I configure a variance of 15% for the delay. Exit path A has a delay of 80 ms. All exit paths that fall within 80 ms + 15% will be considered equal regarding the delay. 80ms + 15% = 92 ms. The delay for exit B (90 ms) is lower than 92 ms, so exit A and B are seen as “equal” when it comes to delay. This means we will have to look at the second metric (jitter).

Does this make sense? Let’s take a look at an actual policy with three exit paths:

• Exit A:
  • Delay 100 ms
  • Jitter 5ms
  • Packet loss 2000ppm
• Exit B:
  • Delay 150 ms
  • Jitter 6ms
  • Packet loss 1900ppm
• Exit C:
  • Delay 110 m
  • Jitter 3ms
  • Packet loss 1900ppm

MC#show run | sec oer-map
oer-map VARIANCE 10
 match traffic-class prefix-list MYPREFIXES
 set resolve delay priority 1 variance 20
 set resolve loss priority 2 variance 10
 set resolve jitter priority 3 variance 15

Let me describe the policy above: