The MPLS-OPS Archive

["Poh Tze Ven" <tvpoh@essex.ac.uk>]

An interesting paper.

 

>You have to look at two cases (at least):
>1. Steady state: If you keep your trunks and routers lightly loaded (as Sprintlink does), then IGP metrics should work fine in

> the steady state.  The key is that you don't go beyond about 30% loading in the steady state.  Both queuing theory and

>experience show that it is impossible to completely avoid congestion (and packet loss) in the steady state if you go much past

>that due to IP routing's hyperaggregation, even with carefully designed metrics. Sprintlink has chosen to lightly load their

>network.

>MPLS TE works very well if you want to make more efficient use of network resources.

 

Fortz & Thourup claimed a much higher loading than that. It is probably the same for MPLS (~50%-60%).

>2. Outages: You have to ask, both with IGP metrics and with MPLS TE, what happens when outages occur. It is pretty

>straightforward to do MPLS TE network designs that include restoration paths without having to reserve a lot of headroom for

>outage restoration (of course, you do have to reserve SOME headroom - nothing comes for free).  The situation is much

>worse for IGPs, because it is just about impossible to predict in advance what will happen if a particular switch or link fails -

>how long it will take the IGP to reconverge, and how it will reconverge (where will the traffic go?).  And the network will

>continue to use incorrect metrics until either the outage is repaired, or the metrics are updated to reflect the outage topology.

 

Designing restoration paths is complicated and time consuming. Furthermore, it is impossible to predict which switch or link will fail. For Tuned-IGP system, incorrect metrics do no harm traffic flow to the extend that none gets delivered. At worse, some link may get congested and may cause probably small portion of the whole packets in the network being dropped. The packet dropping can be futher reduced since the system coincidently adopts load balancing (if there are several paths available). The local switch can re-loadbalance without any path setup time while waiting for the link metrics to be corrected.

 

Of course this may not likely provide 100% protection. One may point out 101 deficiencies on this type of TE, however it is simpler and probably sufficient for diff-serv. And that is what Sprint opts to follow -- "simplicity" philosophy.

 

-Tze Ven