RE: link capacity and reservable

Francois,

I must say that there seems to be an over-complexity of over-booking options in DS-TE.  What is making this discussion over-ly confusing for me is that I think your explanation reversed the use of 'Link Size Overbooking' and 'LSP Size Overbooking' a couple of times.  Please check below between the ** marks where I've substituted what I thought was the correct explanation and/or term.

Sorry to add confusion if this 'correction' is incorrect :-)

Also, your discussion implies that LSP Size Overbooking and Link Size Overbooking are used individually, but not together.  If so, why can't they (or shouldn't they) be used together?

Thanks,
Jerry

I believe there was clear agreement that:
	- there was a strong need for SPs to be able to apply, on a
network wide basis, a different level of overbooking for different CTs
(typically high overbooking on best-effort, low/no overbooking on
premium/voice)
*	- this was well supported by the "LSP Size Overbooking" method
(which allows different overbooking per CT - it even offers finer
granularity of per-LSP overbooking)*
	- there was a strong need for SPs to be able to apply a
different level of overbooking on differnet links (typically higher
overbooking on higher speed links)
*	- this was well supported by the "Link Size Overbooking" method
(effectively just pretending to have a bigger link than the real one ;
and thus effectively applying a single per link overbooking which is
COMMON to all CTs)*
	- there was only a weak potential need for being able to apply
different overbooking ratios which need to be different for each CT on
different links.
	- this should be OPTIONAL
	- this would be well supported by the per-CT Local Overbooking
Multiplier.

A related conclusion of the above is that the "Link Size Overbooking"
method does NOT need to enforce different overbooking ratios for
different CTs. If the SP needs different overbooking ratios for
different CTs, then, in the context of DS-TE, this can be achieved via
the "LSP Size Overbooking" method.

Since the "Max Reservable Bandwidth" is involved only in the "*Link* Size
Overbooking" method, it does NOT need to enforce a different level of
overbooking for different CTs; enforcing the same one across all CTs is
all what's required. This means that, taking into account the specific
environment of DS-TE, the aggregate constraint does not need to be
vectorised (although I agree that in a completely generic world it would
have to).

Now, in the case where the SP wants to enforce different overbooking
ratios for different CTs on different links, then this needs to be
achieved via the LOMs (and not via the "Link Size Overbooking"). Then
the LOMs need to be applied individually to each CT which effectively
results in the vectorisation you described. This will be reflected in
the CAC formulas when updated to reflect the aggregate constraint (which
will be applied to the "Normalised Bw"). 

So to recap in a nutshell, I believe the generic "vectorisation" issue
you discussed:
	- does not apply to Link Size Overbooking in the particular case
of DS-TE (since Link Size Overbooking does not need to enforce different
overbooking ratios across CT) and thus we only need a single "Max Res
Bw" value
	- does apply to the Local Overbooking Multiplier method and
is/will be reflected by applying the "Normalised Bw" when applying the
aggregate constraint.