The MPLS WG Archive

["Ash, Gerald R (Jerry), ALARC" <gash@att.com>]

A viewgraph summary of ID <draft-ash-te-qos-routing-01.txt> is located at:
http://www.research.att.com/~jrex/jerry/vgs.te.overview.ppt
<http://www.research.att.com/~jrex/jerry/vgs.te.overview.ppt> 
As mentioned below, these VGs were presented at the IETF47 TEWG, and provide
an
overview of the MPLS/TE simulation studies presented in the draft which
address many
of the topics discussed on this thread. 


>-----Original Message-----
>From: Ash, Gerald R (Jerry), ALARC
>Sent: Monday, April 24, 2000 9:50 AM
>To: 'Dave Cooper'; 'HANSEN CHAN'
>Cc: Ash, Gerald R (Jerry), ALARC; mpls@UU.NET <mailto:mpls@UU.NET> 
>Subject: RE: Backend TE Support
>
>
>The I-D located at
> http://www.research.att.com/~jrex/jerry/
<http://www.research.att.com/~jrex/jerry/> 
>reports simulation results for various LSP computation alternatives (under
>overload/failure scenarios on a large multiservice voice/data network):
>- off-node (centralized) vs. on-node (distributed) computation
>- available-bandwidth flooding vs. no available-bandwidth flooding
>- effect of frequency of available-bandwidth flooding
>- etc.
>In the "Main" (summary) section of the draft, Table 1.2 summarizes the
>comparison results:
>- on-node LSP computation can outperform off-node computation
>- LSP computation without available-bandwidth flooding can outperform
>methods with available-bandwidth flooding
>- etc.
>A viewgraph summary of the draft (presented at the IETF-47 TEWG) is
>available on request.
>----------------------
>Jerry Ash
>AT&T Labs
>Middletown, NJ, USA
>gash@att.com
>----------------------
>
>>-----Original Message-----
>>From: Dave Cooper [ mailto:dcooper@globalcenter.net
<mailto:dcooper@globalcenter.net> ]
>Sent: Thursday, April 20, 2000 12:05 PM
>>To: mpls@UU.NET
>>Subject: Backend TE Support
>>
>>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