Re: [TE-wg] TE use in today's networks

[Jennifer Rexford <jrex@research.att.com>]

Noel,

> If i) one has some complex goal for how one would like paths for
> traffic to be selected, and ii) one wants the system to be able to
> respond to outages in a dynamic and autonomous fashion, then one has
> to bite the bullet and create a path-selection system which can meet
> those goals. It has to a) make the needed information available, and
> b) incorporate those goals in the algorithm used to select paths.

Sure, nicely put.  You could undoubtedly define a better routing
framework than OSPF/IS-IS for traffic engineering.  Existing IGPs are
not all that flexible (e.g., they do destination-based forwarding,
they do not make flexible use of mutliple shortest paths, and they do
not make any use of non-shortest paths).  I think you could say the
same thing for QoS mechanisms -- that per-flow mechanisms are "better"
than aggregate QoS mechanisms, which is better than no QoS.  The
question isn't whether you can do better than the existing technology;
you surely can.  The question is how much you would gain (in network
efficiency) and how much you lose (in network and management complexity).
And, what should a network operator do in the meantime as the "better"
protocols and mechanisms are developed and tested?

> If one *does* need dynamic response, it should be intuitively
> obvious that even if one can find a set of weights that produces the
> result one wants in the base case, then the resulting traffic pattern,
> once chance has taken some random set of elements out of service, is
> probably not going to be one that comes anywhere near meeting whatever
> goals one has.

While this is theoretically true, experiments suggest that in practice
the weights that are good in the base case often work pretty well in
the failure case; when they don't, a change or two does the trick.
Also, this is a question of time scale.  Changing weights to adapt to
time-of-day traffic changes, longer time-scale traffic shifts, and the
addition of new routers/links, seems reasonable -- and preferable to
the alternative of keeping the weights fixed.  

(You could also imagine that you have enough resources allocated for
the "high priority" traffic to receive the required service even under
the failure scenario, and just do weight changes to improve the
performance seen by the "low priority" traffic.  Or, you could imagine
using explicit routes for the "high-priority" traffic and using the
label-switched paths selected based on the weights in the base IGP for
the remaining traffic.)

> The answer is simple: stop trying to drive a screw with a hammer.

What if you don't have a screwdriver and the hammer works pretty well?

-- Jen