comments on draft-ietf-tewg-diff-te-reqts-06.txt

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

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?
- 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?
- sect 3.2 talks (two places) about "the order in which tunnels are
  routed". What does that (ordering of tunnels) mean ?
- what are thelast 2 paragraphs on page 7 trying to say?
  sounds like blabla and handwaving to me, no?
- sect 4. 1st sentence
  s/implementations/techniques or protocols/ ??
  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"
- Is most of the text in sect 4.2 on page 9 not just another 
  scenario that belongs in sect 3?
- does the "criteria to be considered" on page 11 not belong in
  section 5?
- On page 11 you reference [BC-MODEL] but it is not listed in the
  references section I think.
- 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:

    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.
- sect 4.6
  I guess the reference to sect 2.2 should be to 3.2 ??
- 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?
- sect 5.1 refers to sections 2 and 3, which I think should respectively
  be 3 and 4
- 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.

  See also comments by others from ops-directorate reviewers
  

spelling nits:
- first linbe page 6
  s/be able/be possible/ ??
- first 2 paragaraphs on page 7 have conflicting current and past
  tense usage of verbs
- setc 3.3 5th line
  s/ to and egress port/to an egress port/
- bottom of page 8
  s/section 3.4 below/section 4.3 below/
- page 11, inconsistent use of "criteria" and "criterion"

Thanks,
Bert