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

I agree with Francois and Dimitry.

Thanks,
Siva

At 12:00 PM 6/2/2003 -0400, Dimitry Haskin wrote:
>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
> > >>
> >