More comments/questions on DS-TE solution draft

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

Hi! Here are few additional comments related to the DS-TE solution
draft.

1. Probably the draft should explicitly spell out that there has to be a
   well-defined relationship between the BCs and LOMs, to make the
   whole thing work.

    Specifically, for the "Russian Doll"  BC model, the draft should
    spell out the exact relation between CTs/BCs & LOMs.
	some thing like:
	a. Count :  Total number of LOMs == Total number of BC/CT??
	b. Value  : LOM[m] < LOM[n] , where m	> n   ??     or 
     		    BCm * LOM[m] < BCn * LOM[n] , where m > n ??

2. It may not be bad idea to rename the term "Class-Type" as 
   "Bandwidth_Class" [Bw_Class/Bw_pool/Any term that is little
    more descriptive.]. 
    Reasons:
	a) The term Class-Type is non-descriptive.
	b)  In future, people may un-intentionally misuse (overload)
	the term.

3. It will be helpful, if the draft spells out any domain level restrictions
    /recommendations that the user should keep in mind. For example:
	a) Is it necessary for the number of CTs to be same in
	all the links of all LSRs in the DS-TE domain ?
	b) Does the CT identifier have to be consecutive in nature ?
	c) Is it necessary that _all_ the LSRs in the domain MUST 
	support DS-TE. 
	    if it is not necessary then :
		i) What should be the behavior if a LSR that
		does not support the signaled (or inferred) CT ?

4. How can a LSR distinguish between the DS-TE and non DS-TE
    bandwidth advertisement (DS-TE re-uses the existing constructs 
    to advertise the available bw in a CT+priority basis) ?

Thanks,
sanjay