[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Dropping the Local Overbooking Multiplier (LOM) method from DS-TE specs?
Hi!
comments in-line.
> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]
> Sent: Tuesday, June 03, 2003 7:28 PM
> To: te-wg@ops.ietf.org
> Cc: Ash, Gerald R (Jerry), ALABS; Francois Le Faucheur
> (flefauch); Lai,
> Wai S (Waisum), ALABS
> Subject: RE: Dropping the Local Overbooking Multiplier (LOM)
> method from
> DS-TE specs?
>
>
> 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.
And possibly a third category:
3. people who think the LOM extension is relatively simple
and think LOM has potential usage.
[On complexity issue : see my previous e-mail,
For specific example: see my previous e-mail on issues and
the e-mail response to Dimitry's e-mail]
>
> 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,
Personally, I agree with this view [given that LOM is already
an optional feature]
Thanks,
sanjay
> and, given that, I believe the better option is to leave LOM
> as is and not progress it as a separate effort.
>
> Thanks,
> Jerry
>