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

["Ash, Gerald R (Jerry), ALABS" <gash@att.com>]

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 :-)

> 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):


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.

Thanks,
Jerry