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

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Fri, 8 Nov 2002 16:37:37 -0500

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?
		(b) What should the LSR send out for the following:
			->max_link_bandwidth
			->max_reservable_bw
			->Unreserved Bw TLV (all 0s?)
			->BC & LOM TLV
		(c) Invalid config?

	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 ??

Thanks,
sanjay

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 12 Nov 2002 16:08:04 -0000

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! 

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"

> 			->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:

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?

>> 	 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, ..."

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?

Thanks

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 15 Nov 2002 13:59:50 -0000

Sanjaya,

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

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?

>> 	Proposed changes should address the issue of non-consecutive 
>> 	CTs.

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?

>> 
>> 	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.
>> 

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.

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

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.

>> 
>> 		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. 

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