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

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Sun, 1 Jun 2003 18:58:42 -0500

All,

I'm not sure where we stand on keeping LOM or dropping LOM.

If we keep LOM, it is possible to re-define LOM so as 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.

Comments welcome.

Thanks,
Jerry & Wai Sum

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 2 Jun 2003 09:47:23 +0100

Hello Sanjaya,

>> > For the record, the DSTE-REQTS spec does not define 
>> requirements for
>> > implementation/vendors. It defines requirements for the ds-te 
>> > solution.
>> 
>> 	Missed "DSTE-PROTO" before the "and" in the original e-mail.
>> 	Anyway, DSTE-REQ calls out for the solution draft to optionally
>> 	support ability to tweak the overbooking factor of a CT in 
>> 	different parts of the network. DSTE-PROTO already provides a 
>> 	solution for this (as an optional feature). 
>> 
>> 	I am not against moving the LOM feature into its own draft, 

Noted.

>>but
>> 	I fail to understand: What good does it do, to remove the 
>> 	(already optional) LOM feature from the base spec? 
>> 

To me the main benefits are:
	- make the DS-TE core specifications simpler (to read,
implement, deploy) and thus maximise its chances of sucessful deployment
	- would allow us to progress LOM in the "Experimental" track,
which I think matches better the TEWG feel (ie something that may or may
not be useful and where experience will tell).

>> 	If we move the LOM into its own draft, do the BC model drafts 
>> 	still need to ensure that the model still works when LOM is in
>> 	use? Or do we need more drafts to extend the BC model drafts?
>> 

My proposal would be that the single LOM draft discusses (i) the concept
of LOMs, (ii) the BC-model-independent aspects of LOMs (eg. IGP
extensions, applying constraints to Normalised vs Reserved) and (iii)
the BC-model-specific aspects (eg take the CAC/Unreserved-Bw formuals
that are currently in -russian and -mam ). So I think a single draft
could cover all the aspects of LOM. Again, that is a good property o
LOM, it has been defined as a pure "increment" of LSP/Size overbooking
and is thus very easy to keep in or out.

>> 	An aside: DSTE basically provides a per-CT knob on the LSRs. 
>> 	And a per CT overbooking knob, might allow a provider 
>> to overbook
>> 	the data traffic on a link, without overbooking the real-time
>> 	traffic (on the same link) at the same level.
>> 

Yes, as discussed, there is quite a lot we can do without LOM.

Thanks

Francois

>> 	Thanks,
>> 	sanjay
>> 
>> > So, my interpretation of what its text says is just that the DS-TE
>> > solution should try to cope with the corresponding 
>> > requirement. In other
>> > words, to me, it is identified as an optional feature for the
>> > DSTE-solution (a feature that the DSTE solution should try 
>> > address, but
>> > may not address).
>> > 
>> > I really don't want to start a "DSTE-REQTS interpretation" 
>> > argument. The
>> > only reason I bring that up is to address your point 
>> below. ie I don't
>> > think the discussion we're having on taking LOM out of the 
>> base specs
>> > would require any change to the DSTE-REQTS document.
>> > 
>> > Note also that the proposal is just to take it out of the 
>> > base spec, not
>> > necessarily to drop it altogether (eg it could be documented 
>> > separately
>> > - perhaps as an experimetal RFC, like the BC Models). 
>> > 
>> > >> We already discussed the overbooking/underbooking issues
>> > >> quite some time back. I don't think we, should change
>> > >> requirement [DSTE-REQ] at this stage (past last call),
>> > >> unless there is a real problem or limitation.
>> > >> 
>> > >> If we are trying to change the requirement because the 
>> > >> LOM concept is difficult, 
>> > 
>> > I don't think the concern is that the LOM solution itself is too
>> > complicated for the given requirement or not understood. To 
>> > me it's more
>> > a question of saying: now that we understand the ratio between the
>> > functional benefit of the particular optional requirement and the
>> > complexity associated with it, do we actually think it is 
>> > worth keeping
>> > in the base spec?
>> > 
>> > Now, you may feel that indeed it is worth and that LOM 
>> should stay in
>> > base spec. But I wanted to be sure we were all looking at the same
>> > question, and you're not feeling LOM should stay in simply 
>> because you
>> > felt it is somehow mandated by the DSTE-REQTS.
>> > 
>> > Thanks
>> > 
>> > Francois
>> > 
>> > >>let's take steps to clarify
>> > >> the concept by necessary editorial changes (and examples).
>> > >> 
>> > >> Thanks,
>> > >> sanjay
>> > >> 
>> > >> > -----Original Message-----
>> > >> > From: Francois Le Faucheur (flefauch) 
>> [mailto:[email-masked]]
>> > >> > Sent: Monday, May 26, 2003 9:05 AM
>> > >> > To: [email-masked]
>> > >> > Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
>> > >> > method from
>> > >> > DS-TE specs?
>> > >> > 
>> > >> > 
>> > >> > All TEWGers,
>> > >> > 
>> > >> > Thoughts on dropping/keeping LOM in base DS-TE specs?
>> > >> > 
>> > >> > Thanks
>> > >> > 
>> > >> > Francois
>> > >> > 
>> > >> > >> -----Original Message-----
>> > >> > >> From: Francois Le Faucheur (flefauch) 
>> > >> > >> Sent: 26 May 2003 14:59
>> > >> > >> To: Kireeti Kompella; [email-masked]
>> > >> > >> Subject: Dropping the Local Overbooking Multiplier (LOM) 
>> > >> > >> method from DS-TE specs?
>> > >> > >> 
>> > >> > >> 
>> > >> > >> Kireeti,
>> > >> > >> 
>> > >> > >> Once upon a time, we merged 3 technical proposals for 
>> > >> DS-TE (one of
>> > >> > >> which was yours) into a common one. One of the 
>> > >> > capabilities that was
>> > >> > >> unique to your proposal was the ability to support 
>> > >> > overbooking ratios
>> > >> > >> which are different on a per CT AND per link basis 
>> > >> (while the other
>> > >> > >> methods supported different ratios on different links 
>> > >> and different
>> > >> > >> ratios on a per CT basis, not not on a per CT and per-link 
>> > >> > >> basis). Back
>> > >> > >> then you made a argument that there was some value in 
>> > >> > allowing this.
>> > >> > >> This resulted in the addition of the optional Local 
>> > Overbooking
>> > >> > >> Multiplier (LOM) method in the DS-TE specs.
>> > >> > >> 
>> > >> > >> A number of people commented that considering the ratio of 
>> > >> > >> complexity vs
>> > >> > >> functionality for this particular capability, we may be 
>> > >> better off
>> > >> > >> issueing the base DS-TE specs without this for now and 
>> > >> > then add this
>> > >> > >> capability later or in a separate document. I personnally 
>> > >> > also favors
>> > >> > >> such an approach.
>> > >> > >> 
>> > >> > >> What is your take on this?
>> > >> > >> 
>> > >> > >> Cheers
>> > >> > >> 
>> > >> > >> Francois
>> > >> > >> 
>> > >> > >> >> -----Original Message-----
>> > >> > >> >> From: Jim Boyle [mailto:[email-masked]] 
>> > >> > >> >> Sent: 24 May 2003 02:31
>> > >> > >> >> To: Francois Le Faucheur (flefauch)
>> > >> > >> >> Cc: [email-masked]; Lai, Wai S , ALABS
>> > >> > >> >> Subject: RE: Reflecting new-MAM/SAM definition in 
>> > >> > diff-te drafts 
>> > >> > >> >> 
>> > >> > >> >> 
>> > >> > >> <clip>
>> > >> > >> >> 
>> > >> > >> >> btw... I also think LOMs are lots of complexity for 
>> > >> > little gain :)
>> > >> > >> >> 
>> > >> > >> >> 
>> > >> > >> >> 
>> > >> > >> >> On Tue, 20 May 2003, Francois Le Faucheur 
>> (flefauch) wrote:
>> > >> > >> >> 
>> > >> > >> >> > Jerry,
>> > >> > >> >> > 
>> > >> > >> >> > >> -----Original Message-----
>> > >> > >> >> > >> From: Ash, Gerald R (Jerry), ALABS 
>> > >> [mailto:[email-masked]] 
>> > >> > >> >> > >> Sent: 20 May 2003 17:35
>> > >> > >> >> > >> To: Dimitry Haskin; Francois Le Faucheur (flefauch)
>> > >> > >> >> > >> Cc: Ash, Gerald R (Jerry), ALABS; 
>> > >> [email-masked]; Lai, 
>> > >> > >> >> > >> Wai S (Waisum), ALABS
>> > >> > >> >> > >> Subject: RE: Reflecting new-MAM/SAM definition in 
>> > >> > >> diff-te drafts
>> > >> > >> >> > >> 
>> > >> > >> >> > >> 
>> > >> > >> >> > >> Dimitry, Francois,
>> > >> > >> >> > >> 
>> > >> > >> >> > >> > >     o SUM (Reserved (CTc)) <= Max Reservable 
>> > >> > Bandwidth, 
>> > >> > >> >> > >> > > However, this formula is incorrect for DS-TE 
>> > >> > when per-CT 
>> > >> > >> >> > >> > > LOM's are used, since the above formula only 
>> > >> > >> >> reflects the Max 
>> > >> > >> >> > >> > > Reservable Bandwidth for the entire link, 
>> > >> and does not 
>> > >> > >> >> > >> > > reflect the per-CT local overbooking 
>> > >> factors.  So what 
>> > >> > >> >> > >> > > formula do you suggest when per-CT 
>> LOM's are used?
>> > >> > >> >> > >> 
>> > >> > >> >> > >> > Wouldn't 'Reserved (CTc)' it the above 
>> > >> formula already 
>> > >> > >> >> > >> accounts for the
>> > >> > >> >> > >> > overbooking multiplier at CTc?  I don't see 
>> > how this 
>> > >> > >> >> > >> formula precludes
>> > >> > >> >> > >> > per-CT LOM's to be used. Please explain.
>> > >> > >> >> > >> 
>> > >> > >> >> > >> Are you then proposing these formulas:
>> > >> > >> >> > >> 
>> > >> > >> >> > >> 1. When per-CT LOMs are not used:
>> > >> > >> >> > >> 
>> > >> > >> >> > >>      o SUM (Reserved(CTc)) <= Max Reservable 
>> > Bandwidth, 
>> > >> > >> >> > >> 2. When per-CT LOMs are used:
>> > >> > >> >> > >> 
>> > >> > >> >> > >>      o SUM (Normalized(CTc)) <= Max Reservable 
>> > >> Bandwidth, 
>> > >> > >> >> > >> Is that correct?  Please confirm, and/or give 
>> > >> the formulas 
>> > >> > >> >> > >> you propose.
>> > >> > >> >> > 
>> > >> > >> >> > Yes, this is exactly what I propose.
>> > >> > >> >> > I think this is similar to what you were 
>> proposing, only 
>> > >> > >> >> using "Max Res
>> > >> > >> >> > Bw" instead of "Max Link Bw". 
>> > >> > >> >> > 
>> > >> > >> >> > Sorry I didn't make that very clear before.
>> > >> > >> >> > 
>> > >> > >> >> > Cheers
>> > >> > >> >> > 
>> > >> > >> >> > FRancois
>> > >> > >> >> > 
>> > >> > >> >> > >> 
>> > >> > >> >> > >> Thanks,
>> > >> > >> >> > >> Jerry
>> > >> > >> >> > >> 
>> > >> > >> >> > 
>> > >> > >> >> > 
>> > >> > >> >> > 
>> > >> > >> >> > 
>> > >> > >> >> 
>> > >> > >> >> 
>> > >> > >> 
>> > >> > >> 
>> > >> > 
>> > >> 
>> > >> 
>> > 
>> 
>>

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 2 Jun 2003 10:26:36 +0100

All,

>> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
>> Sent: 02 June 2003 01:59
>> To: [email-masked]
>> Cc: Ash, Gerald R (Jerry), ALABS; Lai, Wai S (Waisum), ALABS

My perception is that, so far, :
	- a number of people have argued in favor of taking LOM out of
the base spec (incl Dimitry, Jerry, Siva, myself)
	- some people (I believe this includes Sanjaya) would have a
problem if the LOM work was completely "dropped", but would not have a
problem if LOM is documented in a seperate document. 
	- some people (eg Sandy) inquired about whether we could not
achieve the same net effect without LOM anyway, but now agree that,
while we can do quite a lot without LOM, it is not possible to
(accurately) meet the (debated) extra requirement.
	- noone has expressed objections to taking LOM out of the base
spec to move it to another document.

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)
	- issue a separate document (-lom) on LOM which can be
progressed in Experimental track.

Please let me know if you have concerns with this proposal.

Cheers

Francois

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Mon, 2 Jun 2003 07:01:34 -0500

Francois, All,

> no one has expressed objections to taking LOM out of the base

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.
 
> 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.

> 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:

Define:

Given:

Thanks,
Jerry & Wai Sum

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 2 Jun 2003 14:01:33 +0100

Jerry,

>> Sent: 02 June 2003 14:02
>> To: Francois Le Faucheur (flefauch); [email-masked]
>> I believe Sanjay objected, 

>> 	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.
  
>> 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.

>> 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

>> 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:
>> 
>> 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:
>> 
>> We believe that this simplification, as summarized in 
>> equations (1) and (2) above, is worthwhile if LOM is retained.
>> 
>> Thanks,
>> Jerry & Wai Sum
>>

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Mon, 2 Jun 2003 09:33:52 -0500

Francois, All,

> on this. 

That's your view, but I don't think it constitutes a proof of same :-)

> Note that its two main components (Link/Size Overbooking) are

I expected this comment, of course.  However, DS-TE is a *new* environment (CTs, BC models, etc.), and we should have the right to define things within that new environment.

However, so as to not drag this out, and come to closure, I'm OK to go with your proposed formulas, pending a final agreement on LOM (see below):

When LOM is NOT used (i.e. LOM[i]=1)
=================================================
o for each value of b in the range 0 <= b <= 7:
  Reserved (CTb) <= BCb,
o SUM (Reserved(CTc)) <= Max-Reservable-Bw,   
  where the SUM is across all values of c in the range 0 <= c <= 7

When LOM is used 
===============================
o for each value of b in the range 0 <= b <= 7:
  Normalized (CTb) <= BCb,
o SUM (Normalized(CTc)) <= Max-Reservable-Bw,   
  where the SUM is across all values of c in the range 0 <= c <= 7

"Unreserved TE-Class [i]" when LOM is NOT used (i.e. LOM[i]=1)
============================================================
MIN  [
[ BCc - SUM ( Reserved(CTc,q) ) ] for q <= p ,
[ Max_Reservable_Bw - SUM ( Reserved(CTb,q) ) ] for q <= p and 0 <= b <= 7,]
where:
TE-Class [i] <--> < CTc , preemption p>
in the configured TE-Class mapping.

"Unreserved TE-Class [i]" when LOM is used
==========================================
LOM(c) x MIN  [
[ BCc - SUM ( Normalized(CTb,q) ) ] for q <= p,
[ Max_Reservable_Bw - SUM ( Normalized(CTb,q) ) ] for q <= p and 0 <= b <= 7,]
where:
TE-Class [i] <--> < CTc , preemption p> 

> Do you feel there is rough consensus to drop LOM altogether (that would
> work for me)?

I have not seen anyone give an example of where LOM is needed.  Unless we see that, my preference would be to drop it.  LOM is a real parameter, and at present needs to be carried in the RSVP extensions for DS-TE.  It requires addition aggregation constraints in the BC models.

Considerations of per-CT and hi-speed vs. low-speed links can be easily accommodated, as I gave in an example by using just LSPOM and LSOM (see earlier post http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00314.html).  It seems like much more than enough flexibility to avoid any problems, without also further complication with LOM.  

Can anyone explain why LOM would be needed, and in particular, give a practical example of same?

It seems to have marginal value (I don't see anyone showing how it is needed, or really supporting it).  I think we can agree that simplification *will* be achieved if we eliminate LOM.

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 2 Jun 2003 16:18:48 +0100

Hello Jerry,

>> Sent: 02 June 2003 16:34

Absolutely right. 
Just like I would rather see statement saying that someone finds the
current model rather complicated as opposed to statement saying it is
rather complicated. 8^)

>> I expected this comment, of course.  However, DS-TE is a 
>> *new* environment (CTs, BC models, etc.), and we should have 
>> the right to define things within that new environment.
>> 
>> However, so as to not drag this out, and come to closure, 
>> I'm OK to go with your proposed formulas, pending a final 
>> agreement on LOM (see below):
>> 
>> 

Great. This should allow us to move ahead fast as soon as we make a
final call on what to do with LOM.

>> I have not seen anyone give an example of where LOM is 
>> needed.  Unless we see that, my preference would be to drop 
>> it.  LOM is a real parameter, and at present needs to be 
>> carried in the RSVP extensions for DS-TE.  It requires 
>> addition aggregation constraints in the BC models.
>> 
>> Considerations of per-CT and hi-speed vs. low-speed links 
>> can be easily accommodated, as I gave in an example by using 
>> just LSPOM and LSOM (see earlier post 
>> http://ops.ietf.org/lists/te-wg/te->> wg.2003/msg00314.html).  
>> It seems like much more than 
>> enough flexibility to avoid any problems, without also 
>> further complication with LOM.  
>> 
>> Can anyone explain why LOM would be needed, and in 
>> particular, give a practical example of same?
>> 
>> It seems to have marginal value (I don't see anyone showing 
>> how it is needed, or really supporting it).  I think we can 
>> agree that simplification *will* be achieved if we eliminate LOM.

We can certainly agree on that.

So let's see if we hear some justiication for LOM or not, and based on
that we can finalise decision (hopefully within a few days) firstly to
take LOM out of base specs, and secondly to drop altogether (or document
as Experimental).

Cheers

Francois

---

From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Date: Tue, 3 Jun 2003 18:27:45 -0500

All,

I had proposed earlier:

> Can anyone give a practical example of where LOM is needed? 
> Unless we see that, my preference would be to drop it.   

Since posting that, some examples have been given (on the list and privately) that perhaps illustrate how LOM can be used in practice.

Furthermore, based on the discussion so far:

1. many people support leaving LOM in because they're reluctant to give up the extra flexibility (even though they don't offer specific supporting examples).
2. many people feel that the LOM extension is very simple, therefore why the concern, just leave it there.

Also, I argued against having LOM progressed separately, I think that would just complicate matters, and leave the BC models, Proto extensions, etc. in a state of limbo (possible awaiting a LOM extension later).  I had argued to either keep LOM, or drop LOM, but not leave it in the 'in between' state.

Overall, I don't think the case has been made to drop LOM, and, given that, I believe the better option is to leave LOM as is and not progress it as a separate effort.

Thanks,
Jerry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 4 Jun 2003 14:11:12 +0100

Hello Sanjaya,

>> From: Choudhury, Sanjaya [mailto:[email-masked]] 
>> Sent: 03 June 2003 16:10
>> To: [email-masked]
>> Hi Francois, Jerry, All!
>> My first preference, would be to leave the DSTE-PROTO
>> as it is with the following changes:
>> 	(i)  replace the max_link_bw by max_reservable_bw
>> 	(ii) add some more text clarifying the LOM concept
>>

Understood.
 
>> If after another week of discussions, we are still at impasse,
>> my second preference would be to split the LOM text out of 
>> the DSTE-PROTO and make it its own draft. 

Noted.
Unless the people who expressed first preference for taking LOM out of
base spec get convinced to change their mind soon, it seems likely we
won't all agree on our first preference. So this seems to me like a
likely avenue.

>>I do have serious 
>> reservations about the second approach, because we are just 
>> deferring the problem and not addressing the issue.
>> 
>> Now, lets examine the issues in little more detail::-
>> 
>> As of now, I have heard the following concerns about the 
>> LOM concept (as presented in the DSTE-PROTO):
>> 
>> 	Issue-1: LOM is a complex concept.
>> 	Issue-2: LOM makes DSTE-PROTO difficult to read
>> 	Issue-3: LOM is difficult to implement
>> 	Issue-4: LOM is difficult to deploy
>> 	Issue-5: We don't know if LOM is a useful concept
>>

I agree that neither of these issues individually is unsurmountable. 
But the real issue to consider seems rather that the ratio between the
extra functionality and the extra complexity is very high (not so much
because the extra complexity is high but mainly because the extra
functionality appears very low).

Another way to consider this question is the following. 
A general principle we've followed for the dste-proto is to only specify
protocol extensions necessary in order to carry all of, but no more
than, the mechanisms that exist in regular TE and make them work in the
presence of multiple CTs. I very much support that principle : make it
only as complicated as necessary to support multiple CTs, but no more.
As you've mentioned below, this is precisely the case for Link Size
Overbooking and LSP Size Overbooking. We only did what we had to do to
make these concepts from regular TE work with multiple CTs.
The one exception is LOM which is more like doing something beyond what
already exists in regular TE. Now all principles can be broken, but I
would expect a stronger case in terms of requirement to justify doing
so. 

I won't comment on your discussion of the individual issues below
because, as I said, the more relevant question is their combined
trade-off. I will just mention one thing relating to your issue 5 (which
I think is similar to Dimitry's point): of course we want to be able to
do per-CT overbooking. But this is in no way a justification for LOM.
You can do per-CT overbooking perfectly well without LOM. Again, the
only thing you cannot do is enforce an overbooking ratio which is
differnet on a per link and per CT basis. But you can certainly have
different overbooking ratios per CT and simultaneously have different
overbooking ratios per link. 
The meaningful formation here would be to hear if Service Providers feel
that being able to "simultaneously enforce different overbooking ratios
per CT and different overbooking ratios per link" may not be sufficient
for their environment and that different overbooking ratios per-CT AND
per-link are required. 

Thanks again for your thoughts.

Francois
 
>> Here are my take on these issues::-
>> 
>> Issue-1:: In my opinion the LOM concept is the _least_
>> complex part of DSTE-PROTO. I think, people are confused
>> by the mechanics behind the co-existence of LOM, with the 
>> two *legacy* overbooking techniques.
>> 
>> DSTE-PROTO did not introduce the concept of "LSP Size
>> Overbooking" or "Link Size Overbooking". 
>> It just (i) gave formal name to the existing techniques
>> and (ii) ensured that the new LOM co-exists with the 
>> existing overbooking approaches.
>> 
>> The above mentioned existing overbooking techniques work
>> in existing non-DSTE networks (and will continue to work
>> in DSTE domains).
>> 
>> =>We can address this issue, by adding some clarifying text.
>> 
>> Issue-2:: DSTE is all about, providing per-CT BW control to
>> the network administrator. I think it makes the solution 
>> more complete by leaving the LOM text in.
>> 
>> =>We can easily solve the readability problem by adding
>> some clarifying text [will it be useful, if I propose some
>> text in this section?]
>> 
>> Issues-3:: I can't tell for others, but personally I think 
>> it is not a difficult feature to implement. After all, it
>> is just a multiplier!
>> 
>> =>Vendors don't have to implement it, if they think it is
>> difficult to implement the concept.
>> 
>> Issue-4:: When fine grained BW optimization is needed, 
>> the administrator will use the per-CT BW controls 
>> provided by the DSTE-PROTO. When dealing with a per-CT
>> level BW control, it is more natural to expect a per-CT
>> overbooking factor. After all, providers are used to
>> per-CoS overbooking concepts from their experience with
>> ATM.
>> 
>> =>DSTE-PROTO does not force all users to use the LOM 
>> concept, but provides enough per-CT control for the 
>> interested users.
>> 
>> Issue-5: I think per-CT overbooking solution (LOM) can 
>> be a useful tool the network administrators. It complements
>> the existing overbooking techniques, seamlessly.
>> 
>> 	-When the administrator has decided to deploy DSTE, 
>> 	obviously, he wants per-CT BW control. It is only 
>> 	natural to expect a per-CT overbooking knob 
>> 
>> 	-Consider a situation, where the administrator wants
>> 	to overbook his data traffic, but does not want to
>> 	overbook the voice traffic on the link. In this case
>> 	max_reservable_bw knob is too coarse to be used. LOM
>> 	can aid with this configuration.
>> 
>> 	-In the past, some of the providers have indicated
>> 	their plans to use per CoS overbooking techniques.
>> 
>> 
>> Thanks,
>> sanjay
>> 
>> 
>>  
>> 
>> 
>> 
>> 
>> > From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
>> > Sent: Monday, June 02, 2003 11:19 AM
>> > To: Ash, Gerald R (Jerry), ALABS; [email-masked]

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 4 Jun 2003 14:29:09 +0100

Jerry,

>> Sent: 04 June 2003 01:28
>> Cc: Ash, Gerald R (Jerry), ALABS; Francois Le Faucheur 
>> (flefauch); Lai, Wai S (Waisum), ALABS
>> Since posting that, some examples have been given (on the 
>> list and privately) that perhaps illustrate how LOM can be 
>> used in practice.

Hm, I haven't seen a single example. What did I miss?

Sanjaya's message made the point that it is a common requirement to want
to do per-CT overbooking. This is not a justification for LOM as per-CT
overbooking can be done with LSP Size Overbooking.

Did my spam filter inadvertently trashed messages on the list?
Also, it is hard to take into examples communicated privately unless you
can share those with us?

Cheers

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 4 Jun 2003 14:49:30 +0100

Jerry,

>> Also, I argued against having LOM progressed separately, I 
>> think that would just complicate matters, and leave the BC 
>> models, Proto extensions, etc. in a state of limbo (possible 
>> awaiting a LOM extension later).  I had argued to either 
>> keep LOM, or drop LOM, but not leave it in the 'in between' state.

I'd like to come back to your point above because:
	- (i) it is a concern that Sanjaya also expressed
	- (ii) I think we can find a way which does not leave things
more in a limbo than keeping it in as an option
	- (iii) I have the impression that putting LOM in an
Experimental draft is a solution that everybody else could probably
leave with (even if not their first choice) so this may be a way to get
out of the "impasse". Ie it is the second choice of people who favor
keeping LOM in the spec and of those who favor dropping LOM altogether.

We could basically take the exact same text that is currently spread
over -proto, -mam, -russian (and perhaps -mar if you've put some in
there) and group it into this new -LOM draft. So frankly, it terms of
how things are specified to work it would just be perfectly equivalent.
If your concern is that MAR may get left out, we could work on that,
perhaps try to work together on a section for the MAR-specific LOM
aspects (just like there would be a russian-specific and mam-specific
section cut-and-pasted from -russian and -mam).

The only real difference in making the same text appears in Exeprimental
draft is really to say that the TEWG would like to get more live
experience on DS-TE before deciding whether this should make Standards
Track or not. This seems to perfectly reflect the situation.
We've made the same decision for RDM, MAM and MAR: we've made them
Experimental to indicate that we needed more experience to decide which
one should become Standards.
I can't see that LOM is less Experimental than some of the BC models ^)

If we go that way, could you not live with LOM as Experimental?

Thanks

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 4 Jun 2003 15:05:13 +0100

Sanjay,

>> > 
>> > Overall, I don't think the case has been made to drop LOM, 
>> 
>>   Personally, I agree with this view [given that LOM is already
>>   an optional feature]
>>

Fair enough. 
Now at the same time we have a number of people (Siva, I believe Dimitry
and Siva) who indicated preference for dropping LOM. So I'm trying to
find out something we can agree on. Which is why I am folloiwng up on
your "second choice" in my other email 8^)

Cheers

Francois