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

["Francois Le Faucheur (flefauch)" <flefauch@cisco.com>]

Bert,

I removed all the items we agreed on. See below on the open ones:

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

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

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

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

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.

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

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

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

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

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