The MPLS WG Archive

["Don Fedyk" <dwfedyk@nortelnetworks.com>]

Title: RE: Backend TE Support

Dave

Although it is rather experimental adjusting LSPs is far more
stable than adjusting Connectionless metrics. If you look at the
draft-ietf-mpls-crlsp-modify-01.txt the mechanism exists to modify
an individual LSP. BW utilization is one of the indicators this
is required. (BW reservation which is specified, is different however
but some mix the concept).
I like the hotel definition of reservation. The hotel may be fully
booked but not fully utilized. Guaranteed rooms but no-shows.
Links on the other hand can be underbooked but over utilized. 
So BW utilization can be used as an indicator of this situtation.

Don

> -----Original Message-----
> From: Dave Cooper [mailto:dcooper@globalcenter.net]
> Sent: Friday, April 21, 2000 12:05 AM
> To: Bora Akyol
> Cc: mpls@UU.NET
> Subject: Re: Backend TE Support
>
>
> 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
>
>
>
> Bora Akyol wrote:
> >
> > [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
> >
> >
> > At 04:05 PM 4/20/00 +0000, Dave Cooper wrote:
> > >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
> > >
> > >
> >
>
>