Subject: RE: DSTE-PROTO: Question/Comments on:Empty TE-Class Map ; Consecu tive CTs

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Thu, 14 Nov 2002 13:37:22 -0500

Hi! Comments in-line.

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: Tuesday, November 12, 2002 11:08 AM
> To: Choudhury, Sanjaya; [email-masked]
> 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:[email-masked]] 
> >> Sent: 08 November 2002 22:38
> >> To: [email-masked]'
> >> 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

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Fri, 15 Nov 2002 09:20:22 -0500

Hi! Comments inline.

> Sent: Friday, November 15, 2002 9:00 AM
> To: Choudhury, Sanjaya
> Cc: [email-masked]
> Sanjaya,
> I am not following you. I am assuming that "empty TE-Class maps" means
> that all of the 8 possible TE-classes are configured to "unused". Is
> this what you mean as well?
> If yes, then the proposed changes discuss exactly that. What 
> do you see
> is still missing?
> If not, what do you mean? the case where the operator has not yet
> configured anything?
> 
	I think the proposed changes _does_ address the issue
	of empty TE-Class maps. [Should have used "does" instead of
	"should" :)]
> >> 	Proposed changes should address the issue of non-consecutive 

	Proposed changes _does_ address the issue of non-consecutive 
	CTs. [Used the wrong word again..]

> But, as I've axplained, I can't really see an issue there.
> It seems quite OK for you to use CT0 and CT7 if that is what you want,
> regardless of the BC model.
> 
> Text on TE-class mapping currently indicates that there is no
> restriction on which CT you use in the TE-class mapping, so 
> we are clear
> here.
> With respect to IGP advertisement of unreserved bandwidth, this has no
> impact (you always advertise the 8 values for each TE-class). 
> So we are
> clear here.
> With respect to IGP advertisment of BCs, I have proposed to 
> enhance the
> text so it makes it clear that you would then have to advertise BC0,
> BC1, ...BC7. So we would be clear here.
> Same thing re IGP advertisment of LOMs. 
> 
> I think that is all we have to say. No?
> 
> >> 
> If text covers the case clearly already, why would we need to add a
> specific example?
> Also, we are trying to keep the proto document independent of the BC
> model.

		As I indicated, this suggestion was for the RDBC Model
		draft. Thought, an example (a scenario) would contribute
		to readers understanding.
		
> Well, changing any LSP parameters (eg bandwidth), or adding 
> an LSP with
> higher preemption, may affect existing LSPs with DSTE or with 
> TE today.
> I don't think we need to discuss that specifically.
> 
> >> 
> I don't think so. I think formulas are applicable as they are. 
> It just happens that, for a given value of b, "Reserved(CTb,q) for all
> values of q (0<=q<=7).
> 
> Thanks
> 
> Francois
> 
> 
> 
> >> 	Thanks,
> >> 	sanjay
> >> 	
> >> > Thanks
> >> > 
> >> > Francois
> >> > 
> >> > >> 
> >> > >> Thanks,
> >> > >> sanjay	
> >> > >> 
> >> > >> 			
> >> > >> 
> >> > >> 
> >> > 
> >> 
>