[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: more review comments: draft-tewg-ietf-diff-te-reqts-06.txt
I am cc:-ing David Meyer so he can jump in if he feels
I am not properrly answering.
Inline
> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
> Sent: dinsdag 21 januari 2003 19:55
> To: Wijnen, Bert (Bert); Tewg (E-mail)
> Subject: RE: more review comments:
> draft-tewg-ietf-diff-te-reqts-06.txt
>
>
> Hi again Bert,
>
> >> -----Original Message-----
> >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> >> Sent: 21 January 2003 17:07
> >> To: Tewg (E-mail)
> >> Subject: more review comments: draft-tewg-ietf-diff-te-reqts-06.txt
> >>
> >>
> >> Again, sorry for late forwarding. This is the last one
> >> I had to dig up.
> >>
>
> That's good news. ^)
>
> Thanks to David for these comments. Proposed resolution embedded:
>
> >> Thanks,
> >> Bert
> >>
> >> -----Original Message-----
> >> From: David Meyer [mailto:dmm@sprint.net]
> >> Sent: woensdag 6 november 2002 15:34
> >> To: Randy Bush
> >> Cc: ops directorate
> >> Subject: Re: early peek at draft-tewg-ietf-diff-te-reqts-06.txt
> >>
> >>
> >> One thing I forgot to mention is that any draft proposing a
> >> service (or set of services) based on diff-serv should describe
> >> in it's security section what kind of DoS vulnerabilities the
> >> service might incur.
>
> We are already discussing security in the other thread. Since this is a
> requirements document I assume we need to focus on the security
> requirements here and that the DOS thing need to be discussed in the
> DSTE solution. Anyway, see actual proposal in other email.
>
Well, in my other email, I also proposed that you try to address this
isseu. If Dave suggests that he can immediately think of a few ways for
DoS attacks, then it seems appropriate to think them through and write
something about it. If nothing else, then at least list the fact that
any protocols that get developed need to pay specific attention to
ensure that DoS attackes are prevented as much as possible.
> >> >> 1. Introduction
> >> >>
> >> >> 1.1. Problem Statement
> >> >>
> >> >> Diff-Serv is becoming prominent in providing
> scalable network
> >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> >> designs supporting multiple classes of services.
> >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> >>
> >> >> @@@ This is a marketing statement, as I know of at least one
> >> >> @@@ provider who sees it differently
> >> >>
>
> Can replace with:
> "Diff-Serv is used by some Service Providers to achieve scalable network
> designs supporting multiple classes of services."
>
Seems to be much better already.
>
> >> >> In some Diff-Serv networks where optimization of
> transmission
> >> >> resources on a network-wide basis is not sought,
> MPLS Traffic
> >> >> Engineering (TE) mechanisms may simply not be used.
> >> >>
> >> >> 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
> >> >> across all Diff-Serv classes of service. In this case,
> >> Diff-Serv and
> >> >> MPLS TE both provide their respective benefits.
> >> >>
> >> >> @@@ Again, what is meant in the above by "optimization"
> I presume
> >> >> @@@ is CAPEX optimization (i.e., optimized utilization)? Even
> >> >> @@@ that much doesn't seem to be supported.
> >> >>
>
> As previously agreed "need to be" will be replaced by "may be".
>
Dave, does that address your issue enuf?
>
> >> >> This document focuses exclusively on the specific
> >> environments which
> >> >> would benefit from DS-TE. Some examples include:
> >> >>
> >> >> - networks where bandwidth is scarce (e.g.
> >> transcontinental
> >> >> networks)
> >> >>
> >> >> @@@ ?
>
> Not sure what the issue is here.
>
I think David means that he wonder if there is any such scarceness
of bandwidth across the atlantic. Is not the fact that there is
abundant bandwidth these days on of the reasons why we have such
a bad downturn in the telecom world?
> >> >> Another option is to split the different <FEC/{TA}PSC>
> >> of a given
> >> >> FEC into multiple Traffic Trunks on the basis of the
> >> {TA}PSC. In
> >> >> other words, traffic from a given node to another
> >> given node, is
> >> >> split based on the classes of service, into multiple
> >> Traffic Trunks
> >> >> which are transported over separate LSPs, which can
> >> potentially
> >> >> follow a different path through the network. DS-TE
> >> precisely takes
> >> >> advantage of this fact and indeed computes a separate
> >> path for each
> >> >> LSP.
> >> >>
> >> >> @@@ It would be nice if they quantified the complexity here.
>
> Scalability is discussed in section 5 as an evaluation criteria.
> The DSTE solution contains a discussion on scalability impact on IGP,
> signaling, path computation etc.
>
Dave? is that sufficient for you?
> >> >> @@@ In addition, the a discussion of the interaction with FRR
> >> >> @@@ would be useful at this point.
> >> >>
>
> No specific requirements was identified by SPs for DS-TE in terms of FRR
> (primarily because FRR operations was seen as defined independently of
> what gets transported on top of the tunnel). Any specific aspects of
> interaction with FRR that would be worth detailing?
>
I will let Dave answer which aspects he would like to see.
If no specific aspects, then maybe you can add some of the text of
your answer above.
>
> >> >> In so doing, DS-TE can take into account the specific
> >> >> requirements of the Traffic Trunk transported on each
> >> LSP (e.g.
> >> >> bandwidth requirement, preemption priority). Moreover
> >> DS-TE can take
> >> >> into account specific engineering constraints to be
> >> enforced for
> >> >> these sets of Traffic Trunks (e.g. limit all Traffic Trunks
> >> >> transporting a particular {TA}PSC to x% of link
> >> capacity). In brief,
> >> >> DS-TE achieves per LSP constraint based routing with
> >> paths that
> >> >> tightly match the specific objectives of the traffic
> >> forming the
> >> >> ^^^^^^^
> >> >>
> >> >> @@@ what is the defn of "tightly"?
>
> Will replace "that tightly match" by "that better match".
>
I would think that that is better understood.
> >> >> 3.1. Scenario 1: Limiting Proportion of Classes on a Link
> >> >>
> >> >> An IP/MPLS network may need to carry a significant
> >> amount of VoIP
> >> >> traffic compared to its link capacity. For example, 10,000
> >> >> uncompressed calls at 20ms packetization result in
> >> about 1Gbps of IP
> >> >> traffic, which is significant on an OC-48c based
> >> network. In case of
> >> >> topology changes such as link/node failure, VoIP
> >> traffic levels can
> >> >> even approach the full bandwidth on certain links.
> >> >>
> >> >> @@@ this last sentence doesn't really make sense in the absence
> >> >> @@@ of an understanding of the provider's network (like if I
> >> >> @@@ protect all of my packets, the statement doesn't apply)
>
> I assume the last line was meant to say "if I protect all my links"
> (instead of "all my packets"). No?
>
Dave?
> Anyway, this is not trying to say that VoIP will approach link bandwidth
> in every network. Just that it can happen in some networks in some
> situations. Which reflects the concern of the SP who provided this text.
> The description above starts with "For example". Statement seems valid
> in the context of an example.
>
Dave?
> >> >>
> >> >> For delay/jitter reasons it is undesirable to carry
> >> more than a
> >> >> certain percentage of VoIP traffic on any link.
> >> >>
> >> >> @@@ but we understand that we can run in the region about 80%
> >> >> @@@ utilization with small jitter and delay (with >= OC48). So
> >> >> @@@ why is it undesirable? This seems statement seems to
> >> be unsupported.
>
> I think the comment points out that the "certain percentage" may be as
> high as 80% in some cases (eg high speed link, strict priority provided
> to VoIP by scheduler without any rate limitation activated,...). It
> doesn't seem to invalidate the fact that if you may encounter a very
> high VoIP load on some links, you may want to control it to a certain
> percentage below 100% (be it 80%).
> Also, while the fastest backbone links in many networks are OC48 and
> above, lower speed links are also found in many networks where the
> "certain percentage" may be lower. Also, scheduler might be configured
> by SP with some rate limitation for the VoIP queue below 100% (for
> policy purposes to keep bandwidth for some other traffic such
> as Premium VPN).
>
> But again, this was not meant to suggest that this is something you need
> to do everywhere. Just that it makes sense in some environments and that
> some SPs want to do it there.
>
> So, to better reflect this, we will adjust the statement above into:
> "For delay/jitter reasons, some network administrators see it as
> undesirable to carry more than a certain percentage of VoIP traffic on
> any link. "
>
Dave, does that address your concern?
>
> >> >>
> >> >> 4.1. DS-TE Compatibility
> >> >>
> >> >> While DS-TE is required in a number of situations such
> >> as the ones
> >> >> described above, it is important to keep in mind that
> >> using DS-TE
> >> >> may impact scalability (as discussed later in this
> >> document) and
> >> >> operational practices. DS-TE should only be used when
> >> existing TE
> >> >> mechanisms combined with Diff-Serv cannot address the
> >> network design
> >> >> requirements.
> >> >>
> >> >> @@@ can these cases be described in any general way? That would
> >> >> @@@ seem to be useful (as useful as making the statement in the
> >> >> @@@ first place).
>
>
> Can update last sentence with:
> "
> DS-TE should only be used when existing TE mechanisms combined with
> Diff-Serv cannot address the network design requirements (i.e. where
> constraint based routing is required and where it needs to enforce
> different bandwidth constraints for different classes of traffic, such
> as in the scenarios described above in section 3).
> "
>
Dave?
>
> >> >> At the time of writing this document, it is not clear
> >> whether a
> >> >> single model of Bandwidth Constraints is sufficient,
> >> which one it
> >> >> should be and how flexible this model really needs to
> >> be and what
> >> >> are the implications on the DS-TE technical solution and its
> >> >> implementations. Work is currently in progress to
> >> investigate the
> >> >> performance and trade-offs of different operational
> aspects of
> >> >> Bandwidth Constraints models.
> >> >>
> >> >> @@@ can these tradeoffs (and additionaly, complexity tradeoffs)
> >> >> @@@ be quantified in any way? I would imagine that this would
> >> >> @@@ be useful for anyone wanting to deploy this technology?
> >> >>
>
> This has been discussed outside of the this document.
> For example, see draft-wlai-tewg-bcmodel-00.txt for quantified
> comparison.
>
Maybe add a ref to those "work in progress" docs.
>
> >> >> In the selection of a default model, at least the
> >> following criteria
> >> >> are expected to be considered:
> >> >> (1) addresses the scenarios in Section 2
> >> >> (2) works well under both normal and overload conditions
> >> >> (3) applies equally when preemption is either enabled
> >> or disabled
> >> >> (4) minimizes signaling load processing requirements
> >> >> (5) maximizes efficient use of the network
> >> >>
> >> >> @@@ (6) Minimizes implementation and deployment complexity?
> >> >>
>
> Agreed.
>
>
> >> >> Since there are 8 preemption priorities and up to 8
> >> Class-Types,
> >> >> there could theoretically be up to 64 TE-Classes in a
> >> network. This
> >> >> is felt to be beyond current practical requirements.
> >> The current
> >> >> practical requirement is that the DS-TE solution must
> >> allow support
> >> >> for up to 8 TE-classes. The DS-TE solution must
> allow these TE-
> >> >> classes to comprise any arbitrary subset of 8 (or
> >> less) from the
> >> >> (64) possible combinations of (8) Class-Types and (8)
> >> preemption
> >> >> priorities.
> >> >>
> >> >> @@@ what are these numbers based on (what does "current
> practical
> >> >> @@@ requirements" mean)?
> >> >>
>
> "Current practical requirements" means based on what the SP co-authors
> of that draft and others SPs from the TEWG are considering deploying in
> the coming years.
> To give you a feel , in the case of number of CTs, some argued 3 CTs
> were enough, others argued 4 CTs were enough, some argued
> they may use 5
> or more, no one argued for more than 8. We settled for 8 since this
> there were no scalability impact in a solution supporting 3,4 or 8.
>
Dave are you happy with this answer?
> >> >> @@@ I guess Scalability (5.4) is a metric of complexity, but I'd
> >> >> @@@ like to see something more specific, e.g. "Minimizes <foo>"
> >> >> @@@ etc
>
> Section 5.4 already lists the specific aspects of scalability that we
> want to be considered:
> "IGP signaling, IGP processing, IGP database, TE-tunnel signaling"
>
>
> >> >>
> >> >> 6. Security Considerations
> >> >>
> >> >> 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.
> >> >>
> >> >> @@@ I would venture to guess that no one tries to "add specific
> >> >> @@@ security requirements". That's why we have this section...
> >> >>
>
> See above re security.
>
> Cheers
>
> Francois
>
Bert