In message <5512B961-3280-4EBD-8A0B-275AD43358DE(_at_)cisco(_dot_)com>
Fred Baker writes:
On Nov 16, 2006, at 4:02 PM, Curtis Villamizar wrote:
Preemption in MPLS can be soft preemption (setting aside
differences of opinion about how signaling of soft preempt should
be done for the moment)...
Even for hard preemption, there is at worst a fall back to IP and
reroute...
Those are both options, but IMHO have issues. One can't, for example,
fall back and reroute to a different path if the bottleneck where
preemption is occurring is the only path to the destination. [...]
One vendor, lets call them vendor A, has solved this using a feature
they call metric-bias which is a better alternative to soft
preemption. MPLS CSPF is influenced so that an effort is made to
avoid highly utilized links. If there is no other way, thats where it
goes. If there is other traffic (BE) thats what gets clobberred.
But we're way off topic so I won't go into details.
[big snip]
Yes, I'm being extreme, but this topic is about the end cases. And
yes, adding more bandwidth is always helpful. It isn't always an
option, and under the scenarios in question (in some cases, just say
"Armageddon") might be pretty difficult to predict in detail.
Plain IP solutions based on queueing alone work fine if allowing the ETS
traffic to take the shortest IGP path never congests the ETS traffic
and never gets too painful for the BE traffic.
Generally MPLS shines relative to plain IP where there is a network
fault, or many network faults, and capacity remains but may be quite
limited in part of the topology. That would be expected to be the
case in certain situation where an ETS is most needed.
For example, multiple faults occurred and capacity was very
substantially reduced during and for quite a while after Katrina.
Some automatic means of best using whatever capacity is available at
any give time (such as MPLS does) would be a good thing IMHO.
Do you disagree?
Curtis
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf