RE: DS-TE overbooking model - Not that complicated

Sandy,
 
>> I'm hoping that instead of LOMs and instead of LSP under-sizing, BC
>> over-sizing will be deemed sufficient to support "per-CT 
>> overbooking"!
>> 

The underlying issue behind this point is pretty much the same as behind
Dimitry's question. Because our BC models (MAM, RDM, MAR,..) enforce one
or more shared/aggregate constraint (as opposed to independent
constraint), there is a fundamental need to be able to "normalise" those
ie make them somehow comparable for applying a shared constraint. Just
configuring (an inflated) BC for each CT does not give enough
information on what is the per-CT overbooking ratio in order to make
them comparable for applying the aggregate constraint. There are two
main conceptual ways to make them comparable:
	- factoring the per-CT overbooking ratio in the LSP size. This
is what the LSP-Size overbooking method recommends.
	- configure locally per-CT overbooking multipliers which contain
information on how to normalise those. This is precisely what the LOM
parameters are.

So the bottom line is that it is not possible to support "per-CT
overboking" purely by adjusting the size of the BCs (when
shared/aggregate constraints are used). The simplest way is to reflect
per-CT overbooking in the LSP Size. The other option is to reflect local
per-CT overbooking multipliers as per LOM.

Thanks

Francois


>> Thanks,
>> Sandy
>>   
>> Sanford Goldfless
>> 192 Fuller St
>> Brookline MA 02446
>> 617-738-1754
>> [email protected]
>> 
>> 
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>> Behalf Of Francois Le Faucheur (flefauch)
>> Sent: Tuesday, May 27, 2003 5:27 AM
>> To: [email protected]
>> Subject: DS-TE overbooking model - Not that complicated
>> 
>> Hello,
>> 
>> We have been through fairly detailed discussions on the overbooking
>> models, which I believe have been very useful to synch up. 
>> This involved
>> a lot of synching up on various terminology and concepts that come to
>> mind to each of us (only in slightly different form for each 
>> individual)
>> on the topic of overbooking. This may have generated a 
>> perception that
>> the overbooking model for DS-TE is fairly complex. I would like to
>> address this potential perception and make the case that the 
>> overbooking
>> model actually selected for DS-TE is (i) quite simple and (ii)
>> structured as minimum possible increment over existing TE overbooking
>> model.
>> 
>> Again, the DS-TE overbooking model has:
>> 	*  two MANDATORY components :
>> 		-A- LSP Size Overbooking
>> 		-B- Link Size Overbooking
>> 	* and one OPTIONAL component:
>> 		-C- Local Overbooking Multiplier
>> 
>> The two main and mandatory components are actually an 
>> integral part of
>> the existing TE. Just they never got discussed that much 
>> explicitely in
>> existing TE documents, but they are fully part of TE. They 
>> are commonly
>> used in TE live deployments today. They have just been inherited by
>> DS-TE and we applied them in the exact same way. Only, they got
>> discussed more explicitely (eg when doing the exercise of 
>> providing CAC
>> formulas and "Unreserved Bw" formulas) to ensure they were understood
>> consistently in the context of multiple CTs. 
>> Note also that like with existing TE, -A- and -B- don't result in any
>> specific protocol extensions (ie you would have the exact same
>> extensions even if you decided to not support Link/LSP Size
>> Overbooking).
>> So I can't see how we could do any simpler here, short of losing
>> overbooking functionality as compared to existing TE.
>> 
>> The third component is the only one where additional complexity over
>> existing TE really comes in. But this all hinges on the potential
>> requirement for overbooking ratios on a per-CT-and-per-link 
>> basis which
>> was identified at some stage as a potential requirements. If there is
>> such a requirement, we do need something beyond Link/LSP Sie
>> Overbooking; no way around it. Rather than re-invent a complete
>> overbooking model for DS-TE, the LOM method is structured as a pure
>> optional increment over Link/LSP overbooking to address this
>> requirement. This is purely optional anyway (and may even be 
>> removed, as
>> being currently discussed).
>> 
>> So, in summary, :
>> 	- the mandatory components of the DS-TE overbooking model are
>> strictly identical to the ones of existing TE (no more, no less)
>> 	- the one optional component is structured as a pure increment
>> over the other components, and is required to provide a specifc DS-TE
>> functionality identified as (potential) requirement. If the 
>> requirement
>> is dropped, this component can also be dropped (we would then be left
>> with an overbooking model for DS-TE which is strictly 
>> identical to the
>> overbooking model of existing TE).
>> 
>> Hope this is useful.
>> 
>> Cheers
>> 
>> Francois
>> 
>> 
>> 
>>