[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on draft-ietf-tewg-diff-te-reqts-06.txt
Inline
> 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)"
>
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.
>
> >> > >> - 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".
>
OK, I give in
> >> > >> - 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.
>
And I responded there also
> >> > >> - 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.
>
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
> >> > 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.
> "
>
That sounds much better to me.
Pls check that you also addres the comments about DoS attacks as
reaided by David Meyer.
Bert
> Thanks
>
> Francois
>