Review of draft-tewg-diff-te-reqts-06.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

First, I need to appologize, this review got done
quite a while ago, and I now found that I did not
forward it to the WG.
The good news: I have it on my radar again.

Kathie (DIFFSERV WG co-chair) has reviewed (at my
request) and has come up with these comments.
I am forwarding this with her permission.

Can the authors and WG pls check and suggest answers 
to the issues raised.

I am digging up more... which will follow soon.

Thanks,
Bert 

-----Original Message-----
From: Kathleen Nichols [mailto:nichols@packetdesign.com]
Sent: vrijdag 15 november 2002 2:08
To: Wijnen, Bert (Bert)
Cc: Scott Bradner (E-mail)
Subject: Re: Diffserv-aware Traffic Engineering




Wijnen, Bert (Bert) wrote:
> Could you (either yourslef or one of the DIFFSERV WG members)
> take a look at 
> 
>   draft-tewg-diff-te-reqts-06.txt
> 
> from a DIFFSERV point of view.
> 
> The TEWG has asked me to consider it for publication as 
> Informational RFC
> 
> Thanks,
> Bert 

I took a fairly quick view. I suppose I could say "mostly harmless"
but I do have a question of what the purpose of this document
is. That is, what light is it shedding on the Internet? It claims
in the abstract that it presents Service Provider requirements
for support of Diff-Serv aware MPLS Traffic Engineering. But
the "requirements" seem quite general. (I'm looking in
sections 4 and 5). On the other hand, Section 5 says that
some solutions may require that all current TE protocols syntax
be extended. This seems like off-handedly proposing a lot of
possible standards action. The paragraph at the bottom of page
9 is saying that a good deal of the model it is discussing has
not a clear needs case. So, at the high level, I'm wondering
why this document is being written now, what problem is it
solving. It does not present "example applications scenarios identified
by Service Providers" in my opinion. Its examples are very
general and there is no case made about how anyone is planning
a deployment. But, as relevance does not appear to be a
criterion for publication of Informational RFCs, I'll
move on to other concerns.

The third paragraph of section 1.1 states that "where optimization
of transmission resources is sought, Diff-Serv mechanisms [DIFF-
MPLS] need to be complemented by existing MPLS Traffic Engineering
mechanisms..." this in concert with the previous paragraph
seems to state that network-wide optimization of resources
*requires* MPLS. This is not a statement of fact, but of
opinion.

Near the end of section 3.2 there is a definition of "flows
of the same class" in terms of "Forwarding Equivalence Class"
which perhaps should be defined.

There are a few tortured sentences, particularly the first
sentence of the second paragraph of section 1.3 and last
sentence of first paragraph of section 3.3.

3.1, scenario 1, the example of 10,000 uncompressed calls
seems a bit specious. What grounding in reality does
that have? This is supposed to be giving requirements so
it seems the examples should not be merely illustrative.

3.1, second sentence. So I know how to determine the
"certain percentage" of VoIP traffic and it has to
do with a number of factors including the type of
scheduler in the forwarding path. But this sounds like
a lot of handwaving on the part of the authors.

Section 4.2: there seems to be some confusion of defining
a traffic class by the PHB it uses. This has been a problem
for a while and why the Diffserv WG did more work on defining
PDBs. A PHB is a mechanism and a bit low level to use to
define a traffic class.

My main concern is that the document does not meet its
stated objective of "to provide guidance for the definition,
selection and specification of a technical solution
addressing these requirements." The examples and discussion
are very "uncooked" and the document says so in itself.
I don't see that the introduction of more terminology is
needed at this point, but real documentation of real
problems and real solutions might be more useful.

	Kathie