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

I agree with Francois. Let's remove LOM from the base spec and not to
venture on another round of unnecessary redefinitions of the base spec.

As a side note, I would not be too upset if no separate LOM spec follows any
soon. I'd let someone who feels that there is a real practical need for LOM
to pick up the LOM torch.

Dimitry

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email protected]]
> Sent: Monday, June 02, 2003 9:02 AM
> To: Ash, Gerald R (Jerry), ALABS; [email protected]
> Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
> method from
> DS-TE specs?
> 
> 
> Jerry,
> 
> >> -----Original Message-----
> >> From: Ash, Gerald R (Jerry), ALABS [mailto:[email protected]] 
> >> Sent: 02 June 2003 14:02
> >> To: Francois Le Faucheur (flefauch); [email protected]
> >> 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
> >> 
>