Subject: Backend TE Support

From: Dave Cooper <[email-masked]>
Date: Thu, 20 Apr 2000 16:05:24 +0000

We've been running MPLS in the core for TE purposes
for quite some time now. However, one of the largest hurdles we
have faced is not just the stability of the protocol
but the actual management of protocol. More specifically,
the TE bandwidth statements used to make "optimal" path 
decisions. (Keeping TE bandwidth consistent with 
actual peak flows).

In a large backbone, flows can fluctuate by large
variations (usually due to egress traffic shifts,
down customers, or other external factors) and its
obvious that TE bandwidth can become "outdated" fairly
quickly.

I was inquiring to see if other providers or vendors
have been working on developing software to help 
manage this critical component of MPLS.  The old adage
is correct in "Garbage in, Garbage out" and if TE
bandwidth is not accurate, LSPs will never be
routed over optimal paths.  We have been doing some 
in-house development, but we're always interested in 
outside input or even code that can be co-developed.

-dave

---

From: "HANSEN CHAN" <[email-masked]>
Date: Thu, 20 Apr 2000 13:59:12 -0400

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

Thanks,
Hansen

---

From: [email-masked] (Anoop Ghanwani)
Date: Thu, 20 Apr 2000 14:08:22 -0400 (EDT)

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

---

From: Daniel Awduche <[email-masked]>
Date: Thu, 20 Apr 2000 15:15:40 -0400

Actually, the original assertion/generalization is false
(i.e. that "LSPs in today's MPLS network are usually computed 
off-node").

Cheers,
/Dan

---

From: "HANSEN CHAN" <[email-masked]>
Date: Thu, 20 Apr 2000 18:04:13 -0400

Dan,

To make sure I understand. Do you mean the path of LSPs is computed on the
node, not by software tools?

Thanks,
Hansen

---

From: Daniel Awduche <[email-masked]>
Date: Thu, 20 Apr 2000 19:07:15 -0400

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

---

From: Senthilkumar Rajasekharan <[email-masked]>
Date: Thu, 20 Apr 2000 19:28:33 -0400 (EDT)

Hi Hansen,

> LSP path computations online. This is a mandatory requirement

The following link has a description of an online LSP computation
mechanism ....
http://www.bell-labs.com/user/suter/rates.ps.gz
 
-Senthil

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 20 Apr 2000 16:33:23 -0700

Yet another reason for using extensions to IGPs for TE flooding (at
least in some implementations) is verification against the up to date TE
database build based on those updates and kept on the router even in the
case when you load the explicit lists from the off-line tool. 

It would be quite wastefull to attempt to signall multiple LSPs and fail
only because the off line tool did not have the most recent TE topology.

Robert.

-- 

_____________________________________________________________________

     |          |         Robert Raszuk, CCIE #3690  ICQ #12710752
    :|:        :|:        IOS-Engineering, MPLS Development Team
   :|||:      :|||:       170 W. Tasman Dr. N2, San Jose, CA 95134
.:|||||||:..:|||||||:.    Phone: 408-525-7588     Pager: 888-581-1312
C I S C O S Y S T E M S   Email: [email-masked]   Fax: 408-525-7588
                          URL:   http://wwwin-mpls.cisco.com/
_____________________________________________________________________

---

From: Bora Akyol <[email-masked]>
Date: Thu, 20 Apr 2000 20:12:51 -0700

[posted to the MPLS mailing list]

A while back, a couple of BBN folks including myself had suggested to add a
current network utilization metric to the ISIS-TE extensions which got shot
down due to concerns roughly voiced as " Oh, if you flood dynamic network
information, people may make bad decisions and destabilize the network." Of
course, we could have put the flooding in there and waited on actual
deployment of a protocol that made use of this, but oh well!

But if there is an interest from the network service providers, maybe we
can revisit this and add an extension to the ISIS-TE extensions.

I would certainly be willing to co-author or author such an ID. Moreover,
once we do put this extension in, it allows for different approaches to
traffic engineering.

Regards

Bora Akyol

---

From: Bora Akyol <[email-masked]>
Date: Thu, 20 Apr 2000 20:17:13 -0700

On the contrary,

The IGP extensions are needed because most protection LSP calculation
happens on box and most vendors support automatic routing of LSPs.

Bora Akyol

---

From: Roch Guerin <[email-masked]>
Date: Fri, 21 Apr 2000 07:22:51 -0400

Bora,

We had actually specified something very
similar for OSPF in RFC 2676, and also looked
quite extensively at the issue of what/when
to advertise in order to make routing decisions.
The source of fluctations were a bit different,
but most of the techniques investigated to
dampen them and the results on their impact
should be applicable to the TE problem.  Some
of this was documented in a SIGCOMM'98 paper
by Apostolopooulos et al.

Roch

---

From: "Indra.Widjaja" <[email-masked]>
Date: Fri, 21 Apr 2000 09:50:52 -0400

> happens on box and most vendors support automatic routing of LSPs.

Actually, if you compute your working LSP offline, you would generally
prefer
to also compute the corresponding protection LSP offline, except for
local repair.

indra

---

From: Dave Cooper <[email-masked]>
Date: Fri, 21 Apr 2000 04:05:15 +0000

Bora, i'll limit this since it is operational in nature but
i think that dynamically adjusting TE bw would probably prove
too unstable in a network running thousands of LSPs. Given large
variations in BW levels, tunnel thrashing could easily result. 
Also, IMO using a statiscal sample (hourly, daily or weekly) 
and taking the some peak percentile would probably result 
in a more stable and somewhat accurate representation of TE bw. 
Obviously, this would need to take place off the LSR.  Maybe 
other providers can  ellaborate if they see propagating this 
information beneficial.

My apologies for the operational nature of the thread :)

-dave

---

From: "Ramana V Gollamudi" <[email-masked]>
Date: Fri, 21 Apr 2000 10:22:03 -0400

Hansen,

I think the critical point is about how up to date the TE database information
is.  Using link state IGPs is one convenient way of gathering the latest
apporpriate information required to compute the path of LSPs. Then, where the
computation is done is matter of convenience and effeciency.

Ramana

---

From: "HANSEN CHAN" <[email-masked]>
Date: Fri, 21 Apr 2000 23:06:08 -0400

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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Apr 2000 23:27:36 -0400

> outside input or even code that can be co-developed.

Dave,

Solving this problem is what MPLS-OMP is intended for.  We do plan to
implement MPLS-OMP but there is a lot of work that needs to preceed
it.  OMP is on the back burner for now.  I'm busy with a CR
implementation.  We will also be making the CR bandwidth more dynamic
(use the greateer of a configured value or a filtered measurement).
That is also longer term.

The prior OMP documents are available at the temporary location:
http://www.fictitious.org/omp

[ Yes.  That's a real URL.  Don't be scared, its just a DNS name. :) ]

Regards,

Curtis

---

From: Daniel Awduche <[email-masked]>
Date: Mon, 24 Apr 2000 13:58:36 -0400

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