[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: link capacity and reservable
Hello Jerry,
>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
>> Sent: 26 May 2003 22:49
>> To: Francois Le Faucheur (flefauch)
>> Cc: Ash, Gerald R (Jerry), ALABS; te-wg@ops.ietf.org
>> Subject: 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 :-)
>>
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
>> together?
>>
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.
Thank you
Francois
>> 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.
>>