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

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    >> I think, manual "Optimization" of weights (even small number if
    >> weights) based on the huge topology is a real disadvantage.
 
    > this doesn't have to be done manually -- it could be automated. The
    > basic idea is to know the current topology and offered load in your
    > network by measurement and to have a tool that can select weights that
    > satisfy some objective function (and, perhaps, try to minimize the
    > number of weights that need to change from the existing configuration).
    > Then, you need a way to effect weight changes in the network
 
Ahem. I feel a major, major rant coming on.

The image that comes to mind, hearing of these schemes to try and do traffic
engineering with this approach of carefully selected single metrics, is that
of a person trying to proceed down the street by standing on an upright car
tire and making it rotate with their feet, like some sort of demented
relative of a log-rolling contest.

You can see someone with great balance getting away with it - but it's
fundamentally not a workable idea. To paraphrase Dorothy Parker, "This is not
an idea to be tossed aside lightly. It should be thrown aside with great
force."


Trying to accomplish any optimization of traffic arrangement, or any equally
sophisticated goal for a path-selection system, by means of carefully tweaked
metrics on network elements, used with an existing dynamic single-metric
path-selection system, is just deeply confused. Let's step back for a second,
and think about what's really happening here,

The *whole idea* behind using a *dynamic* autonomous path-selection system is
*to respond in real-time to unplanned changes in network topology*. (After
all, if one doesn't need dynamic response, one could just install static
routes - which can equally well be computed offline, and installed
automatically, as posited above - and be done with it.)

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.

I suppose one might respond that "well, we don't mind living with non-optimal
(by our lights) path selection during temporary outages, it's the base state
we care about". However, I would have thought that it was precisely during
temporary outages - when the network has *fewer* resources available to it to
carry traffic - that one needs *better* path-selection than on average.

If the network was that over-provisioned that it was OK anyway during an
outage, then why on earth did it need some sort of non-trivial path-selection
in the base situation? Similarly, if the system is getting acceptable
path-selction during periods of outages, when it's using metrics which aren't
tuned for that case, are the paths that are selected during normal operation
by untuned metrics really going to be that bad?


The whole notion that one can select single metrics for network elements,
ones that can truly meet complex path-selection goals over a wide range of
subset topologies, is misguided. There's just not enough information
available, nor a complex enough algorithm to process it. The answer is
simple: stop trying to drive a screw with a hammer.

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.


    >> (In my opinion these implementations [MPLS with precomputed backup
    >> paths] are going to be mature in foreseeable future).
 
    > The key issues are when will this capability be available, how
    > complicated is it to manage, and how much better/faster is it than the
    > alternatives?

I remain highly dubious that anything of real value will be gained by this
technique optimized metrics - or, in more blunt terms, whether the slight
potential improvements are large enough to be worth the energy being expended
on this technique.

	Noel