Subject: RE: Backend TE Support

From: "Don Fedyk" <[email-masked]>
Date: Fri, 21 Apr 2000 09:54:50 -0400

Bora  

We have proposed extensions to the TE metrics for multiple metrics. This 
has been presented at the last two IETF meetings by me.   The last 
presentation is at

http://www.ee.duke.edu/~ag/final-papers/multiplemetrics.pdf

We do not specify what is in the metrics, just that there are multiple
metrics. The draft is focused on static metrics, since we believe that 
that is justification enough. We thought that utilization might be 
one of the possible values in the future I would be interested in your 
comments. 
I was planning to push fo this on the OSPF/IS-IS dicussion groups in the
next day or so. 

Don

> -----Original Message-----
> From: Bora Akyol [mailto:[email-masked]]
> Sent: Thursday, April 20, 2000 11:13 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Backend TE Support
> 
> 
> 
> [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
> > 
> >
> 
> 
>

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 21 Apr 2000 10:31:56 -0400

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

> From: Dave Cooper [mailto:[email-masked]]
> Sent: Friday, April 21, 2000 12:05 AM
> To: Bora Akyol
> Cc: [email-masked]
> 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:
> > 
> > current network utilization metric to the ISIS-TE 
> extensions which got shot

---

From: "Ash, Gerald R (Jerry), ALARC" <[email-masked]>
Date: Mon, 24 Apr 2000 09:50:15 -0400

The I-D located at
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
[email-masked]
----------------------

>Sent: Thursday, April 20, 2000 12:05 PM
>To: [email-masked]
>Subject: Backend TE Support
>

---

From: "Ash, Gerald R (Jerry), ALARC" <[email-masked]>
Date: Wed, 26 Apr 2000 08:56:59 -0400

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. 

>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; [email-masked] <mailto:[email-masked]> 
>Subject: RE: Backend TE Support
>
>
>The I-D located at
<http://www.research.att.com/~jrex/jerry/> 
>>From: Dave Cooper [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Eric Gray <[email-masked]>
Date: Thu, 27 Apr 2000 07:27:02 -0700

Curtis,

	I believe it's the one that can be found at:

    http://www.cs.umd.edu/users/georgeap/

You wrote:
> 
> 
> 
> In message <[email-masked]>, Tony Przygienda writes:
> > Bora Akyol wrote:
> > 
> > > >That would help.
> > > >
> > > >It might also be necessary to provide some sort of advice or
> > > >conventions on flooding frequency since flooding frequency will
> > > >substantially affect many algorithms.  Attempts to provide a high
> > > >degreee of adaptivity can either react very slowly or 
> too quickly and
> > > >go unstable if the flooding frequency and the adaptivity 
> reaction time
> > > >are not well matched.
> > > >
> > > >Curtis
> > 
> > Recently a whole Ph.D. thesis has been done on that very topic
> > by  Apostolopoulos in Watson/UMD, may be worth reading before
> > re-inventing ...
> > 
> >     -- tony
> 
> 
> URL please.
> 
> Curtis
>

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 27 Apr 2000 11:05:33 -0500

Curtis

> From: Curtis Villamizar [mailto:[email-masked]]
<snip>

> 
> I am also pointing to OMP as an example of a use of additional metrics
> which for better or worse, is well defined.  I strongly believe in
> having "working code and first" and then advancing a document so I've
> presented OMP, will implement, then ask for advancement as
> experimental, then only after deployment suggest standards track
> advancement.  Don, Bora, and others, seem taking the opposite approach
> in defining protocol with the intemtion of later determining a use for
> it.  In the past the IETF has insisted that things be well thought out
> and documented and has avoided protocol options with uncertain usage.
> 
> Curtis
> 
I would like to address this. We originally proposed multiple static 
metrics for TE from a real requirement. Now we could have just gone 
for one additional optional metric but the effort is rather large. 
So we went for three additional to give us some breathing room. I 
merely suggested that the way we've defined them that others could 
use them for other things - maybe to get real working code. Perhaps
this was a mistake, although we were planning to experiment with the 
additional metrics if you hadn't already guessed. 

If there is disagreement, we could go for experimental but really all 
we want is a few standard TLV codes that we don't have to redefine. 
The other stuff can be defined later.

Don

> 
> > > In message <4.3.1.2.20000426155007.00b09700@localhost>, 
> Bora Akyol writes:
> > > > OK!
> > > > 
> > > > I would be willing to author/co-author/edit such a 
> draft, but would need 
> > > > help on defining the metrics and formulating them to 
> fit the TLVs, LSAs e
> > tc.
> > > > 
> > > > Any volunteers?
> > > > 
> > > > Bora
> > > 
> > > 
> > > Bora,
> > > 
> > > Perhaps you missed this prior comment:
> > > 
> > >    I don't mean to lend my support for this proposal by 
> commenting and
> > >    suggesting a compromise.  By introducing too much 
> protocol which is
> > >    partially defined, and possibly not well enough thought out, we
> > >    could be creating the standards process equivalent of 
> a Tower of
> > >    Babel.  [Which might not be policially correct since that's ISO
> > >    territory. :)]
> > > 
> > > I am not in favor of a draft which defines information to be
> > > advertised with no stated purpose.  This is a lot like the old TOS
> > > bits, which all sounded like a great idea.  I recall, cost,
> > > throughput, delay, and what was the other one.  They 
> never got used.
> > > IP is fortunate to have minimized such baggage, unlike OSI.
> > > 
> > > OTOH, I do expect to be working on an MPLS-OMP 
> implementation (RSN?)
> > > and will resubmit the OSPF-OMP and MPLS-OMP drafts for 
> consideration
> > > again by the respective work groups.  The OSPF WG seems 
> inclined to
> > > advance the OSPF-OMP as experimental, but I'd prefer to 
> split it in
> > > two, one on flooding, one on OSPF-OMP forwarding.  The 
> MPLS-OMP work
> > > relies on the OSPF-OMP flooding only.  There was also a very small
> > > ISIS-OMP draft which needs to be revised since the sub-TLVs used
> > > conflict with sub-TLVs later taken by ISIS TE extensions for CR.
> > > 
> > > Curtis
> > > 
> > > 
> > > > >go unstable if the flooding frequency and the 
> adaptivity reaction time
> > > > >are not well matched.
> > 
> > 
>