[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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