The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Apr> msg00259



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

TE Extension of IGP and draft-ietf-mpls-te-feed-00.txt

  • From: "Peter Ashwood-Smith" <petera@nortelnetworks.com>
  • Date: Thu, 27 Apr 2000 11:02:33 -0400
  • Organization: Nortel Networks

Chiu, Angela L, ALSVC wrote:
> 
> 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

  A problem we face, as software designers is making our software work for
an entire problem space. If we pick a subset of the problem space and only
solve it, we have to be very clear that is all we intend to solve. MPLS
/ traffic engineering is aimed at solving the same problems that ATM solves
today. That is to say, large numbers of LSPs of all different layer 1 and 0
types of transport from optical to shim and atm/fr transport. 

  We cannot begin to predict how many LSPs will be needed in the networks of
tomorrow although we can assume that we will need at least as many as we
have today in ATM style networks. As a result our problem space is larger than
that which you describe and hence our solutions must take that entire space
into account. 

  I know some people view MPLS TE as just a few LSPs here and there and
that scaling is not an issue, I disagree with this and believe that attitude
will severly limit the usefulness of MPLS TE. As MPLS heads into the optical
domain and SONET domain it will have to address concerns of large carriers 
with carrier grade expectations and this implies good scalability and predictable
performance.

  Cheers,

  Peter