The MPLS WG Archive

["Chiu, Angela L, ALSVC" <alchiu@att.com>]

Peter,
 
Your points are very valid for the problem context that you are describing
where all or majority of traffic is carried on LSPs, which maybe in the
order of 1000s. The problem I was describing in my earlier email is
different than yours. It is 
>> 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.
For example, an ISP performs capacity planning based on demand forecast. In
practice, the real traffic may be somewhat different than the forecast in
either volume or distribution, maybe both. This may result in a few
congestion points in the network by using normal IGP routing, let's say 3
hot spots in this case. Then based on some offline tool, the operator
identifies that only 5 traffic trunks need to be rerouted using LSPs, and
finds the new path for each traffic trunk using some optimization algorithm.
As pointed out by Dan, if the problem persists, the operator may elect to
re-adjust the link capacity to solve the problem.
 
Regards,
 
Angela
 
-----Original Message-----
From: Peter Ashwood-Smith [mailto:petera@nortelnetworks.com]
Sent: Monday, April 24, 2000 10:57 PM
To: 'MPLS'; Chiu, Angela L, ALSVC
Cc: HANSEN CHAN; Daniel Awduche; mpls@UU.NET
Subject: RE: TE Extension of IGP and draft-ietf-mpls-te-feed-00.txt




To be polite (but blunt). I believe you are wrong for the following reasons.


For a centralized solution to have accurate information it must gather
information from all nodes at approximately the setup/clearning rate of LSPs
in the network. This of course is impractical because the setup/clearing
rate may be 1000's per second during failure/resetup events.

A far more practical approach is to have all nodes aware of general trends,
via the normal OSPF/IS-IS floods and significant floods, and to then
feedback information along routes that are being used either successfully or
unsuccessfully. This allows those nodes that are sourcing LSPs to stay
fairly close to in sync with respect to the real network state, at least for
the slices through the network they are using. We have done considerable
simulation and implementation of this kind of approach and it works quite
well.

See the following draft for descriptions of how this works. I also have a
presentation that was given at the IETF that I can forward to anybody that
is interested. 

 <http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-00.txt>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-00.txt 

Oh, while I am at it, I am hoping to get a last call on this document ...
George, Vijay? 

Cheers, 

Peter Ashwood-Smith 


	BM__MailData-----Original Message----- 
From:   MPLS [SMTP:mpls@apollo.mctr.umbc.edu] 
Sent:   Monday, April 24, 2000 10:46 PM 
To:     Chiu, Angela L, ALSVC 
Cc:     HANSEN CHAN; Daniel Awduche; mpls@UU.NET 
Subject:        RE: TE Extension of IGP 

	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. 
> > > > > > > > > 
>