[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Review of draft-tewg-diff-te-reqts-06.txt
Bert and all,
>>
>> Can the authors and WG pls check and suggest answers
>> to the issues raised.
>>
Below are some thoughts and suggested resolution.
Cheers
Francois
=========================================================
>> It does not present "example applications scenarios
>> identified
>> by Service Providers" in my opinion.
Hmm. The text of section 3 was edited from text provided by the Service
Provider co-authors to describe what they are considering deploying and
what application they are trying to support. So, to me, to all the draft
co-authors, and I think to many people -if not the whole TEWG who passed
last call on this document- this does provide "example applications
scenarios identified by Service Providers".
>> there is no case made about how anyone is planning
>> a deployment.
A number of Service Providers co-authors contributed to this document
because they are considering/planning to deploy this.
The whole document is precisely a case that some SPs are
considering/planning deployment for this.
>>But, as relevance does not appear to be a
>> criterion for publication of Informational RFCs, I'll
>> move on to other concerns.
>>
Well, this is felt relevant by a number of Service Providers, which was
the essential consideration for progressing that document.
In any case, I agree that we don't need to discuss it any further and
can just "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.
Agreed.
This will be edited along the lines of replacing "need to/necessary" by
"may".
For example,
"... Diff-Serv mechanisms [DIFF-MPLS] need to be complemented by
existing MPLS Traffic Engineering mechanisms...".
Could be replaced by:
"... Diff-Serv mechanisms [DIFF-MPLS] may be complemented by existing
MPLS Traffic Engineering mechanisms...".
>>
>> 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.
Reference to the MPLS Architecture RFC will be added in the "Normative
Reference" list. It contains definition of FEC and other fundamental
MPLS concepts which are required for understanding of this document.
>>
>> There are a few tortured sentences, particularly the first
>> sentence of the second paragraph of section 1.3
1st sentence of 2nd paragraph of 1.3 is:
"
One option is to not split this set of <FEC/{TA}PSC> so that each
Traffic Trunk comprises traffic from all the {TA}/PSC .
"
Is this the sentence in question?
Is this really unaceptably tortured (considering the previous sentence
explains there are several options on how these things can be split)?
>>and last
>> sentence of first paragraph of section 3.3.
>>
Here is what I read:
"
The goal is to ensure all "guaranteed" traffic within a subscribed
traffic contract, will be delivered within stated tolerances."
I guess I must have a tortured mind because I can't quite see the
"torturedness"?
If it can make someone happier, all the enhancement I can suggest would
be:
"The goal is to ensure that all the "guaranteed" traffic under the scope
of a subscribed service level specification, will be delivered within
the tolerances of this service level specification."
Otherwise, I'll need specific suggestions.
>> 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.
>>
Some Service Providers are carrying part of their national PSTN traffic
over their packet network today. Voice VPN traffic is also transported
over the core. As migration of those continues, 10000 calls is felt as a
realistic order of magnitude for 1-3 year requirements.
But this text was provided by Thomas from Global Crossing, so Thomas may
want to add his view.
>> 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.
>>
I am not sure what is the specific concern/suggestion.
Effectively what we're trying to say is:
- VoIP load can be significant compared to link capacity
- some SPs feel that controlling the maximum load of VoIP on
all/some links is one of the tools that will help them control the level
of QoS [even if this document does not discuss the actual relationship
between (i) VoIP load, (ii) QoS levels and (iii) other factors including
type of scheduler]
To be able to address this I'd need to know whether:
- there is a disagreement that some SPs feel that way
- we are not phrasing the above clearly enough (specific
suggestions will help)
>> 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.
The trick is that PHBs have been complemented by the concept of PSC to
introduce the notion of "sharing a scheduling constraint". But PDBs have
not. So to be able to use this notion of "sharing a scheduling
constraint" we somehow have to refer to the PHB/PSC. But to address the
specific concern in this section, we can replace
"... running 4 Diff-Serv classes of services respectively based on
the EF
PHB [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e.
Best-Effort) PHB [DIFF-FIELD]. "
by:
"running 4 Diff-Serv classes of services whose {TA}PSCs are
respectively based on the EF
PHB [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e.
Best-Effort) PHB [DIFF-FIELD]. "
Note that section 1.2 already contains a definition for "class of
service" which uses the concept of TA:
"We also loosely refer to a {TA}PSC as a
Diff-Serv class of service, or class-of service."
(BTW, as a suggestion to the Diff-Serv WG, my impression is that this
{TA}PSC concept we're defining here, would actually be very handy in a
broader context as people are very often trying to refer to a "class of
service". Something like:
"
A Scheduling Aggregate: the set of TAs corresponding to the set of
PHBs of a
given PSC.
"
I wonder if this has/is/could been/be considered by the Diff-Serv WG)
>>
>> 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."
Well it contains the requirements to the level expressed by Service
Providers and it has provided us enough guidance to progress the DS-TE
protocol extensions to readiness for WG Last Call. Seems to fit the
bill.
Cheers
Francois