[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on draft-ietf-tewg-diff-te-reqts-06.txt
> >> - 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.
>
OK, that explains it somewhat to me... but I cannot get that from
the text in the I-D. Maybe add something about that.
Or is it clear to all TE-WGers and is it just me?
> >> - 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
>
How is "Very High QoS Guaranteed Traffic" defined? What does it mean.
What do you mean by "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/
>
OK
> >> 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".
>
Ooops... sorry
> >> - 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".
>
Section 4 I thought was to list the requirements....
I think it all boils down to the fact that it is really difficult
to find exactly what the requirements are. It is too much intermingled
with other text (at least to my taste).
> >> - 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.
>
thanks
> >> - 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".
>
Now that you point it out, I think I see it...
Maybe just me ??!!
> >> 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".
>
I was not speaking about the definitions alone.
> >> - 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.
>
The "not expected" does not sound right. It sounds as if you have no
real clue what security impacts/requirements these DS-TE requirements
bring to the table.
>
> >> 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.
>
Mmm... so yout "it" stands for "VoIP traffic" ...
got it now.
> >> - 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
> >>
Bert