The MPLS WG Archive

[MPLS <mpls@apollo.mctr.umbc.edu>]

As far as my understanding of path computation goes, in online path
computation scenario, which Dan mentioned is more likely to be the case,
what ensures that the ingress node(s) have a consistent view of the
network, how do we make sure that IGPs have converged and each node has
correct topology as well as TE database ? 

An offline tool i think "might" give a more realistic picture of the
network resource allocation state at any time, correct me if i am wrong. 

Manish




On Mon, 24 Apr 2000, Chiu, Angela L, ALSVC wrote:

> Hansen,
> 
> See comments in line.
> 
> Angela
> 
> AT&T Labs
> Room C4-3A22
> 200 Laurel Ave.
> Middletown, NJ 07748
> Tel. (732) 420-2290
> Fax (732) 368-1746
> Email: alchiu@att.com
> 
> > -----Original Message-----
> > From:	HANSEN CHAN [SMTP:hchan@newbridge.com]
> > Sent:	Monday, April 24, 2000 6:17 PM
> > To:	Chiu, Angela L, ALSVC
> > Cc:	Daniel Awduche; mpls@UU.NET
> > Subject:	Re: TE Extension of IGP
> > 
> > Angela,
> > 
> > > I just want to add one other point. When a network operator wants to use
> > a
> > > small set of LSPs to remove a few hot spots in the network assuming all
> > > other links having satisfactory performance, an offline tool may be the
> > > preferred way to identify which traffic trunks that contribute to those
> > > congestion points should be re-routed away from those hot spots, and
> > then
> > > figure out what the new non-shortest path should be, and leave all the
> > rest
> > > of the traffic on its normal shortest path.
> > 
> > If I understand the picture correctly, that offline tool should do the
> > following:
> > 
> > 1. collect statistics from the network and analyze network trunk bandwidth
> > utilization to understand where the hot spot is
> > 2. compute the LSP paths (offline) with certain algorithm for the optimal
> > use of
> > trunk bandwidth in the network
> 	[Chiu, Angela L, NNAD]  Yes. As I pointed out before, between your
> steps 1 and 2, the offline tool needs to identify, for each hot spot, a set
> of traffic trunks that contribute to the congestion and need to be rerouted.
> 
> 
> > But as Dan said in his message, LSPs are more likely to be computed
> > online. I
> > cannot see how a node can compute all LSPs for the whole network. It might
> > be
> > able to do a good job for LSPs originating from itself. But for LSPs
> > originating
> > from other edge LSR? I would think a offline tool is a better place to
> > plan for
> > all LSPs.
> 	[Chiu, Angela L, NNAD]  Actually, it is the ingress node (the node
> where an LSP originates) that is responsible for the path computation based
> on the link state information propagated via IGP extension.
> 
> 	Angela
> 
> > Cheers,
> > Hansen
> > 
> > >
> > >
> > > As far as I know, all the online LSP path computation algorithms
> > provided by
> > > the vendors are not capable of taking the normal IP traffic into account
> > > since the algorithms only see the bandwidth requirements from traffic on
> > > LSPs. If one has to use the online LSP path computation algorithm,
> > he/she
> > > needs to use some offline tool to figure out the aggregate bandwidth
> > > requirement by the normal IP traffic on each link (excluding the traffic
> > > trunks that will be routed via LSPs), substract that from the total
> > > available bandwidth for that link, and make that the new available
> > bandwidth
> > > for the online LSP path computation algorithm to use.
> > >
> > > Regards,
> > > Angela
> > >
> > > AT&T Labs
> > > Room C4-3A22
> > > 200 Laurel Ave.
> > > Middletown, NJ 07748
> > > Tel. (732) 420-2290
> > > Fax (732) 368-1746
> > > Email: alchiu@att.com
> > >
> > > > -----Original Message-----
> > > > From: Daniel Awduche [SMTP:awduche@UU.NET]
> > > > Sent: Monday, April 24, 2000 1:59 PM
> > > > To:   HANSEN CHAN
> > > > Cc:   Anoop Ghanwani; mpls@UU.NET; Daniel Awduche
> > > > Subject:      Re: TE Extension of IGP
> > > >
> > > > Hansen,
> > > >
> > > > Online LSP path computation is the preferred operational model in many
> > > > contexts -- for many good reasons.  Obviously, service providers
> > > > have the option to activate these aspects according to their
> > > > circumstance and needs...
> > > >
> > > > As a simple rule of thumb, in networks with adequate capacity, online
> > > > constraint-based routing should suffice for LSP path placement. In
> > > > relatively under-capacitated networks, however, significant
> > > > offline effort may be required to squeeze additional utility from the
> > > > infrastructure.
> > > >
> > > > Cheers,
> > > > /Dan
> > > >
> > > > On Fri, Apr 21, 2000 at 11:06:08PM -0400, HANSEN CHAN wrote:
> > > > > Dan,
> > > > >
> > > > > I agree that most MPLS implementations perform LSP path computations
> > > > online. But I
> > > > > always thought the working LSPs deployed in the networks are still
> > > > computed
> > > > > offline. You only use online computations when you're
> > > > re-routing/repairing the LSPs
> > > > > around some failure. Is my understanding correct?
> > > > >
> > > > > Cheers,
> > > > > Hansen
> > > > >
> > > > > Daniel Awduche wrote:
> > > > >
> > > > > > Hansen,
> > > > > >
> > > > > > Yes, many (perhaps most) contemporary implementations perform
> > > > > > LSP path computations online. This is a mandatory requirement
> > > > > > in some operational contexts. It's also possible to augment
> > > > > > the online system with offline software tools.
> > > > > >
> > > > > > Cheers,
> > > > > > /Dan
> > > > > >
> > > > > > On Thu, Apr 20, 2000 at 06:04:13PM -0400, HANSEN CHAN wrote:
> > > > > > > Dan,
> > > > > > >
> > > > > > > To make sure I understand. Do you mean the path of LSPs is
> > computed
> > > > on the
> > > > > > > node, not by software tools?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Hansen
> > > > > > >
> > > > > > > Daniel Awduche wrote:
> > > > > > >
> > > > > > > > Actually, the original assertion/generalization is false
> > > > > > > > (i.e. that "LSPs in today's MPLS network are usually computed
> > > > > > > > off-node").
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > > /Dan
> > > > > > > >
> > > > > > > > On Thu, Apr 20, 2000 at 02:08:22PM -0400, Anoop Ghanwani
> > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > I am trying to understanding the use of TE extension of
> > IGP in
> > > > a MPLS
> > > > > > > > > > network. From my understanding, you need TE extension when
> > > > you're doing
> > > > > > > > > > on-node path computation. However, since LSPs in today's
> > MPLS
> > > > network
> > > > > > > > >
> > > > ^^^^^^^^^^^^^^^^^^^^
> > > > > > > > >
> > > > > > > > > We're hoping it won't stay that way forever because it's
> > > > limiting
> > > > > > > > > to have to rely on offline tools for all traffic engineering
> > :-)
> > > > > > > > >
> > > > > > > > > That means that traffic engineering would need to be more
> > > > dynamic,
> > > > > > > > > and the routers would play a more active role in determining
> > > > paths
> > > > > > > > > and possibly doing network optimization.  Hence the IGP
> > > > extensions.
> > > > > > > > >
> > > > > > > > > > are usually computed off-node (in software tool), why
> > would
> > > > the use of
> > > > > > > > > > TE extension be critical?
> > > > > > > > > >
> > > > > > > > > > Appreciate if someone can shed some light on this
> > question.
> > > > > > > > >
>