[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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, 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.
> 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.
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).
> 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