[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on draft-ietf-tewg-diff-te-reqts-06.txt
Bert,
Thanks for the thorough review.
Thanks also to ops-directorate reviewers.
Comments/proposed-resolution embedded below:
>> -----Original Message-----
>> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
>> Sent: 19 January 2003 19:32
>> To: Tewg (E-mail)
>> Subject: comments on draft-ietf-tewg-diff-te-reqts-06.txt
>>
>>
>> Mix of nits, admin comments, and serious comments
>>
>> - general... I find it difficult to extract the list of requirements
>> from your document. I think the last 2 lines of sect 4.3
>> for example
>> is one of the requirements. It also seems to me that the
>> 2nd and 6th
>> paragraphs on page 12 are requirments. The last sentence of the one
>> but last para on page 13 also seems a requirement... and so on.
>> Would it make sense to eitehr MARK them very clearly in the text,
>> or to sumamry them in a separate section?
Well, all the detailed requirements are grouped under section 4 and they
are all "marked" with a "must" (or "should/may"). Seems like a
reasonably clear way to present them.
There is some (non-requirement) text preceding the actual requirements
to provide background/definition for the formulation of the requirement.
I think it is best to keep all that together so one can understand the
requirements.
The reason we did not capitalise the "must/should/may" is that this
document is going for Informational track so we were not sure
MUST/SHOULD/MAY were appropriate. Sounds like they are, so we will
follow your suggestion and capitalize them.
>> - sect 1.1 says:
>> In other networks, where optimization of transmission resources is
>> sought, Diff-Serv mechanisms [DIFF-MPLS] need to be
>> complemented by
>> existing MPLS Traffic Engineering mechanisms [TE-REQ] [ISIS-TE]
>> [OSPF-TE] [RSVP-TE] [CR-LDP] which operate on an aggregate basis
>> I wonder about the "complemented by existing ... mechanisms"
>> Several of the references documents are still work-in-progress.
>> Would a s/existing/other/ be more appropriate?
Noted.
>> - sect 3.2 talks (two places) about "the order in which tunnels are
>> routed". What does that (ordering of tunnels) mean ?
Before being available, TE tunnels need to be established. This
establishment includes computing route for the tunnel and signaling
tunnel establishment (and thus reserving bandwidth). The order in which
these tunnels are established/routed can greatly affect which tunnels
can grab bandwidth and which cannot, and thus greatly affects the state
of the final system.
>> - what are thelast 2 paragraphs on page 7 trying to say?
>> sounds like blabla and handwaving to me, no?
They are trying to say something specific :
Some SPs would like to simultaneously:
- offer "Very High QoS Guaranteed Traffic" and "Normal Traffic"
- they want to do admission control of "Very High QoS Guaranteed
Traffic" to ensure it fits in the queue dedicated to that service
- they want to do regular TE of Normal traffic
This leads to the need for doing TE CAC on more than one Bandwidth pools
(which is what DS-TE is all about).
>> - sect 4. 1st sentence
>> s/implementations/techniques or protocols/ ??
Agreed. Since we already mention several times the "DS-TE solution" , we
could s/implementations/solution/
>> In other words... we are not mandating any "implementation" are we.
>> We are specifying functionality for (potential) DS-TE protocols are
>> we not?
>> - sect 4.2
>> Is the first sentence not a generic TE requirement and not specific
>> to DS-TE? Maybe I get confused since you did not define the term
>> "Traffic Trunc"
Section "1.2 Definitions" contains a definition for "Traffic Trunks".
>> - Is most of the text in sect 4.2 on page 9 not just another
>> scenario that belongs in sect 3?
We tried to keep things simple in the scenarios (eg only talked about
"classes of service"). The objectives of the scenarios is to give a
simple-to-grab understanding of what SPs want to do.
In section 4.2 we are trying to describe the relationship between CTs
and classes/PHBs. This requires more complex terminology and mapping
examples. Also, in section 4.2 we are not describing what application
the is trying to achieve, just how CTs may be "mapped".
>> - does the "criteria to be considered" on page 11 not belong in
>> section 5?
Agreed.
When updating the text of 4.2 about Default model, we will move the BC
Model criteria to section 5.
>> - On page 11 you reference [BC-MODEL] but it is not listed in the
>> references section I think.
Noted.
>> - Page 13. Maybe I just do not udnerstand... but it seems to me
>> that this text:
>>
>> The network administrator would then, in particular, NOT be able
>> to :
>> - transport a CT0 Traffic Trunk over an LSP with setup priority=1
>> and holding priority=1
>> - transport a CT1 Traffic Trunk over an LSP with setup priority=0
>> and holding priority=0
>>
>> Conflicts with the immediately following text:
>>
In the previous paragraph, it is important to note the word "then".
"Then" was intended to mean "in the case of the example CTs definition
which is given above". Given this "CT definition", the text is correct.
The paragraph below would require a differnet "CT definition".
>> DS-TE must allow two LSPs transporting Traffic Trunks
>> from different
>> Class-Types to use the same preemption priority. In
>> other words, the
>> DS-TE solution must allow TE-classes using different CTs
>> to use the
>> same preemption priority. This effectively allows the network
>> administrator to ensure that no preemption happens across Class-
>> Types, if so desired.
>>
>> As an example, the DS-TE solution must allow the network
>> administrator to define three Class-Types (CT0, CT1 and CT2) each
>> comprising one TE-Class which uses preemption 0. In that case, no
>> preemption will ever occur.
>>
>> Or do I indeed not understand?
>> - May I assume that all TE-WG members understand the
>> notations used in
>> section 4.5 ?? Cause I would have to go and study in detail if I
>> want to get it.
A definition for these terms is actually provided in section "1.2
Definitions".
>> - sect 4.6
>> I guess the reference to sect 2.2 should be to 3.2 ??
Right.
>> - The last 2 sentences of 1st para of sect 4.6 mean what?
>> Is it an "optional requirement" or is it "ou of scope" ??
>> if out of scope, then why is sect 4.6 present?
Yeah, a little confusing right now ^)
I propose to just specify it as optional and get rid of the "out of
scope" statement.
>> - sect 5.1 refers to sections 2 and 3, which I think should
>> respectively
>> be 3 and 4
Noted.
>> - The security considerations section seems very weak, see
>> underlined:
>>
>> The solution developed to address the requirements defined in this
>> document must address security aspects. DS-TE is not
>> expected to add
>> specific security requirements beyond those of Diff-Serv and
>> existing TE. Networks which employ Diff-Serv techniques
>> might offer
>> ------
>> some protection between classes for denial of service attacks.
>> ------
>> Though depending on how the technology is employed, it is possible
>> for some (lower scheduled) traffic to be more susceptible
>> to traffic
>> anomalies (which include denial of service attacks)
>> occurring within
>> other (higher scheduled) classes.
>>
My proposal would be to just keep the two first sentences (ie DSTE
solution must address security. DS-TE not expected to add new security
issues beyond those of Diff-Serv and TE) and get rid of the rest since
we do not have to start discussing how security may be achieved in the
Reqt document itself.
>> See also comments by others from ops-directorate reviewers
>>
>>
>> spelling nits:
>> - first linbe page 6
>> s/be able/be possible/ ??
I think "be able" is correct.
Before, we already say " VoIP traffic should be able ..." and here we
mean that the VoIP traffic should be able to use the shortest path.
>> - first 2 paragaraphs on page 7 have conflicting current and past
>> tense usage of verbs
Noted
>> - setc 3.3 5th line
>> s/ to and egress port/to an egress port/
Noted
>> - bottom of page 8
>> s/section 3.4 below/section 4.3 below/
Actually it should be section 4.4.
>> - page 11, inconsistent use of "criteria" and "criterion"
>>
Noted.
>> Thanks,
>> Bert
>>
>>