[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
>> 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, ..."
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
>>
>> Thanks,
>> sanjay
>>
>>
>>
>>