[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: link capacity and reservable
>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALABS [mailto:email@example.com]
>> Sent: 26 May 2003 22:49
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALABS; firstname.lastname@example.org
>> Subject: RE: link capacity and reservable
>> 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 :-)
You are absolutely correct that I did swap "LSP"/"Link". How silly is
that ... right in the middle of a text attempting to clarify things...
Thanks a lot for correcting it. Hope this removes the "over-confusion".
>> 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
I absolutely agree that "LSP Size Overbooking" and "Link Size
Overbooking" can be used simultaneously (I like that sentence because
even if I swap "LSP"/"Link" it is still correct 8^)).
This allows to simultaneously enforce overbooking ratios on a
per-CT-basis (eg. CT0 is overbooked by factor 2, CT1 is not overbooked)
and overbooking ratios on a per-link-basis (ie link0 is overbooked by
factor 1.3 and link1 is overbooked by factor 1.1).
My point below was about enforcing overbooking ratios on a
per-CT-and-per-link basis (ie CT0 is overbooked by factor 2 on link 0
and overbooked by factor 3 on link 1, while CT1 is not overbooked on
link0 nor on link1). This could NOT be achieved just by combination of
"LSP Size overbooking" and "Link Size Overbooking"; it could only be
achieved via the use of the LOM method. But, as being discussed, it is
not obvious that the nbeed for this justifies the extra complexity.
>> 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
>> * - 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
>> 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.