[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!
> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
> Sent: Wednesday, May 28, 2003 12:31 PM
> To: Choudhury, Sanjaya; te-wg@ops.ietf.org
> Subject: RE: Dropping the Local Overbooking Multiplier (LOM)
> method from
> DS-TE specs?
>
>
> Hello Sanjaya,
>
> >> -----Original Message-----
> >> From: Choudhury, Sanjaya [mailto:Sanjaya.Choudhury@marconi.com]
> >> Sent: 28 May 2003 16:35
> >> To: te-wg@ops.ietf.org
> >> Subject: RE: Dropping the Local Overbooking Multiplier (LOM)
> >> method from DS-TE specs?
> >>
> >>
> >> Hi! DSTE-REQ already states that the per-CT overbooking
> >> is an optional feature and does not require the vendors
> >> to implement it.
> >>
>
> 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, but
I fail to understand: What good does it do, to remove the
(already optional) LOM feature from the base spec?
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?
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.
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:flefauch@cisco.com]
> >> > Sent: Monday, May 26, 2003 9:05 AM
> >> > To: te-wg@ops.ietf.org
> >> > 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; te-wg@ops.ietf.org
> >> > >> 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:jboyle@pdnets.com]
> >> > >> >> Sent: 24 May 2003 02:31
> >> > >> >> To: Francois Le Faucheur (flefauch)
> >> > >> >> Cc: te-wg@ops.ietf.org; 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:gash@att.com]
> >> > >> >> > >> Sent: 20 May 2003 17:35
> >> > >> >> > >> To: Dimitry Haskin; Francois Le Faucheur (flefauch)
> >> > >> >> > >> Cc: Ash, Gerald R (Jerry), ALABS;
> >> te-wg@ops.ietf.org; 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,
> >> > >> >> > >> > > for all "c" in the range 0 <= c
> <= (MaxCT-1)
> >> > >> >> > >> > >
> >> > >> >> > >> > > 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,
> >> > >> >> > >> for all "c" in the range 0 <= c <= (MaxCT-1)
> >> > >> >> > >>
> >> > >> >> > >> 2. When per-CT LOMs are used:
> >> > >> >> > >>
> >> > >> >> > >> o SUM (Normalized(CTc)) <= Max Reservable
> >> Bandwidth,
> >> > >> >> > >> for all "c" in the range 0 <= c <= (MaxCT-1)
> >> > >> >> > >>
> >> > >> >> > >> 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
> >> > >> >> > >>
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >>
> >> > >> >>
> >> > >>
> >> > >>
> >> >
> >>
> >>
>