[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
Francois,
Sorry for my delayed response, as I just got back from vacation.
Thanks for rewording "normal" and "overload" to reflect LSP
setup. It's a good suggestion. I think changing "works well"
as I defined below to mean only "efficient use" would leave out
significant aspects of overall network operation. This same
comment applies also to Jim's suggestion of
"(5) maximizes efficient use of the network."
For example, the impact of one service on another would not
be adequately covered. I prefer my original wording, as I
think it implies efficiency under this and other conditions.
The effect of coupling in BC and their interlocking impact on
the network's capability to set up LSPs for different services
will be expounded in my draft.
Thanks, Wai Sum.
-----Original Message-----
From: Francois Le Faucheur [mailto:flefauch@cisco.com]
Sent: Thursday, June 06, 2002 1:28 PM
To: Lai, Wai S (Waisum), ALASO
Cc: Francois Le Faucheur; Jim Boyle; Ash, Gerald R (Jerry), ALASO;
te-wg@ops.ietf.org
Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
Waisum,
At 17:14 05/06/2002 -0400, Lai, Wai S (Waisum), ALASO wrote:
>Francois,
> Your first two comments are fine. Regarding your comments on
>(2) works well under both normal and overload conditions,
>I do NOT mean "when there is contention across CTs" in the way
>you described.
>
>By "normal condition," I mean the network is carrying traffic
>at a level that it is designed to support.
>
>There will always be contention even under normal conditions,
>because of the stochastic nature of traffic flows, i.e., the
>fluctuating activities of establishment and teardown of LSPs
>(otherwise, why do we need to define preemption priority in
>the first place).
>Perhaps adding some text as follows may be suseful.
>Thaks, Wai Sum.
>
>"Normal condition" means the network is carrying traffic
>at a level that it is designed to support.
>"Overload condition" means that the network is carrying traffic
>higher than its normal level.
>"Works well" means that under these conditions, the
>network should be able to sustain the expected performance,
>e.g., under overload it is x times worse than its normal
>performance.
I think I understand what you mean now.
It is not completetly clear to me how that would translate into an
evaluation criteria for BC models, but I think the general idea is
reasonable so I have no objection to adding something along those lines.
Additional suggestions on wording:
1)How about :
"Normal condition" means that the network is attempting to establish a
volume of DS-TE LSPs for which it is designed.
"Overload condition" means that the network is attempting to establish a
volume of DS-TE LSPs beyond the the one it is designed for.
(to me "carrying traffic" can be easily misunderstood as relating to the
actual amount of packets transmitted , when here we are more focusing on
the amount of tunnels versus what can be setup)
2)"Works well":
Personnaly I think the above definition for "works well" is trying to be
too precise this time (it begs questions as to what sort of
"performance" ,
can the BC Model itself control that ..). I would suggest again
replacing
"works well" by something like "maintain efficient use of the network
both
under normal condition and Overload condition".
("efficient use of the network " is something we use as an other
evaluation
criteria. Here we just want to make the point that this applies both
under
normal AND overload conditions.)
So, altogether, it would read:
"
(2) maintain efficient use of the network both under Normal Condition
and
Overload Condition".
"Normal condition" means that the network is attempting to establish a
volume of DS-TE LSPs for which it is designed.
"Overload condition" means that the network is attempting to establish a
volume of DS-TE LSPs beyond the one it is designed for.
"
What do you think?
Francois
>-----Original Message-----
>From: Francois Le Faucheur [mailto:flefauch@cisco.com]
>Sent: Wednesday, June 05, 2002 11:39 AM
>To: Jim Boyle
>Cc: Lai, Wai S (Waisum), ALASO; Ash, Gerald R (Jerry), ALASO;
>te-wg@ops.ietf.org
>Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
>
>
>Jim, Waisum,
>
>At 09:44 05/06/2002 -0400, Jim Boyle wrote:
>
> >Well, it's seems long-winded, but I suppose I can go along with that.
> >
> >Let's remove the reference, and add:
> >
> >(5) maximizes efficient use of the network.
> >
> >Is the WG ok with that?
>
>I am OK with Jim's proposal. A few small comments/suggestions embedded
>below inside Waisum's initial proposal.
>
>Francois
>
>
> > Waisum - would that be a workable compromise?
> >
> >Jim
> >
> >On Wed, 5 Jun 2002, Lai, Wai S (Waisum), ALASO wrote:
> >
> > > Jim,
> > > Per your request, here is the proposed text to replace the last
> > > but one paragraph of Section 3.3. Comments are welcome.
> > > Thanks, Wai Sum.
> > >
> > > At the time of writing this document, it is not clear whether a
> > > single model of Bandwidth Constraints is sufficient, which one it
> > > should be and how flexible this model really needs to be and what
> > > are the implications on the DS-TE technical solution and its
> > > implementations. Work is currently in progress [Reference] to
> > > investigate the performance and trade-offs of the different
> > > operational aspects of Bandwidth Constraints
>
>Should we not replace "Bandwidth Constraints" by "Bandwidth Constraints
>models"?
>
> >. For example,
> > > preliminary results indicate that the use of a higher degree of
> > > bandwidth sharing among different services
> >can lead to a tighter
> > > coupling among them, which can result in the impact of one service
> > > on another.
>
>
>Should we not replace "services" by "Class-Types" in the two occurances
>above?
>
>
> >Another preliminary observation is that there is the
> > > need to balance overall efficiency and the avoidance of starvation
> > > of any one service. These factors should be considered in the
> > > deployment of any bandwidth constraint model.
> > >
> > > The DS-TE technical solution must specify one
> > > default bandwidth constraint model which must be supported by any
> > > DS-TE implementation. Having a default bandwidth constraint model
> > > allows for the network administrator to have at least one
> > > consistent behavior when working with multiple implementations of
> > > DS-TE. Additional bandwidth constraint models may also be
>specified.
> > > In the selection of a default model, at least the following
criteria
> > > must be considered:
> > > (1) addresses the scenarios in Section 2
> > > (2) works well under both normal and overload conditions
>
>I am not comfortable with that statement:
> - not sure what "works well" means.
> - not sure what is "overload conditions" in this context. I
>guess
>this means "when there is contention across CTs, right?
>
>If I understand correctly, perhaps we could rephrase into something
>like:
>"(2) addresses both the cases where CTs are contending against one
>another
>for bandwidth reservation and the cases where CTs are not contending
>against one another".
>
>If you mean something differnet, could you clarify?
>
> > > (3) applies equally when preemption is either enabled or disabled
> > > (4) minimizes signaling load processing requirements
> > >
> > > [Reference] W.S. Lai, "Performance evaluation of bandwidth
>allocation
> > > models for Diffserv-aware MPLS traffic engineering,"
>Internet-Draft,
> > > June 2002.
> > >
> > > -----Original Message-----
> > > From: Jim Boyle [mailto:jboyle@pdnets.com]
> > > Sent: Tuesday, June 04, 2002 3:00 PM
> > > To: Lai, Wai S (Waisum), ALASO
> > > Cc: Ash, Gerald R (Jerry), ALASO; te-wg@ops.ietf.org
> > > Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
> > >
> > >
> > >
> > > You're text does not make it "clear" to me.
> > >
> > > Can you propose some text which captures what you see as objective
> > > criteria?
> > >
> > > My pass would be to add a sentence at the end of the paragraph
such
>as:
> > >
> > > "The default bandwidth model should be one that can address the
> > > scenarios
> > > in section 2 in a manner which balances bandwidth efficiency as
well
>as
> > > signaling overhead."
> > >
> > > I'm not sure if that will allow us to converge on a model, but at
>least
> > > it
> > > specifies some objective criteria to judge different models by.
>Plus,
> > > with just one sentence and no value statements on models as you
had
> > > previously suggested, I think we can add it in and progress the
>draft.
> > >
> > > Does this sound ok?
> > >
> > > Jim
> > >
> > > On Tue, 4 Jun 2002, Lai, Wai S (Waisum), ALASO wrote:
> > >
> > > > Jim,
> > > > I think our proposal to add some text in the requirements doc
>for
> > > > BC model is in the same spirit as in Section 4 "Solution
>Evaluation
> > > > Criteria" of this document for solutions supporting DS-TE.
> > > >
> > > > Let me quote again the paragraph in question:
> > > > "At the time of writing this document, it is not clear
whether
>a
> > > > single model of Bandwidth Constraints is sufficient, which
one
>it
> > > > should be and how flexible this model really needs to be and
>what
> > > > are the implications on the DS-TE technical solution and its
> > > > implementations. The DS-TE technical solution must specify
one
> > > > default bandwidth constraint model which must be supported
by
>any
> > > > DS-TE implementation."
> > > >
> > > > Regarding the first sentence, we have now some new information
>on
> > > the
> > > > implications of the BC models, which is contrary to what is
stated
>as
> > > > "it is not clear".
> > > >
> > > > More importantly, the second sentence in above text only says
>that
> > > > one default needs to be specified *without going into the
specific
> > > > selection criteria*. We believe that some criteria to be
>considered
> > > > include at least:
> > > > (1) performance under normal conditions versus service
protection
> > > > and isolation capability under overload (as stated in my
>previous
> > > > email)
> > > > (2) signaling load processing requirements (as stated in the
email
>by
> > > > Rudiger Geib)
> > > >
> > > > As I explicitly stated in my previous email, we fully agree
that
>the
> > > > requirements doc is not the place to resolve what the default
>model
> > > > should be. Thus, we have no objection to continuing this
>discussion
> > > > in the context of draft-ietf-tewg-diff-te-proto-00.txt, but see
a
> > > > need/value in identifying criteria and referencing relevant
>studies
> > > > in the requirements document.
> > > >
> > > > Thanks, Wai Sum.
> > > >
> > > > -----Original Message-----
> > > > From: Jim Boyle [mailto:jboyle@pdnets.com]
> > > > Sent: Monday, June 03, 2002 10:15 AM
> > > > To: Ash, Gerald R (Jerry), ALASO
> > > > Cc: Lai, Wai S (Waisum), ALASO; te-wg@ops.ietf.org
> > > > Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
> > > >
> > > >
> > > >
> > > > Jerry - it is already specified in the requirements document
that
>the
> > > > bandwidth constraint model must be specified in the technical
>solution
> > > > document:
> > > >
> > > > "The DS-TE technical solution must specify one
> > > > default bandwidth constraint model which must be supported by
>any
> > > > DS-TE implementation"
> > > >
> > > > How = IETF process, Where = TEWG. Do we really need to state
>that?
> > > >
> > > > As for making comparisons between models in the draft, I don't
>think
> > > > it's
> > > > called for. I think making references to documents which
describe
> > > them
> > > > is
> > > > also something that isn't necessary in the requirements
document.
>As
> > > > for
> > > > adding some text as to the decision must be made on "hard
>information"
> > > -
> > > > I
> > > > see that as a no-value addition to the document.
> > > >
> > > > What objection do you and Wai have to having this discussion in
>the
> > > > context of draft-ietf-tewg-diff-te-proto-00.txt ?
> > > >
> > > > Jim
> > > >
> > > > On Mon, 3 Jun 2002, Ash, Gerald R (Jerry), ALASO wrote:
> > > >
> > > > > > The discussion on what should be the default bandwidth
>constraint
> > > > > > model should be done in the context of the solution draft.
> > > > >
> > > > > This should be stated as a requirement in Section 3.3 of the
> > > > requirements draft.
> > > > >
> > > > > > The paragraph you quote makes it clear that the requirements
>draft
> > > > leaves that
> > > > > > discussion squarely with the technical solution.
> > > > >
> > > > > Nowhere in Section 3.3 of the requirements draft is it stated
>how or
> > > > where the technical solution will be decided. It should be
stated
>as
> > > a
> > > > requirement in Section 3.3 that "the default BC model will be
>decided
> > > in
> > > > the context of the technical solution draft."
> > > > >
> > > > > > I don't see a need for any text revision of the requirements
>draft
> > > > before
> > > > > > sending it on to the IESG.
> > > > > > Anyone else have any comment?
> > > > >
> > > > > Yes. An additional requirement should be added in Section
3.3:
> > > > > "the default BC model must be based on available hard
>information,
> > > > such as analysis given in [forthcoming lai-id] [other relevant
> > > > references]."
> > > > >
> > > > > Also, Wai Sum's suggested short explanation of the essence of
>his
> > > > analysis is highly relevant to Section 3.3, and shouldn't be
>rejected
> > > > out of hand.
> > > > >
> > > > > Jerry
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >