RE: link capacity and reservable

[Dimitry Haskin <dhaskin@axiowave.com>]

Francois,

Thanks for your clear explanation. What has escaped me before is that LOM is
useful only for those cases where both of the following must be true:

 1) CTs of the same link have different overbooking ratios.
 2) The amount of reservations in one CT must precisely effect reservable
bandwidths in other CTs of the same link.

If I am correct, then it is quite possible to support different overbooking
ratios per CT per link without LOM, provided that 2) is not required (or at
least not with the same level of precision that LOM can provide).

Thanks,
 Dimitry




> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
> Sent: Wednesday, May 28, 2003 4:58 AM
> To: Dimitry Haskin; Ash, Gerald R (Jerry), ALABS
> Cc: te-wg@ops.ietf.org
> Subject: RE: link capacity and reservable
> 
> 
> Hello Dimitry,
> 
> >> -----Original Message-----
> >> From: Dimitry Haskin [mailto:dhaskin@axiowave.com] 
> >> Sent: 27 May 2003 17:37
> >> To: Francois Le Faucheur (flefauch); Ash, Gerald R (Jerry), ALABS
> >> Cc: te-wg@ops.ietf.org
> >> Subject: RE: link capacity and reservable
> >> 
> >> 
> >> Francois,
> >> 
> >> > 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.
> >> >
> >> 
> >> For my sake.. Since b/w constrains are advertised and 
> >> handled per CT per TE
> >> link (i.e. there are separate BCn values on each visible 
> link in a TE
> >> domain), why is LOM necessary to achieve overbooking per  CT 
> >> per link?  
> 
> LOM is necessary because the BC Models we are considering enforce one
> (or more) shared/aggregate constraint(s).
> 
> If we had a trivial BC model of pure independent bandwidth 
> constraints,
> then yes, each CT could operate independently and do its own 
> computation
> of how much is taken from its own BC. And we would not need LOM.
> 
> But since we have shared aggregate constraints (aka Max Reservable Bw)
> you need to somehow configure what is the individual overbooking ratio
> that is to be considered on that link for that CT, for the purpose of
> deducting bandwidth from the shared/aggregate constraint. This is the
> vectorisation issue that Waisum raised. The "euro vs dollar" 
> question as
> Wai put it.
> 
> In other words, considering MAM (with new definition), imagine you
> configure BC0=1000 (probably reflecting some high overbooking) and
> BC1=100 (probably reflecting some low overbooking), and
> Max-Reservable-Bw=300 (probably reflecting an average 
> overbooking on an
> aggregate basis). One would not know exactly how to apply the Max
> Reservable Bandwidth differntly to CT0 LSPs and CT1 LSPs in order to
> compute the. For example if you have established one CT0 LSP 
> of 500 and
> one CT1 LSP of 50, how much exactly is left available to CT0 and CT1?
> 
> With the LOM solution, you configure BC0=100, BC1=50 , Max Reservable
> Bw=130, LOM(0)=10 and LOM(1)=2. Then you know exactly how to apply the
> Max Reservable Bandw constraints (see formulas in dste drafts) and how
> to compute the available bandwidth for each CT dependeing on how much
> LSPs are established acros ALL other CTs.
> 
> I suggest looking at section 6.2 of diff-te-russian where the formulas
> make clear the role of LOM in various computation.
> 
> One could probably come up with solutions which are slightly different
> to LOM, but the LOM solution is very attractive because, 
> again, it is a
> pure increment to the other overbooking methods which exist 
> in TE today.
> 
> Cheers
> 
> Francois
> 
> >>Or
> >> is it that link0 and link1 in your example form a some kind 
> >> link bundle, i.e
> >> form a single TE link as far as OSPF/ISIS TE extensions are 
> >> concerned?
> >> 
> >> Thanks,
> >>  Dimitry
> >> 
> >> 
>