RE: Reflecting new-MAM/SAM definition in diff-te drafts [owner-te-wg@ops.ietf.org in Pass-Through List] ['from' in Pass-Through List] [owner-te-wg@ops.ietf.org in Pass-Through List] ['from' in Pass-Through List]

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

Hello Sanjaya,

>> -----Original Message-----
>> From: Choudhury, Sanjaya [mailto:Sanjaya.Choudhury@marconi.com] 
>> Sent: 22 May 2003 15:30
>> To: te-wg@ops.ietf.org
>> Subject: RE: Reflecting new-MAM/SAM definition in diff-te 
>> drafts [owner-te-wg@ops.ietf.org in Pass-Through List] 
>> ['from' in Pass-Through List] [owner-te-wg@ops.ietf.org in 
>> Pass-Through List] ['from' in Pass-Through List]
>> 
>> 
>> > 
>> > Again, assuming we define LSOM as the "Link Size Overbooking 
>> > Multiplier"
>> > (as opposed to the "LSP/Link Size Overbooking Multiplier"), 
>> > then I agree
>> > with your relationship.
>> > 
>> > Thanks for helping get all this clarified.
>> > 
>> > Francois
>> 
>> Hi! I am not sure it is necessary to introduce the concept 
>> of a new multiplier ("LSOM") in DSTE-PROTO. 
>>

Oh. I couldn't agree more. 

This is what I tried to indicate also in my earlier message:
[FLF] For DS-TE, like for TE, I think we don't need to explicitely 
[FLF] define in
[FLF] the drafts the concepts of LSP/Link Size overbooking 
[FLF] Multipliers (LSOMs)
[FLF] nor formulas using them because we operate directly/exclusively on
[FLF] "normalised" values.  

We only defined LSOM fo the purpose of the email discussion to
facilitate the discussions and confirmed we were all in synch in terms
of overbooking model. But I don't propose to add the LSOM
concept/formulas into the drafts.
 
>> Only change that should probably goto the draft is to replace
>> "Max Link Bw" in formulas by "Max reservable Bw", when user  
>> overrides the maxLinkBw (with a max reservable bw).
>> 

Right. "Max Reservable Bw" will be the value used as the aggregate
constraint on all CTs. 

>> Here is how I understand the types of overbookings:-
>> 1. Link size  overbooking
>> 	-user overrides the 'max link bw' (dictated by 
>> 	the hardware), with a larger/smaller bandwidth 
>> 	reservable on the link, be by configuring a 
>> 	'max reservable bw'.

Yes.
Minor detail. I am not sure what you meant exactly by "override". The
way I would put it is that we always use the Max Reservable bw (which
may be set by default to the actual Link Bandwidth or may be configured
by operator to some larger/smaller value). I think we agree.

>> 	-no additional multipliers are needed 

Yep.

>> 2. LSP size overbooking
>> 	-user reserves more/less amount of BW for the LSP
>> 	compared to the actual amount of traffic the LSP
>> 	is expected to carry.
>> 	-No additional 'multipliers' are needed. The LSP
>> 	BW follows the normal BCs based on the CTs

Yep.

>> 3. per CT overbooking
>> 	-user specifies the LOM on a per CT per interface
>> 	basis. LSP BW adheres to BCs dictated by the CT it
>> 	is associated with 

Yes. Factoring in the LOM, of course.

Good summary of overbooking methods. Thanks.

>> 	-when user has overridden the 'max link bw' by 
>> 	configuring a explicit 'max reservable bw', the 
>> 	user specified value should be used as the upper
>> 	limit for the link.
>> 
>> Reserved(CTx) vs Normalized(CTx):
>> If no LOM is being used, we can assume the LOM to be
>> 1 (100% no over/underbooking). This will allows us
>> to use Normalized(CTx) in all the formulas (instead
>> of two sets -one with Reserved and the other with 
>> Normalized).
>> 

The drafts already state that when LOM are not used it means they are
set to 1.
I had put the two sets of formulas with/without LOM because LOM is
purely an optional mechanism [ and frankly I don't expect it to be used
that often considering how much you can achieve with Link overbooking
and LSP overbooking] so I thought it would be useful to state the
formulas without LOM . 
Note that while the CAC formulas are pretty much the same with/without
LOM (with simple substitution of "reserved" by "normalised") the
formulas for computing Unreserved BW do get less intuitive with LOM than
without.

Thanks for your comments and analysis.

Francois

>> Thanks,
>> sanjay
>> 
>> 
>>  	
>> 
>>