Subject: [Isis-wg] RE: FYI Draft Metrics and Resource Classes for TE

From: "Don Fedyk" <[email-masked]>
Date: Thu, 21 Oct 1999 16:26:56 -0500

Dan and Angela:

Yes, As you both pointed out it maximizes the bandwidth only on a next hop
link basis not a path basis. I will correct the text.
This is not key to the arguments of the draft but it does illustrate
how bandwidth allocation is advantageous. 

Thanks,
Don

> -----Original Message-----
> From: Chiu, Angela L, ALSVC [mailto:[email-masked]]
> Sent: Thursday, October 21, 1999 4:53 PM
> To: [email-masked]; Fedyk, Don [BL3:2001-I:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: RE: FYI Draft Metrics and Resource Classes for TE
> 
> 
> Jon,
> 
> I echo what Dan pointed out earlier. By making link cost to 
> be the inverse
> proportional to available bandwidth, it only says that the 
> least cost link
> is the one with the most available bandwidth.
> 
> 	Your statement that 
> 	"the shortest path corresponds to the path with the 
> most bandwidth"
> is not even true for paths with the same number of hops. For 
> example, let
> link cost to be the inverse of the available bandwidth. 
> Available link bandwidth on path A: 1, 6, 6, 6, 6, 6, 6 => 
> path available
> bandwidth = 1, with path cost = 2
> Available link bandwidth on path B: 2, 3, 3, 3, 3, 3, 3 => 
> path available
> bandwidth = 2, with path cost = 2.5
> 
> Hope the example helps.
> 
> Angela Chiu
> 
> AT&T Labs
> Room C4-3A22
> 200 Laurel Ave.
> Middletown, NJ 07748
> Tel. (732) 420-2290
> Fax (732) 368-1746
> Email: [email-masked]
> 
> > -----Original Message-----
> > From:	[email-masked] [SMTP:[email-masked]]
> > Sent:	Thursday, October 21, 1999 4:26 PM
> > To:	[email-masked]
> > Cc:	[email-masked]; [email-masked]; [email-masked]
> > Subject:	Re: FYI Draft Metrics and Resource Classes for TE
> > 
> > Jon,
> > 
> > A note on your draft...
> > 
> > You made the following assertion in the draft..
> > 
> >  "On the other hand, it is also possible to look at bandwidth as an
> >   additive metric by using link costs that are in inverse proportion
> >   to available bandwidth; in such cases, the shortest path
> >   corresponds to the path with the most bandwidth."
> > 
> > This assertion is, of-course, false (that is that the shortest
> > path based on inverse bandwidths is the one with the most 
> > bandwidth). You may wish to correct it in the next iteration 
> > of your draft. 
> > 
> > Regards,
> > /Dan
> > 
> > 
> > Don Fedyk said:
> > > 
> > > We have submitted the draft: draft-fedyk-mpls-te-metrics-00.txt
> > > for review to the following working groups:
> > > - Traffic engineering
> > > - MPLS
> > > - IS-IS
> > > - OSPF
> > > 
> > > We asked to present it to the TE and ISIS working groups.
> > > 
> > > Abstract
> > > 
> > >    There has recently been a lot of activity in defining 
> the components
> > >    for MPLS-based traffic engineering.  This includes the recent
> > >    extensions of the Interior Gateway Protocols (IGPs) to 
> carry metrics
> > >    and resource class information about links.  This memo explores
> > >    additional metrics that are useful for traffic 
> engineering.  We also
> > >    describe some of the subtleties associated with the use of the
> > >    resource class (or color) vector that has been defined 
> in the IGP
> > >    extensions.
> > > 
> > > For those interested, a copy is avialable at:
> > > http://www.ee.duke.edu/~ag/final-papers/mpls-te-metrics.txt
> > > Thanks,
> > > -Don Fedyk and Anoop Ghanwani
> > > 
> 

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 22 Oct 1999 10:43:34 -0400

> From: Tony Przygienda [mailto:[email-masked]]
> Sent: Thursday, October 21, 1999 9:30 PM
> To: Fedyk, Don [BL3:2001-I:EXCH]
> Cc: Chiu, Angela L, ALSVC; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Isis-wg] RE: FYI Draft Metrics and Resource 
> Classes for TE
stuff deleted

> 
> first, I think that the draft is dearly missing the reference 
> to the QoSR
> RFC 2386 by Raj & Bala that does much more thorough (and error-free) 
> job of explaining the problem and well-known research results 
> in terms of 
> algorithmic complexities and available design space and would 
> make some of it
> superfluous. 

We will add the reference. Thank you.

It is evident that there is some confusion. We are only addressing 
connection oriented traffic engineering metrics not 
connectionless metrics. I will try to be more clear.

In my experience I have effectively used multiple connection
oriented TE metrics. I believe this is worthwhile going forward. 
We have customers that request it. The multiple metrics we ask 
for are for traffic engineering MPLS not IGP. 

> second, it may be better to aim for a presentation at the 
> routing area meeting
> rather than in ISIS and OSPF & other groups disjointly since 
> the interested parties
> will be there and this is not a draft asking for specific TLVs / LSA 
> additions but somehow for extensions to the generic scope of 
> the work. As well,
> presenting to 4 groups is kind of a strain ;-)

We only asked for MPLS TE and IS-IS at this point.

> 
> third, IMHO I'd be reluctant to put into the protocol metrics 
> that are a 
> "network administrative decision". An IGP is _not_ a network 
> management tool.
> Metrics have crisp meanings. Otherwise issues of metric 
> translation, ranges,
> consistent computation algorithms and so on will be an 
> interesting albeit
> not very constructive exercise on a live network.

I am confused. The IS-IS draft has TE metrics and resources
this is what we were trying to address.

> 
> fourth, Tony Li's name is misspelled until he changed his 
> name with his job ;-)
Yes, Henk Smit pointed this out already. I apologized to Tony Li. 
I will update the document. 

> 		thanks 
> 		- tony
Thanks, 
Don