[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Dropping the Local Overbooking Multiplier (LOM) method from DS-TE specs?
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: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
>> > >> > >> >> > >>
>> > >> > >> >> >
>> > >> > >> >> >
>> > >> > >> >> >
>> > >> > >> >> >
>> > >> > >> >>
>> > >> > >> >>
>> > >> > >>
>> > >> > >>
>> > >> >
>> > >>
>> > >>
>> >
>>
>>