RE: Dropping the Local Overbooking Multiplier (LOM) method from DS-TE specs?

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

Hello Jerry,

>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] 
>> Sent: 02 June 2003 16:34
>> To: Francois Le Faucheur (flefauch); te-wg@ops.ietf.org
>> Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS
>> Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
>> method from DS-TE specs?
>> 
>> 
>> Francois, All,
>> 
>> > The current approach is NOT complicated. Please see the 
>> specific email
>> > on this. 
>> 
>> That's your view, but I don't think it constitutes a proof 
>> of same :-)
>> 

Absolutely right. 
Just like I would rather see statement saying that someone finds the
current model rather complicated as opposed to statement saying it is
rather complicated. 8^)

>> > Note that its two main components (Link/Size Overbooking) are
>> > directly inherited from existing TE. These two should not 
>> be modified in
>> > any way so they remain backward compatible with existing TE anyway.
>> > The current model works, all formulas are documented and 
>> we had lots of
>> > discussion so everybody is fully synched up on it now.
>> > I see no justification to enter a new round of let's reinvent the
>> > overbooking model for DS-TE at this post Last-Call stage.
>> 
>> I expected this comment, of course.  However, DS-TE is a 
>> *new* environment (CTs, BC models, etc.), and we should have 
>> the right to define things within that new environment.
>> 
>> However, so as to not drag this out, and come to closure, 
>> I'm OK to go with your proposed formulas, pending a final 
>> agreement on LOM (see below):
>> 
>> 

Great. This should allow us to move ahead fast as soon as we make a
final call on what to do with LOM.

>> When LOM is NOT used (i.e. LOM[i]=1)
>> =================================================
>> o for each value of b in the range 0 <= b <= 7:
>>   Reserved (CTb) <= BCb,
>> o SUM (Reserved(CTc)) <= Max-Reservable-Bw,   
>>   where the SUM is across all values of c in the range 0 <= c <= 7
>> 
>> When LOM is used 
>> ===============================
>> o for each value of b in the range 0 <= b <= 7:
>>   Normalized (CTb) <= BCb,
>> o SUM (Normalized(CTc)) <= Max-Reservable-Bw,   
>>   where the SUM is across all values of c in the range 0 <= c <= 7
>> 
>> "Unreserved TE-Class [i]" when LOM is NOT used (i.e. LOM[i]=1)
>> ============================================================
>> MIN  [
>> [ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p ,
>> [ Max_Reservable_Bw - SUM ( Reserved(CTb,q) ) ] for q <= p 
>> and 0 <= b <= 7,]
>> where:
>> TE-Class [i] <--> < CTc , preemption p>
>> in the configured TE-Class mapping.
>> 
>> "Unreserved TE-Class [i]" when LOM is used
>> ==========================================
>> LOM(c) x MIN  [
>> [ BCc - SUM ( Normalized(CTb,q) ) ] for q <= p,
>> [ Max_Reservable_Bw - SUM ( Normalized(CTb,q) ) ] for q <= p 
>> and 0 <= b <= 7,]
>> where:
>> TE-Class [i] <--> < CTc , preemption p> 
>> 
>> > The idea of Experimental is that LOM would be neither "dead" nor
>> > "standards". It would suggest that LOM is something we've 
>> discussed and
>> > documented and some people may want to play with. 
>> Experience will tell
>> > us what we should do with it.
>> > Another good thing with Experimental is that I don't think 
>> we have to
>> > all agree that it is a useful thing as long as some people do. I
>> > personally would have no problem in dropping LOM altogether, but my
>> > impression was that some people had a problem in dropping 
>> it altogether
>> > because we just don't really know whether it will be 
>> useful or not. That
>> > sounded like Experimental track to me.
>> > 
>> > Do you feel there is rough consensus to drop LOM 
>> altogether (that would
>> > work for me)?
>> 
>> I have not seen anyone give an example of where LOM is 
>> needed.  Unless we see that, my preference would be to drop 
>> it.  LOM is a real parameter, and at present needs to be 
>> carried in the RSVP extensions for DS-TE.  It requires 
>> addition aggregation constraints in the BC models.
>> 
>> Considerations of per-CT and hi-speed vs. low-speed links 
>> can be easily accommodated, as I gave in an example by using 
>> just LSPOM and LSOM (see earlier post 
>> http://ops.ietf.org/lists/te-wg/te->> wg.2003/msg00314.html).  
>> It seems like much more than 
>> enough flexibility to avoid any problems, without also 
>> further complication with LOM.  
>> 
>> Can anyone explain why LOM would be needed, and in 
>> particular, give a practical example of same?
>> 
>> It seems to have marginal value (I don't see anyone showing 
>> how it is needed, or really supporting it).  I think we can 
>> agree that simplification *will* be achieved if we eliminate LOM.

We can certainly agree on that.

So let's see if we hear some justiication for LOM or not, and based on
that we can finalise decision (hopefully within a few days) firstly to
take LOM out of base specs, and secondly to drop altogether (or document
as Experimental).

Cheers

Francois

>> 
>> Thanks,
>> Jerry
>>