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

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

Jerry,

>> -----Original Message-----
>> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com] 
>> Sent: 02 June 2003 14:02
>> 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,
>> 
>> > no one has expressed objections to taking LOM out of the base
>> > spec to move it to another document.
>> 
>> I believe Sanjay objected, 

I am sure will hear from Sanjay soon, but quoting from his email:
>> 	I am not against moving the LOM feature into its own draft, 
Doesn't sound like an objection to me.

So I think it is fair to say that noone has expressed any objection (at
this stage anyway).

>>and I think he made a good point. 
>>  Either we should agree to drop LOM completely (no 'separate 
>> document' and/or Experimental track for LOM), or leave it 
>> in.  If it is progressed as a separate document/Experimental 
>> track, this would complicate backward compatibility for all 
>> the BC models.
>>

Whether we keep the text on LOM distributed over -proto, -russian, -mam
(and perhaps in MAR if you have added that in) as it is today or whether
we redistribute it into a single standalone document does not affect
backward compatibility. We're only talking about redistributing the same
text in a different set of documents so we can make one document
Experimental.
  
>> > Based on this, unless we hear different opinions shortly, 
>> my proposal
>> > will be to:
>> > 	- issue the next versions of -proto, -russian and -mam without
>> > LOM, so these can go to IESG Last Call promptly (Standards 
>> for -proto,
>> > Experimental for -russian and -mam)
>> 
>> Wai Sum and I have already expressed a different opinion in 
>> the proposed re-definition of LOM.  Before we agree to drop 
>> the LOM feature, we'd like to see some discussion on the 
>> alternative proposal to simplify the rather complicated 
>> 3-way approach to overbooking that now exists.  See below.

The current approach is NOT complicated. Please see the specific email
on this. 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.

>> 
>> You've also forgotten to mention -mar in the above.
>> 
>> > 	- issue a separate document (-lom) on LOM which can be
>> > progressed in Experimental track.
>> 
>> As above, I'm against a separate Experimental track for LOM, 
>> because this would complicate backward compatibility for all 
>> the BC models.  Otherwise, we need to explain how LOM can be 
>> introduced into the BC models later on, and avoid a 
>> transition/interoperability problem.  It seems that with the 
>> proposed separate track, LOM is functionally dead, but not 
>> officially dead.  I think we should either officially kill 
>> LOM, or retain it (but perhaps re-defined).
>>  

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 concensus to drop LOM altogether (that would
work for me)?

Cheers

Francois

>> > Please let me know if you have concerns with this proposal.
>> 
>> Yes, 2 concerns:
>> 
>> 1. As above, if LOM is progressed separately, we need to 
>> explain how LOM can be introduced into the BC models later 
>> on, and avoid a transition/interoperability problem.  I 
>> think it would be preferable to officially kill LOM, rather 
>> than leave it in the proposed 'separate track'.
>> 
>> 2. Before we agree to drop the LOM feature, we'd like to see 
>> some discussion on the alternative proposal to redefine LOM 
>> (to LOM'), in order to simplify the rather complicated 3-way 
>> approach to overbooking that now exists:
>> 
>> LSPOMc = LSP overbooking multiplier for CTc
>> LSOM = link size overbooking multiplier
>> LOMc = local overbooking multiplier for CTc
>> 
>> If LOM is retained, Wai Sum and I propose to redefine LOM 
>> (calling it LOM') to provide an overall simplification of 
>> this 3-way overbooking complexity, as follows.
>> 
>> Define:
>> 
>> LSPOMc = LSP overbooking multiplier for CTc
>> LSOM = link size overbooking multiplier
>> LSOM = maximum reservable bandwidth/maximum link bandwidth
>> LOMc = local overbooking multiplier for CTc (original 
>> definition of LOMc)
>> LOM'c = redefined local overbooking multiplier LOMc for CTc
>> LOM'c = LSOM * LSPOMc * LOMc
>> 
>> Given:
>> requested LSP CTc = RSVP-TE Tspec LSP bandwidth specified in TLV
>> 
>> Then the following general equation applies:
>> reserved CTc = requested LSP CTc/LOM'c                       (1)
>> 
>> wherein there are several cases of equation (1) for reserved CTc:
>> 
>> 1. Link Size Overbooking only:
>>     LSPOMc = 1, LOMc = 1, for all c
>>     LOM'c = LSOM, or equivalently
>>     reserved CTc = requested LSP CTc/LSOM = requested LSP CTc/LOM'c
>> 2. LSP Size Overbooking only:
>>     LSOM = 1, LOMc = 1, for all c
>>     LOM'c = LSPOMc for all c, or equivalently
>>     reserved CTc = requested LSP CTc/LSPOMc = requested LSP CTc/LOM'c
>> 3. Both Link Size Overbooking and LSP Size Overbooking:
>>     LOMc = 1, for all c
>>     LOM'c = LSOM * LSPOMc, or equivalently
>>     reserved CTc = requested LSP CTc/(LSOM * LSPOMc) = 
>> requested LSP CTc/LOM'c
>>  4. LOM in conjunction with the above cases 1, 2, or 3
>>     reserved CTc = requested LSP CTc/LOM'c
>> 
>> In this model, the aggregate constraint becomes:
>> 
>>  o SUM (Reserved(CTc)) <= MLBW                               (2)
>>      for all "c" in the range 0 <= c <= (MaxCT-1)
>> 
>> We believe that this simplification, as summarized in 
>> equations (1) and (2) above, is worthwhile if LOM is retained.
>> 
>> Thanks,
>> Jerry & Wai Sum
>>