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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 19 Jan 2003 19:31:34 +0100

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 20 Jan 2003 11:09:26 -0000

Bert,

Thanks for the thorough review. 
Thanks also to ops-directorate reviewers.

Comments/proposed-resolution embedded below:

>> -----Original Message-----
>> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
>> Sent: 19 January 2003 19:32
>> To: Tewg (E-mail)
>> Subject: comments on draft-ietf-tewg-diff-te-reqts-06.txt
>> 
>> 

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.

>>   Would a s/existing/other/ be more appropriate?

Noted.

>>   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. 

>>   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).

>>   s/implementations/techniques or protocols/ ??

Agreed. Since we already mention several times the "DS-TE solution" , we
could s/implementations/solution/

>>   to DS-TE? Maybe I get confused since you did not define the term

Section "1.2 Definitions" contains a definition for "Traffic Trunks".

>>   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

Agreed.
When updating the text of 4.2 about Default model, we will move the BC
Model criteria to section 5. 

>>   references section I think.

Noted.

>>   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".

>>   section 4.5 ?? Cause I would have to go and study in detail if I

A definition for these terms is actually provided in section "1.2
Definitions".

>>   I guess the reference to sect 2.2 should be to 3.2 ??

Right.

>>   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 

Noted.

>>    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.

>>   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

Noted

>>   s/ to and egress port/to an egress port/

Noted

>>   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.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 21 Jan 2003 10:41:32 +0100

> follow your suggestion and capitalize them.
Mmmm.. take a look at RFC3216 sect 4 for example. I think such a form
makes it really clear as to what exactly the requirement is and what
type of requirement it is and what the motivation/explanation is.

I was not so much worried aboutMUST/SHOULD/MAY not being capitalized.
More that the explanantory text and the actual requirements and
sometimes examples/scenario-text is all mixed. 

For example, could you easily tell me how many mandatoty and
how many optional requirements there are?

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 21 Jan 2003 12:43:18 +0100

> 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?

> 	- 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
> Agreed. Since we already mention several times the "DS-TE 
> solution" , we could s/implementations/solution/
> 
OK

> Section "1.2 Definitions" contains a definition for "Traffic Trunks".
Ooops... sorry

> 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).

> Model criteria to section 5. 
thanks

> The paragraph below would require a differnet "CT definition".
Now that you point it out, I think I see it... 
Maybe just me ??!!

> A definition for these terms is actually provided in section "1.2
I was not speaking about the definitions alone.

> we do not have to start discussing how security may be achieved in the
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.

> mean that the VoIP traffic should be able to use the shortest path.
Mmm... so yout "it" stands for "VoIP traffic" ...
got it now.

Bert

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 21 Jan 2003 13:36:27 -0000

Bert,

>> Or is it clear to all TE-WGers and is it just me?

I would expect that to be clear to people who are familiar with the
[TEWG-FW] and [TE-REQ] documents we included as Normative References.
Still, we can replace:
 "   - in which order the different TE-LSPs are routed"
by
 "   - in which order the different TE-LSPs are routed (since this
affects which TE-LSP can reserve bandwidth first)"

>> What do you mean by "Normal Traffic" ??

"Very High QoS" translates into different Service Level Specification
(SLS) with different operators. That's a desired property of IP QoS.
Here , we don't want to define it very precisely. The text just says
that when supporting such "Guaranteed Bandwidth" service, "it may be
necessary to ensure that ...".
The practical thing behind is that indeed some SPs want to market SLS
with very tight commitment and perform separate admission control of
this traffic as one of the mechanisms to ensure the SLS.

In the document we don't actually use the term "Normal Traffic". We just
refer to "the rest of the traffic".

>> Section 4 I thought was to list the requirements.... 

Yes, the objective of section 4.2 is to list the requirements related to
Class-Types. But before we do so, we define exactly what CTs are and
their relationship to relevant concepts. This is part of the definitions
necessary for formulating the related requirements.

>> with other text (at least to my taste).

You raised this in a separate email, so I'll follow that up there.

>> I was not speaking about the definitions alone.

FEC, E-LSP and L-LSP are really well-known terms in MPLS land.
TA and PSC are well-known in Diff-Serv land.
The only new things are {TA}PSC and <FEC/{TA}PSC> which are defined in
the definition section.
So I think we can assume the notations are understood.
We didn't get any concern even at Last Call.
 
>> real clue what security impacts/requirements these DS-TE requirements

I see your point.
I guess the "not expected" stems from the fact that we may have been
trying to bundle two things (requirements vs mechanisms):
	- there is no identified specific security requirements for DSTE
beyond those of TE and Diff-Serv
	- without assuming anything about DS-TE solution, we can't be
quite sure that existing security mechanisms won't get broken by DS-TE.

So how about breaking this up into something like :

"
The solution developed to address the requirements defined in this
document must address security aspects. DS-TE does not raise any
specific additional security requirements beyond the existing security
requirements of MPLS TE and Diff-Serv. The solution must ensure that the
existing security mechanisms of MPLS TE and Diff-Serv are not
compromised by the solution protocol/procedure extensions or otherwise
must provide security mechanisms to address this. 
"

Thanks 

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 21 Jan 2003 13:54:16 -0000

Hello Bert,

>> Sent: 21 January 2003 10:42
>> To: Francois Le Faucheur (flefauch); Tewg (E-mail)
>> Subject: RE: comments on draft-ietf-tewg-diff-te-reqts-06.txt
>> 
>> 

Yes, very neat. The structuring makes all of this very obvious, and I'll
certainly look at this as a good model for requirements documents.

But, while you cannot just have a quick look at the diff-te-reqts
document and immediately count how many items are mandatory and how many
are optional, my impression is that when you read the various
sub-sections of section "4 Detailed Requirements", it is reasonably
clear whether something is background, example, mandatory requirement or
optional (It will be even clearer when capitalised). It is not as neat,
since you do have to read the whole text and couldn't easily fill-in
"compliance statements" saying we meet items x,y,z and don't meet items
a,b,c;  But practically speaking it has proved quite appropriate for
guiding us in developping the DS-TE protocol extensions (which are due
for WG Last Call very shortly).

So, considering that the WG has been in agreement on the actual content
for a while, and that the corresponding protocol extensions based on
this are ready for Last Call, I'm inclined towards the approach of "not
perfect, but does the job" and avoid significant editing changes just
for easier identification of same content. This is all in the view of
finalising that document asap, since it conditions all the DSTE work.

Is there any way you could live with the current structure (ie
background/definition + requirement/MUST in same sub-section)?
 
Thanks

Francois

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 21 Jan 2003 17:06:49 +0100

Inline

> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: dinsdag 21 januari 2003 14:54
> To: Wijnen, Bert (Bert)
> Cc: Tewg (E-mail)
You should also wonder: can people who need to evaluate your protocol
specs (which I guess will go also through IETF Last Call, they
are intended for stds track, are they not?) can easily check how you
do in terms of meeting the requirments.

> background/definition + requirement/MUST in same sub-section)?
Although I think such a major editorial change would be VERY helpful
and useful, I can understand that you are a bit reluctant.

A simpler change could be in the following form (this is one example):
Take top of Page 12. It says:
   Note that by definition:
   - for a given Class-Type, there may be one or multiple TE-classes
     using that Class-Type, each using a different preemption priority
   - for a given preemption priority, there may be one or multiple TE-
     Class(es) using that preemption priority, each using a different
     Class-Type.

   DS-TE must allow all LSPs transporting Traffic Trunks of a given
   Class-Type to use the same preemption priority. In other words, DS-
   TE must allow a Class-Type to be used by single TE-Class. This
   effectively allows the network administrator to ensure that no
   preemption happens within that Class-Type, when so desired.

If you would change it to (assuming I have destilled the requirement
correctly):
   Note that by definition:
   - for a given Class-Type, there may be one or multiple TE-classes
     using that Class-Type, each using a different preemption priority
   - for a given preemption priority, there may be one or multiple TE-
     Class(es) using that preemption priority, each using a different
     Class-Type.

   MANDATORY REQUIREMENT: DS-TE must allow all LSPs transporting
   Traffic Trunks of a given Class-Type to use the same preemption
   priority. In other words, DS-TE must allow a Class-Type to be
   used by single TE-Class. This effectively allows the network
   administrator to ensure that no preemption happens within that
   Class-Type, when so desired.

So start each paragraph that actually is a short description of 
a requirement statement such that is is prefixed with the text
MANDATYORY REQUIRMENT: or OPTIONAL REQUIREMENT: as the case may be.
So they would still not be numberd (which makes referencing them much
easier) but at least they clearly stand out.

Maybe you could even do: MANDATORY REQUIREMENT nn:
where nn is a sequential number for each of the requirements, so 
they in fact CAN be easily referenced later.

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 21 Jan 2003 21:25:14 +0100

Inline
>        affects which TE-LSP can reserve bandwidth first)"
I now see why I did not understand. When you say "TE-LSPs are routed"
then I think of "routing happens all the time for all packets".
From what you suggest to add, it sounds as if you mean that at the
time a TE-LSP is configured, that that is the time when bandwidth
is reserved. So I guess you mean
     - in which order the different TE-LSPs are configured
       (or established or created) 

Did I get that? If so, then my text if probably even better.

> >> How is "Very High QoS Guaranteed Traffic" defined? What 
> >> does it mean. What do you mean by "Normal Traffic" ??
> >>  
> 
> In the document we don't actually use the term "Normal 
> Traffic". We just refer to "the rest of the traffic".
> 
OK, I give in

> You raised this in a separate email, so I'll follow that up there.
And I responded there also

> We didn't get any concern even at Last Call.
So can you tell me (I am thick, sorry) what means:
  - {TA}PSC
  - <FEC/{TA}/PSC>

Maybe once you explain it to me I will get it and maybe there is an Aha

> must provide security mechanisms to address this. 
That sounds much better to me. 

Pls check that you also addres the comments about DoS attacks as
reaided by David Meyer.

Bert

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 22 Jan 2003 11:03:26 -0000

>> Did I get that? If so, then my text if probably even better.

Alright then let's go for:
"      - in which order the different TE-LSPs are configured
        (or established)
"

(as I couldn't explain the difference between "created".

>> Maybe once you explain it to me I will get it and maybe 

How about an example:

Say SP supports a class of service C1 with committed/excess concepts
using the AF11 and AF12 PHBs.

Diff-Serv has defined a convenient term to designate all the packets of
the DS domain whose DSCP correspond to AF11 . It is called a Traffic
Aggregate. Let me call it, loosely, the AF11 TA.
Clearly we also have the AF12 TA.

We look at the packets belonging to AF11 TA and AF12 TA as the ones
forming the C1 class of service. To indicate that the reason those two
are grouped together is because they "share a ordering constraints" (ie
they MUST not be reordered) we call this set a {TA}PSC.
The PSC is an existing Disff-Serv concept that precisely designates the
set of PHBs sharing the "same ordering constraint".
Hence the notation of "{TA}PSC" to suggest that it is a set of several
TA whose relationship is that their PHBs belong to the same PSC.
In brief it is really nothing else that the set of all packets in that
domain which belong to a given "class of service".

Now clearly, depending on their destination, packets of a given class of
service (ie packets from a given {TA}PSC ) will be transported on
different TE tunnels. FEC is an MPLS term that sort of designate the set
of packets that are "going on the same path from MPLS perspective".  The
set of packets of a given class of service which are transported on a
given tunnel are called a  <FEC/{TA}/PSC> to indicate it is basically
the intersection of a FEC and a {TA}/PSC. 

Aha?

>> That sounds much better to me. 

Will update.
 
>> Pls check that you also addres the comments about DoS attacks as

Discussed separately.

Francois

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 22 Jan 2003 13:54:11 +0100

Inline

> Sent: woensdag 22 januari 2003 12:03
> To: Wijnen, Bert (Bert)
> Cc: Tewg (E-mail)
MUCH better. Thanks

> (as I couldn't explain the difference between "created".
they were choices I gave you.

> the intersection of a FEC and a {TA}/PSC. 
Somewhat... but I am not a TE expert, nor an Diffserv or MPLS expert.
I can at least follow/understand the above explanation. That helps me,
thanks. If everyone else is happy with the text you have in sect 4.5,
then I won't object any longer.

I did see that Panos TRIMINTZIOS already wonders if you are inventing
new (and more complex) terminology. 

> >> Pls check that you also addres the comments about DoS attacks as
Yes, but no I don't think I have seen a proposed (re)solution yet, have I?

Bert