RE: Example of LOM usage

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

Francois, All,

> I think there is agreement that the fundamental theoretical reason why,
> ideally, one way want to have different per-CT overbooking ratios on
> different links is because a number of things don't grow linearly (like
> the erlang formula).
> Thanks for giving a quantified example illustrating the distortion.
> 
> But the input I am personally after is: are there service providers out
> there who are likely to be really after that level of 2nd order of
> optimization in the next few years? 

Wai Sum has given a good example of how/why LOM is needed, this is what we all were asking for in support of keeping LOM as is.  You call the effect '2nd order optimization', I don't think so, the differences can easily be above the 'tweaking threshold'.

> My impression is that it is
> interesting enough for an operator to try come up with the right
> formula/heuristics for factoring some LSP size overbooking and some Link
> size overbooking with a single class in regular TE today. When moving to
> DS-TE, operators will have to extend the formulas/heuristics for LSP
> size overbooking on a per-CT basis, so trying to factor it a second
> level of distortion via a per-CT-per-link overbooking tweak seems a far
> stretch in practice. Obviously, I could be wrong. But we still haven't
> heard an operator saying he is likely to be interested in that level of
> optimization for DS-TE.

Yes, you just heard a reasonable example of the need, from a SP who is likely interested in applying LOM as Wai Sum has illustrated.

> This is also discounting Dimitry's point, that operators could even do
> that without LOM anyway if they accepted to tolerate some inaccuracy on
> the aggregate constraint.

I'm a little baffled by this whole discussion.  A reasonable question was asked to provide justification for LOM.  In the ensuing discussion, most agreed that LOM is not complicated, and we have been given some reasonable examples of why/how it would be applied.  I see no reason to 'tolerate inaccuracy' if it is simple to avoid.

We've also agreed to progress LOM, either as is or 'split it off'.  There are still lots of questions surrounding the idea of splitting off LOM into a parallel effort.  Since LOM is already in the Proto spec, that is the easier option.  There does not seem to be a lot of justification now for splitting it off, especially given that its use has been illustrated.  Let's go with leaving it in, as is, and move on.

Also, I would observe that some aspects of the proposed 're-definition' of LOM, as described in http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00321.html, could be done within a given SP network without any changes to Proto or anything else.  All a SP needs to do is set LSPOM=1, LSOM=1.  Then

LOM'c = LSOM * LSPOMc * LOMc = LOMc

This would simplify the use of 3 types of overbooking in a SP network, would allow per-CT overbooking as well as per-link overbooking, and to me is a further justification to retain LOM as is.

Thanks,
Jerry