RE: Regarding the DiffServ-TE drafts(lefaucheur,boyel,kompella,ash,b itar)

["Naidu, Venkata" <Venkata.Naidu@Marconi.com>]

All DiffServ-TE:

    I have few more concerns apart from what Sanjay asked...

  * draft-lefaucheur-diff-te-proto-00.txt draft says, 
    preemption is allowed across DiffServ CTs, but where as, 
    Ash draft says, No preemption of LSPs across CTs (except 
    for control CT)

    In my option, If LSPs preempt across CTs, then what is
    the use of DiffServ CT boundaries?

  * Is there consensus on TLV Types for IGPs. (If at all we
    are agreed to flood DiffServ TE info using IGPs)


  draft-ash-mpls-diffserv-te-alternative-02.txt:
  * I have few comments on this draft. I am not very clear why
    Restoration comes into picture in DiffServ TE model.

    We should allow some flexibility to the user, to decide
    how he/she chooses to do Restoration/Recovery.
    (as suggested by draft-ietf-mpls-recovery-frmwrk-02.txt)
    
    For example, Number of LSPs used for restoration 
    (full/partial diverse) is not expected in this draft.

  * Why do we need a separate class for Control Traffic? (CT 6)
    I feel, we should give flexibility to send control traffic
    in any of the CTs.


--Venkata Naidu


-> > 	Hi! I Now there are 4 different documented approaches related 
-> > 	to support of DiffServ-TE by IGPs (lefaucheur,boyel,kompella,
-> > 	ash,bitar). As far as I know, the last round of 
-> discussion on this
-> > 	issue, ended without any consensus. I thought it may not be 
-> > 	bad idea to have another round of discussion.
-> > 
-> > 	In my opinion, we can broadly divide the discussions into
-> > 	two areas: 
-> > 		(a) Whether (and How) to advertise the per-class(/type)
-> > 		bandwidth information via IGPs
-> > 		(b) Pre-emption
-> > 
-> > 	To limit the scope of discussion, in this thread, let 
-> us discuss 
-> > 	the first issue only.
-> > 
-> > 	Here are some of my observations and thoughts (If my 
-> observations
-> > 	from existing drafts are incorrect please correct me).
-> > 	
-> > 	Your coments will be appreciated.
-> > 
-> > 	Thanks,
-> > 	sanjay
-> > 
-> > 	Q1. Do we need to advertise the per-class (/type) bandwidth
-> > 	information via IGP ?
-> > 	
-> > 	 -As far as I understand, two of the drafts  (ash,boyel?) prefer
-> > 	 not to advertise per-class bandwidth info for 
-> scalability reasons.
-> > 
-> > 	-In my opinion, it is better to advertise the per-class 
-> bandwidth
-> > 	info via IGP. This information, will help the path computation 
-> > 	module to do a better job. And one can handle, the scalability
-> > 	problems, via different mechanisms (as illustrated by other 
-> > 	drafts). 
-> > 		
-> > 	Q2. If we need to advertise the per-class(/type) bandwidth 
-> > 	information, Should the domain administrator have control
-> > 	over the granularity of the information get advertised in his
-> > 	domain. ?
-> > 
-> > 	-In my opinion, the domain administrator should have control 
-> > 	the per-class BW info that gets advertised in his domain via 
-> > 	a MIB (bandwidths for classes that are not advertised can be
-> > 	folded into the un-reserved bandwidth associated with the link)
-> > 
-> > 	Q3. How do we advertise the per-class(/type) bandwidth info?
-> > 		(a) 1-1 mapping with diffserv classes
-> > 		(b) m-1 mapping with diffserv classes (lefaucheur)
-> > 
-> > 	-In my opinion, 1-1 mapping is simpler and achieves the purpose
-> > 	without introducing new concepts (class-type).
-> > 	-1-1 mapping
-> > 		-one of the drafts (bitar) explicitly advertises the BW 
-> > 		associated with the class
-> > 
-> > 		-the other draft(kompella) overloads the diffserv-class
-> > 		with the priority information.
-> > 		
-> > 		-which approach is better ?
-> > 
-> > 	Thanks,
-> > 	sanjay