RE: Regarding the DiffServ-TE drafts(lefaucheur,boyel,kompella,as h,bi tar)

["Choudhury, Sanjaya" <Sanjaya.Choudhury@marconi.com>]

Some more thoughts (personal opinions) ...

1) We should separate the issue of advertising the 
bandwidth associated with different diffserv classes
from -preemption priority advertisement.

	->Eliminating the pre-emption related advertisements
	reduces the scalability issues to a great extent.

	->Now we are dealing with a traffic engineered network
	 ,where the administrator wants more control and 
	 predictability over the TE-LSP being created in his
	 network. 

	 I don't see, why the administrator would configure
	 his network in such a way that one of the LSPs he 
	 established gets torn down automatically, 30 minutes
       later, by another TE-LSP (of his own creation).

	 Furthermore, we are not creating "UNI" LSPs, which 
	 gets created and deleted frequently and un-predictably.

	->even if there are cases, where one really needs 
	pre-emption, we can address this issue via a separate
	draft.

2) As I mentioned before, in my opinion a 1:1 approach 
(diffserv class: bw adv), is probably the better approach.

The [kompella] drafts proposes 1:1 mapping. However, it 
overloads the priority with the diffserv class bandwidth 
info, there by tightly coupling the per-diffserv-class
bandwidth info with a priority. This has several limitations
	a) user may not want to define a strict "priority"
	between the diffserv classes.

	b) limits the number of class to 8. 
	It is a good idea to limit the number of classes, but 
	this can be handled by configuration.


What about a modified approach that uses the concepts 
outlined in the [kompella] drafts, but encoding in the 
style of [bitar] -explicit PHB-ID . An additional MIB
may help the administrator to further limit the amount
of advertisement by:
	a) limiting the number of classes for which the 
	BW information has to be _explicitly_ advertise
	b) the frequency of advertisement
	c) a possible threshold, which decides whether
	the amount of change in the reserved bandwidth
	should cause the initiation of the new per-class
	bandwidth info.

Do you see any problem with this proposal ?


Thanks,
sanjay



	 

-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Saturday, September 08, 2001 12:44 AM
To: te-wg@ops.ietf.org; wlai@att.com
Subject: RE: Regarding the DiffServ-TE
drafts(lefaucheur,boyel,kompella,as h,bi tar)


>    The two drafts you requested are
> 
> draft-ash-mpls-diffserv-te-alternative-02.txt
> and
> draft-boyle-tewg-ds-nop-00.txt

You forget draft-kompella-tewg-bw-acct-00.txt, which by trading off
the number of priorities per class for the number of classes keeps
the size of IGP updates and the TE database small, between 1/4 and
1/3 the size of the LeFaucheur approach.

Kireeti.