RE: DSTE-PROTO: Question/Comments on:Empty TE-Class Map ; Consecutive CTs

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

Hi! Comments in-line.

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
> Sent: Tuesday, November 12, 2002 11:08 AM
> To: Choudhury, Sanjaya; te-wg@ops.ietf.org
> Cc: Francois Le Faucheur (flefauch)
> Subject: RE: DSTE-PROTO: Question/Comments on:Empty TE-Class Map ;
> Consecutive CTs
> 
> 
> Hello Sanjaya,
> 
> Thanks for raising these valid points. See below proposed approach for
> those:
> 
> >> -----Original Message-----
> >> From: Choudhury, Sanjaya [mailto:Sanjaya.Choudhury@marconi.com] 
> >> Sent: 08 November 2002 22:38
> >> To: 'te-wg@ops.ietf.org'
> >> Subject: DSTE-PROTO: Question/Comments on:Empty TE-Class Map 
> >> ; Consecutive CTs
> >> 
> >> 
> >> Hi Francois! 
> >> I have few questions/comments related to the TE-Class Map as 
> >> described 
> >> in DSTE-PROTO draft.
> >> 	1. What should be the behavior of a DSTE LSR, if the TE-Class 
> >> 	map defined on the LSR is empty?
> >> 		(a) How should the incoming unreserved Bw TLV should 
> >> 		be interpreted?
> >> 			->assume no bandwidth on the link?
> 
> 
> In section 5.2, we currently have the following:
> "If TE-Class[i] is unused, the value advertised by the IGP in
> "Unreserved TE-Class [i]" MUST be set to zero."
> 
> I would propose to add (immediately after the above):
> "... and the value received in the IGP in "Unreserved TE-Class [i]" is
> to be ignored"
> 
> >> 		(b) What should the LSR send out for the following:
> > 			->Unreserved Bw TLV (all 0s?)
> 
> This one is already covered by current text:
> "If TE-Class[i] is unused, the value advertised by the IGP in
> "Unreserved TE-Class [i]" MUST be set to zero."
> ==> if all TE-classes are unused, then all Unreserved Bw values
> adevrtised will be set to zero.
> 
> >> 		(b) What should the LSR send out for the following:
> >> 			->max_link_bandwidth
> >> 			->max_reservable_bw
> >> 			->BC & LOM TLV
> >>
> 
> I don't think we have to say anything special for all these 
> parameters.
> They can be configured to anything and they may be 
> advertised, but they
> just won't get used (I think if we add the proposed 
> clarifications above
> and below, this will be pretty clear).
> 
> >> 		(c) Invalid config?
> >>
> 
> Although not a useful config in normal operations, I think it can be
> seen as a valid config. It effectively amounts to disabling TE/DS-TE,
> since no TE/DSTE LSPs can be setup.
> It can be handled as described above.
> 
> I would propose to add a statement in 4.2.1 saying something like
> "Configuring all the 8 TE-Classes as "Unused" effectively results in
> disabling TE/DS-TE since no TE/DS-TE LSP can be established (nor even
> configured, since as described in section 4.3.3, the CT and preemption
> priorities configured for an LSP must form one of the configured
> TE-Classes)"
> 
> 
> Would the proposed changes address that point?
> 


	I think the proposed changes should address the issue
	of empty TE-Class maps.


>  
> >> 	2. Do we need to enforce that all the CTs defined in 
> >> the TE-Class
> >> map
> >> 	be numerically consecutive ?
> >> 	
> >> 	If we allow non-consecutive CTs to be defined, how can 
> >> we identify 
> >> 	the corresponding values from IGP advertisement TLVs 
> >> (which assume 
> >> 	that the CTs are defined consecutively and in order) ?
> >> 
> >> 	->Since user can always define CT0,CT1 & CT2, instead of
> >> CT0,CT1,CT3;
> >> 	 does it make sense to allow non consecutive CTs ??
> >> 		
> 
> For the reason you described, I would expect that the most common case
> would be to use consecutive CTs, and the current spec is (implicitely)
> optimised for that case.
> However, I don't think we need to enforce that the CTs used be
> consecutive (eg in case SP wants to keep one in the middle for future
> use or something).
> If the CTs used are non-consecutive, then the only drawback 
> is that the
> IGP advertisment of the optional information (BCs, and LOMs) 
> is slightly
> sub-optimal (ie includes useless values).
> For example, if the SP decides to define active TE-classes from CT0,
> CT1, CT3 only, then:
> 	- if the SP only advertises mandatory info (eg Unreserved Bw),
> then encoding remains optimal since 8 "unreserved Bw" values 
> are always
> advertised.
> 	- if the SP decides to also advertise optional info (eg BC,
> LOMs) , then the encoding is slightly suboptimal since 4 
> values will be
> advertised instead of 3 (eg advertise BC0, BC1, BC2, BC3 where BC2 is
> useless).
> 
> The current text needs to reflect that better.
> For example, in section "5.1 Bandwidth Conbstraints", current 
> text says:
> "It is recommended that only the Bandwidth Constraints 
> corresponding to
> active CTs be advertised ...".
> We could replace that with something like:
> "Where the configured TE-class mapping and the Bandwidth Constraints
> model in use are such that BCh+1, BCh+2, ...and BC7 do not 
> relate to any
> of the Class-Types associated with a configured TE-class, it is
> recommended that only the Bandwidth Constraints from BC0 to BCh be
> advertised, ..."
> 


	What should be advertised, when the TE-Class Map is empty: None ? 
	(Kind of contradicts the previous proposal that allows the adv.
	of the configured BC values when the map is empty).



> Also the current following text:
> "For example, considering the case where a Service Provider deploys
> DS-TE with two active CTs and where two bandwidth constraints per link
> apply ..."
> would need to be replaced with:
> "For example, considering the case where a Service Provider deploys
> DS-TE with TE-classes associated with CT0 and CT1 only, and where the
> Bandwidth Constraints model is such that only BC0 and BC1 
> relate to CT0
> and CT1,...
> 
> Similar changes could be made in section "5.3 Local Overbooking
> Multiplier".
> 
> 
> Would the proposed changes address that point?
> 
	Proposed changes should address the issue of non-consecutive 
	CTs.

	Few suggestions/comments:
		1. It will be helpful to add an example to the RDBC Model
		   draft, that deals with a non-consecutive CT scenario.

		2. Adding a new CT, in the middle of two existing CTs 
		   may affect the existing LSPs using existing CTs. Need
		   spell out explicitly ?

		3. I am not sure, if any of the formula presented in RDBC 
		   drafts need to be updated to handle the case of 
		   non-consecutive CT (and BC?) case. 
	Thanks,
	sanjay
	
> Thanks
> 
> Francois
> 
> >> 
> >> Thanks,
> >> sanjay	
> >> 
> >> 			
> >> 
> >> 
>