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

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 7 Jun 2001 12:22:54 -0400

Jennifer/Randy:

   First of all my apologies for not clear about my concerns:

   Please look at my inline comments:

-> In the OSPF case, the second issue could involve basic recomputation
-> of paths using the existing weights.  In many cases, the resulting
-> paths are not all that bad.  In some cases, some weights may need to
-> be changed to move to a better set of paths for the prevailing
-> traffic; in practice, it is sufficient to change one or two weights,
-> and these changes can be precomputed.  Yes, this does require a
-> network management system (or person) to effect the changes.  That is
-> a definitely a disadvantage, as you mention.  But, how significant is
-> this disadvantage?

   As a developer of OSPF (without any knowledge of customer real networks)
   I think, manual "Optimization" of weights (even small number if weights)
   based on the huge topology is a real disadvantage. But I supposed, 
   this disadvantage can be eliminated by incorporating "dynamic"
"optimized"
   weight selections based on constraints/policies is possible. This 
   needs sufficient changes to the existing routing protocols, which 
   I didn't find any developments/deployments. Am I correct?

-> The details of the MPLS case really depend on what MPLS features are
-> in use.  
-> 
->   * On one extreme, you could imagine having precomputed backup
->     paths (or even backup subpaths to replace individual 
->     link failures).
->     Something has to trigger the failover to these backup paths.  In 
->     theory, this can all be done without intervention by a network
->     management system.  But, are MPLS implementations and deployments
->     this mature yet?  Are the backup paths precomputed -- by 
->     the routers themselves or by an external management system?  

    As you mentioned this is "dynamic" without intervention by a network
    management system. There are many implementation and progress I 
    can see in IETF. (In my opinion these implementations are going to
    be mature in foreseeable future). 

->   * Another possibility is dynamic recomputation of routes based on
->     dynamic link weights (set based on the prevailing traffic).  This
->     requires the edge router to learn about the failure, 
->     compute a new path, and signal this path.  In fact, a single failure 
->     may cause a bunch of edge routers to compute a bunch of new paths.
->     What kind of signaling load does this introduce?  Are the local 
->     decisions made by each router (as the system moves to the new state) 
->     good for the global traffic load?

     This is another possibility MPLS fast reroute. Your questions are 
     valid in this case:
     
         What kind of "signaling" load does this introduce?
         Are the local decisions made by each router (as the system moves 
         to the new state) good for the global traffic load?

     My questions are:

         What kind of "routing" load does weight changes introduce in OSPF
         and with what added complexity and/or extra benefits?
         Won't the local decision is based on the global topology?
         Consider PNNI/RSVP-TE signaling, even the local decision 
         is made about the PATH. Isn't that based on global topology data
base?!?

-> In either case, the key question is whether or not this complexity is
-> warranted.  I don't doubt at all that the full-fledged deployment of
-> MPLS opens up additional possibilities (in addition to the existing
-> IGP mechanisms) for more efficient failover (both in terms of routing
-> efficiency and convergence delay).  But, how much, and at what added
-> complexity?  

   I agree complexity is one issue but with what extra benefits?

   Let me very clear, I am not against any of the proposals.
   These are the questions just I have in mind, please don't mind!

--Venkata Naidu

---

From: Jennifer Rexford <[email-masked]>
Date: Thu, 7 Jun 2001 12:46:54 -0400 (EDT)

Venkata,

> As a developer of OSPF (without any knowledge of customer real
> networks) I think, manual "Optimization" of weights (even small number
> if weights) based on the huge topology is a real disadvantage. 

Yes, that is true.  But, 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 (a person or script that can telnet to
the router and enter "ip ospf cost 64" to change an interface's OSPF
weight from, say, 60 to 64).

> But I supposed, this disadvantage can be eliminated by incorporating
> "dynamic" "optimized" weight selections based on constraints/policies
> is possible. This needs sufficient changes to the existing routing
> protocols, which I didn't find any developments/deployments. 

Changes to the existing protocols would be necessary only if you want
the routers to compute and transmit the new values of the weights to
each other.  However, the protocols and the routers don't have to
change if you have an external system that computes and changes the
weights.

> (In my opinion these implementations [MPLS with precomputed backup
> paths] are going to be mature in foreseeable future). 

Yes, that may be true.  These offer the (future) hope of faster
recovery from failures, with the introduction of some signalling
overhead and management complexity.  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?  (Another question might
be whether the potential speed improvements are necessary -- and for
which applications.  Arguably, you could imagine a hybrid scheme where
some of these features are used for certain types of traffic that 
really demand it, whereas more conventional techniques may suffice
for the remaining traffic.)

> and with what added complexity and/or extra benefits?  Won't the local
> decision is based on the global topology?  Consider PNNI/RSVP-TE
> signaling, even the local decision is made about the PATH. Isn't that
> based on global topology data base?!?

Good questions.  The outside-the-network selection of weights (without
changes in the routers and protocols) does introduce work -- outside
of the network (to collect data and select weights), at the network
management level (to effect weight changes at the routers), and inside
the network (to propagate new weights and compute new routes).  This
needs to be compared with the costs and benefits of the other proposals
(particularly against approaches that are already deployable today).

The PNNI-like schemes have an advantage and a disadvantage over this
external approach.  On the positive side, under the PNNI-like scheme,
the network adapts on its own without intervention; this may reduce
the delay for adaptation and reduce network management overhead (once
the initial deployment and configuration issues have been addressed).
On the negative side, the PNNI-like scheme introduces more complexity
in the network, protocol overhead to exchange dynamic weights as the
load in the network changes, and allows individual nodes to make local
decisions that may not be globally optimal (especially in the presence
of out-of-date information about link load).  Some of the negatives of
each scheme can be dealt with (see work in the QoS routing space, for
example).

> Let me very clear, I am not against any of the proposals.  These are
> the questions just I have in mind, please don't mind!

Yup, me too.  I'm interested in understanding the trade-offs and also
(on a more practical level) in knowing if/when the potential gains in
flexibility and efficiency from MPLS/PNNI-like schemes make them more
attractive than the existing alternatives.

-- Jen

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Jun 2001 14:49:19 -0400

>    if weights) based on the huge topology is a real disadvantage. But I
>    supposed, this disadvantage can be eliminated by incorporating
>    protocols, which I didn't find any developments/deployments. Am I
>    correct?

i would just push the new weight out to meet circumstances.  i would trust
automating doing so about a a bit more that i would trust distributing a
few thousand labels.

>     be mature in foreseeable future).

luckily, i have ospf and is-is today.  and they're pretty well shaken
out, seem to work inter-vendor, ...  being a old and stupid operator,
i like simple solutions using well-known components.

randy