[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt



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
>