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

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

Again, sorry for late forwarding. This is the last one
I had to dig up.

Thanks,
Bert 

-----Original Message-----
From: David Meyer [mailto:[email-masked]]
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. While this is alluded to below, more detail
would be useful. For example, while they say:

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

I can think of several ways to DoS the higher class (under certain
conditions). However, it sounds (from this text) that the DoS
would "spill over" into lower classes and not affect the "higher
scheduled class". 

Dave

On Wed, Nov 06, 2002 at 06:25:09AM -0800, David Meyer wrote:
>> On Wed, Nov 06, 2002 at 05:28:32AM -0800, Randy Bush wrote:
>> >> From: "Wijnen, Bert (Bert)" <[email-masked]>
>> >> To: "Randy Bush (E-mail)" <[email-masked]>
>> >> Subject: draft-tewg-ietf-diff-te-reqts-06.txt
>> >> Date: Wed, 6 Nov 2002 14:24:09 +0100 
>> >> 
>> >> Randy, I am doing AD review now.
>> >> I have all sorts of NITs, but would you rather have ops-dir
>> >> take a look at it now (while still in AD review) as opposed
>> >> to later (when I put it on IESG agenda)?
>> 
>> Some initital comments, mostly nits (search for @@@). Will look
>> it over again this afternoon. 
>> 
>> 
>> Dave
>> ----
>> 
>> 
>> 
>>                                             Francois Le Faucheur, Editor 
>>                                                      Cisco Systems, Inc. 
>>     
>>                                                    Waisum Lai, Co-editor 
>>                                                                     AT&T 
>>  
>>                                                                          
>> IETF Internet Draft 
>> Expires: March, 2003                                                
>> Document: draft-ietf-tewg-diff-te-reqts-06.txt         September 2002 
>>  
>>  
>>                       Requirements for support of  
>>                 Diff-Serv-aware MPLS Traffic Engineering 
>>  
>>  
>> Status of this Memo 
>>     
>>    This document is an Internet-Draft and is in full conformance with 
>>    all provisions of Section 10 of RFC2026. Internet-Drafts are 
>>    Working documents of the Internet Engineering Task Force (IETF), its 
>>    areas, and its working groups.  Note that other groups may also 
>>    distribute working documents as Internet-Drafts. 
>>     
>>    Internet-Drafts are draft documents valid for a maximum of six 
>>    months and may be updated, replaced, or obsoleted by other documents 
>>    at any time. It is inappropriate to use Internet-Drafts as reference 
>>    material or to cite them other than as "work in progress." 
>>     
>>    The list of current Internet-Drafts can be accessed at 
>>    http://www.ietf.org/ietf/1id-abstracts.txt. 
>>    The list of Internet-Draft Shadow Directories can be accessed at 
>>    http://www.ietf.org/shadow.html. 
>>     
>>     
>> Abstract 
>>     
>>    This document presents the Service Provider requirements for support 
>>    of Diff-Serv aware MPLS Traffic Engineering (DS-TE).  
>>     
>>    Its objective is to provide guidance for the definition, selection 
>>    and specification of a technical solution addressing these  
>>    requirements. Specification for this solution itself is outside the 
>>    scope of this document. 
>>     
>>    A problem statement is first provided. Then, the document describes 
>>    example applications scenarios identified by Service Providers where 
>>    existing MPLS Traffic Engineering mechanisms fall short and Diff-
>>    Serv-aware Traffic Engineering is required. The detailed 
>>    requirements that need to be addressed by the technical solution are 
>>    also reviewed. Finally, the document identifies the evaluation 
>>    criteria that should be considered for selection and definition of 
>>    the technical solution. 
>>   
>> Le Faucheur, et. al                                                  1 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>     
>>     
>> 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
>> 
>>    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.
>> 
>>    Where fine-grained optimization of transmission resources is sought, 
>>    it is necessary to perform traffic engineering at a per-class level 
>>    instead of an aggregate level, in order to further enhance networks 
>>    in performance and efficiency as discussed in [TEWG-FW]. By mapping 
>>    the traffic from a given Diff-Serv class of service on a separate 
>>    LSP, it allows this traffic to utilize resources available to the 
>>    given class on both shortest path and non-shortest paths and follow 
>>    paths that meet engineering constraints which are specific to the 
>>    given class. This is what we refer to as "Diff-Serv-aware Traffic 
>>    Engineering (DS-TE)". 
>>     
>>    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) 
>> 
>> @@@ ?
>>      -    networks with significant amounts of delay-sensitive traffic 
>>      -    networks where the relative proportion of traffic across 
>>           classes of service is not uniform  
>>     
>>    This document focuses on intra-domain operation. Inter-domain 
>>    operation is not considered. 
>>     
>> 1.2.    Definitions 
>>     
>>    For the convenience of the reader, relevant Diffserv ([DIFF-ARCH], 
>>    [DIFF-NEW] and [DIFF-PDB]) definitions are repeated herein. 
>>     
>>        Behavior Aggregate (BA): a collection of packets with the same 
>>        (Diff-Serv) codepoint crossing a link in a particular direction. 
>>         
>> 
>>  
>>  Le Faucheur et. al                                                  2 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>        Per-Hop-Behavior (PHB): the externally observable forwarding                  
>>        behavior applied at a DS-compliant node to a Diff-Serv behavior 
>>        aggregate. 
>>         
>>        PHB Scheduling Class (PSC): A PHB group for which a common 
>>        constraint is that ordering of at least those packets belonging 
>>        to the same microflow must be preserved. 
>>     
>>        Ordered Aggregate (OA): a set of BAs that share an ordering 
>>        constraint. The set of PHBs that are applied to this set of 
>>        Behavior Aggregates constitutes a PHB scheduling class. 
>>         
>>        Traffic Aggregate (TA): a collection of packets with a codepoint 
>>        that maps to the same PHB, usually in a DS domain or some subset 
>>        of a DS domain.  A traffic aggregate marked for the foo PHB is 
>>        referred to as the "foo traffic aggregate" or "foo aggregate" 
>>        interchangeably. This generalizes the concept of Behavior 
>>        Aggregate from a link to a network. 
>>     
>>    We also repeat the following definition from [TE-REQ]: 
>>     
>>        Traffic Trunk: an aggregation of traffic flows of the same class 
>>        which are placed inside a Label Switched Path. 
>>         
>>   In the context of the present document, "flows of the same class" is 
>>   to be interpreted as "flows from the same Forwarding Equivalence 
>>   Class which are to be treated equivalently from the DS-TE 
>>   perspective". 
>>     
>>    We refer to the set of TAs corresponding to the set of PHBs of a 
>>    given PSC, as a {TA}PSC. We also loosely refer to a {TA}PSC as a 
>>    Diff-Serv class of service, or class-of service. 
>>     
>>    We refer to the collection of packets which belong to a given Traffic 
>>    Aggregate and are associated with a given MPLS Forwarding Equivalence 
>>    Class (FEC) as a <FEC/TA>. 
>>     
>>    We refer to the set of <FEC/TA> whose TAs belong to a given {TA}PSC 
>>    as a <FEC/{TA}PSC>. 
>> 
>> 1.3.    Mapping of traffic to LSPs 
>>     
>>    A network may have multiple Traffic Aggregates (TAs) it wishes to 
>>    service. Recalling from [DIFF-MPLS], there are several options on 
>>    how the set of <FEC/{TA}PSC> of a given FEC can be split into 
>>    Traffic Trunks for mapping onto LSPs when running MPLS Traffic 
>>    Engineering.  
>>     
>>    One option is to not split this set of <FEC/{TA}PSC> so that each 
>>    Traffic Trunk comprises traffic from all the {TA}/PSC . This option 
>>    is typically used when aggregate traffic engineering is deployed 
>>    using current MPLS TE mechanisms. In that case, all the 
>>  
>>  Le Faucheur et. al                                                  3 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    <FEC/{TA}PSC> of a given FEC are routed collectively according to a 
>>    single shared set of constraints and will follow the same path. Note 
>>    that the LSP transporting such a Traffic Trunk is, by definition, an 
>>    E-LSP as defined in [DIFF-MPLS]. 
>>     
>>    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. 
>> @@@ In addition, the a discussion of the interaction with FRR
>> @@@ would be useful at this point.
>> 
>>    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"?
>> 
>>    corresponding Traffic Trunk. 
>>     
>>    For simplicity, and because this is the specific topic of this 
>>    document, the above paragraphs in this section only considered 
>>    splitting traffic of a given FEC into multiple Traffic Aggregates on 
>>    the basis of {TA}PSC. However, it must be noted that, in addition to 
>>    this, traffic from every {TA}PSC may also be split into multiple 
>>    Traffic Trunks for load balancing purposes. 
>>     
>>     
>> 2.      Contributing Authors 
>>     
>>    This document was the collective work of several. The text and 
>>    content of this document was contributed by the editors and the co-
>>    authors listed below. (The contact information for the editors 
>>    appears in Section 9, and is not repeated below.) 
>>     
>>    Martin Tatham                        Thomas Telkamp 
>>    BT                                   Global Crossing 
>>    Adastral Park, Martlesham Heath,     Oudkerkhof 51,  3512 GJ Utrecht 
>>    Ipswich IP5 3RE, UK                  The Netherlands 
>>    Phone: +44-1473-606349               Phone: +31 30 238 1250 
>>    Email: [email-masked]          Email: [email-masked] 
>>                                          
>>    David Cooper                         Jim Boyle 
>>    Global Crossing                      Protocol Driven Networks, Inc. 
>>    960 Hamlin Court                     1381 Kildaire Farm Road #288 
>>    Sunnyvale, CA 94089, USA             Cary, NC 27511, USA 
>>    Phone: (916) 415-0437                Phone: (919) 852-5160 
>>    Email: [email-masked]              Email: [email-masked] 
>>                                          
>>                                          
>>  
>>  Le Faucheur et. al                                                  4 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    Luyuan Fang                          Gerald R. Ash 
>>    AT&T Labs                            AT&T Labs 
>>    200 Laurel Avenue                    200 Laurel Avenue 
>>    Middletown, New Jersey 07748, USA    Middletown, New Jersey 07748,USA 
>>    Phone: (732) 420-1921                Phone: (732) 420-4578 
>>    Email: [email-masked]            Email: [email-masked] 
>>                                          
>>    Pete Hicks                           Angela Chiu 
>>    CoreExpress, Inc                     Celion Networks 
>>    12655 Olive Blvd, Suite 500          1 Sheila Drive, Suite 2 
>>    St. Louis, MO 63141, USA             Tinton Falls, NJ 07724, USA 
>>    Phone: (314) 317-7504                Phone: (732) 747-9987 
>>    Email: [email-masked]    Email: [email-masked] 
>>                                          
>>    William Townsend                     Thomas D. Nadeau 
>>    Tenor Networks                       Cisco Systems, Inc. 
>>    100 Nagog Park                       250 Apollo Drive 
>>    Acton, MA 01720, USA                 Chelmsford, MA 01824, USA 
>>    Phone: +1 978-264-4900               Phone: (978) 244-3051 
>>    Email:[email-masked]    Email: [email-masked] 
>>                                          
>>    Darek Skalecki                        
>>    Nortel Networks                       
>>    3500 Carling Ave,                     
>>    Nepean K2H 8E9,                       
>>    Phone: (613) 765-2252                 
>>    Email: [email-masked]      
>>     
>>     
>>     
>> 3.      Application Scenarios 
>>  
>> 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)
>>      
>>    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.
>> 
>>    The rest of the available link bandwidth can be used to route
>>    other classes corresponding to delay/jitter insensitive
>>    traffic (e.g. Best Effort Internet traffic). The exact
>>    determination of this "certain" percentage is outside the
>>    scope of this requirements document.  
>>      
>>    During normal operations, the VoIP traffic should be able to preempt 
>>    other classes of traffic (if these other classes are designated as 
>>    preemptable and they have lower preemption priority),  
>> 
>>  
>>  Le Faucheur et. al                                                  5 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    so that it will be able to use the shortest available path, only 
>>    constrained by the maximum defined link utilization ratio/percentage 
>>    of the VoIP class. 
>> 
>>    Existing TE mechanisms only allow constraint based routing of 
>>    traffic based on a single bandwidth constraint common to all 
>>    classes, which does not satisfy the needs described here. This leads 
>>    to the requirement for DS-TE to be able to enforce a different 
>>    bandwidth constraint for different classes of traffic. In the above 
>>    example, the bandwidth constraint to be enforced for VoIP traffic 
>>    may be the "certain" percentage of each link capacity, while the 
>>    bandwidth constraint to be enforced for the rest of the classes 
>>    might have their own constraints or have access to the rest of the 
>>    link capacity.  
>> 
>> 3.2.    Scenario 2: Maintain relative proportion of traffic classes 
>>     
>>    Suppose an IP/MPLS network supports 3 classes of traffic. The 
>>    network administrator wants to perform Traffic Engineering to 
>>    distribute the traffic load. Assume also that proportion across 
>>    traffic classes varies significantly depending on the 
>>    source/destination POPs. 
>>     
>>    With existing TE mechanisms, the proportion of traffic from each 
>>    class on a given link will vary depending on multiple factors 
>>    including: 
>>    - in which order the different TE-LSPs are routed 
>>    - the preemption priority associated with the different TE-LSPs 
>>    - link/node failure situations  
>>     
>>    This may make it difficult or impossible for the network 
>>    administrator to configure the Diff-Serv PHBs (e.g. queue bandwidth) 
>>    to ensure that each traffic class gets the appropriate treatment. 
>>    This leads again to the requirement for DS-TE to be able to enforce 
>>    a different bandwidth constraint for different classes of traffic. 
>>    This could be used to ensure that, regardless of the order in which 
>>    tunnels are routed, regardless of their preemption priority and 
>>    regardless of the failure situation, the amount of traffic of each 
>>    class routed over a link matches the Diff-Serv scheduler 
>>    configuration on that link for the corresponding class (e.g. queue 
>>    bandwidth). 
>>     
>>    As an illustration of how DS-TE would address this scenario, the 
>>    network administrator may configure the service rate of Diff-Serv 
>>    queues to (45%,35%,20%) for classes (1,2,3) respectively. The 
>>    administrator would then split the traffic into separate Traffic 
>>    Trunks for each class and associate a bandwidth to each LSP 
>>    transporting those Traffic Trunks. The network administrator may 
>>    also want to configure preemption priorities of each LSP in order to 
>>    give highest restoration priority to the highest priority class and 
>>    medium priority to the medium class. Then DS-TE could ensure that 
>>    after a failure, class 1 traffic would be rerouted with first access 
>>  
>>  Le Faucheur et. al                                                  6 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    at link capacity but without exceeding its service rate of 45% of 
>>    the link bandwidth. Class 2 traffic would be rerouted with second 
>>    access at the link capacity but without exceeding its allotment. 
>> 
>>    Note that where class 3 is the Best-Effort service, the requirement 
>>    on DS-TE may be to ensure that the total amount of traffic routed 
>>    across all classes does not exceed the total link capacity of 100% 
>>    (as opposed to separately limiting the amount of Best Effort traffic 
>>    to 20 even if there was little class 1 and class 2 traffic). 
>> 
>>    In this scenario, DS-TE allowed for the maintenance of a more steady 
>>    distribution of classes, even during rerouting. This relied on the 
>>    required capability of DS-TE to adjust the amount of traffic of each 
>>    class routed on a link based on the configuration of the scheduler 
>>    and the amount of bandwidth available for each class. 
>>     
>>    Alternatively, some network administrators may want to solve the 
>>    problem by having the scheduler dynamically adjusted based on the 
>>    amount of bandwidth of the LSPs admitted for each class. This is an 
>>    additional requirement on DS-TE. 
>>     
>> 3.3.    Scenario 3: Guaranteed Bandwidth Services 
>>     
>>    In addition to the Best effort service, an IP/MPLS network operator 
>>    may desire to offer a point-to-point "guaranteed bandwidth" service 
>>    whereby the provider pledges to provide a given level of performance 
>>    (bandwidth/delay/loss...) end-to-end through its network from an 
>>    ingress port to and egress port.  The goal is to ensure all 
>>    "guaranteed" traffic within a subscribed traffic contract, will be 
>>    delivered within stated tolerances.   
>>     
>>    One approach for deploying such "guaranteed" service involves: 
>>    - dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in 
>>      [DIFF-NEW]) to the "guaranteed" traffic 
>>    - policing guaranteed traffic on ingress against the traffic 
>>      contract and marking the "guaranteed" packets with the 
>>      corresponding DSCP/EXP value 
>>     
>>    Where very high level of performance is targeted for the 
>>    "guaranteed" service, it may be necessary to ensure that the amount 
>>    of "guaranteed" traffic remains below a given percentage of link 
>>    capacity on every link. Where the proportion of "guaranteed" traffic 
>>    is high, constraint based routing can be used to enforce such a 
>>    constraint.  
>>     
>>    However, the network operator may also want to simultaneously 
>>    perform Traffic Engineering of the rest of the traffic (i.e. non-
>>    guaranteed traffic) which would require that constraint based 
>>    routing is also capable of enforcing a different bandwidth 
>>    constraint, which would be less stringent than the one for 
>>    guaranteed traffic. 
>>     
>> 
>>  
>>  Le Faucheur et. al                                                  7 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    Again, this combination of requirements can not be addressed with 
>>    existing TE mechanisms. DS-TE mechanisms allowing enforcement of a 
>>    different bandwidth constraint for guaranteed traffic and for non-
>>    guaranteed traffic are required. 
>>     
>>     
>> 4.      Detailed Requirements for DS-TE 
>>     
>>    This section specifies the functionality that the above scenarios 
>>    require out of DS-TE implementations. Actual technical protocol 
>>    mechanisms and procedures to achieve such functionality are outside 
>>    the scope of this document. 
>>  
>> 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).
>> 
>>    Many network operators may choose to not use DS-TE, or 
>>    to only use it in a limited scope within their network.  
>>     
>>    Thus, the DS-TE solution must be developed in such a way that: 
>>      
>>     (i)    it raises no interoperability issues with existing deployed 
>>            TE mechanisms.  
>>     (ii)   it allows DS-TE deployment to the required level of 
>>            granularity and scope (e.g. only in a subset of the 
>>            topology, or only for the number of classes required in the 
>>            considered network) 
>> 
>> 4.2.    Class-Types 
>>     
>>    The fundamental requirement for DS-TE is to be able to enforce 
>>    different bandwidth constraints for different sets of Traffic 
>>    Trunks. 
>>     
>>    [TEWG-FW] introduces the concept of Class-Types when discussing 
>>    operations of MPLS Traffic Engineering in a Diff-Serv environment.  
>>     
>>    We refine this definition into the following: 
>>     
>>            Class-Type (CT): the set of Traffic Trunks crossing a link, 
>>            that is governed by  a specific set of Bandwidth 
>>            constraints. CT is used for the purposes of link bandwidth 
>>            allocation, constraint based routing and admission control. 
>>            A given Traffic Trunk belongs to the same CT on all links. 
>>  
>>    Note that different LSPs transporting Traffic Trunks from the same 
>>    CT may be using the same or different preemption priorities as 
>>    explained in more details in section 3.4 below. 
>>  
>>  Le Faucheur et. al                                                  8 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>     
>>    Mapping of {TA}PSC to Class-Types is flexible. Different {TA}PSC can 
>>    be mapped to different CTs, multiple {TA}PSC can be mapped to the 
>>    same CT and one {TA}PSC can be mapped to multiple CTs. 
>>     
>>    For illustration purposes, let's consider the case of a network 
>>    running 4 Diff-Serv classes of services respectively based on the EF 
>>    PHB [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e. 
>>    Best-Effort) PHB [DIFF-FIELD]. The network administrator may decide 
>>    to deploy DS-TE in the following way: 
>>         o from every DS-TE Head-end to every DS-TE Tail-end, split 
>>           traffic into 4 Traffic Trunks: one for traffic of each Diff-
>>           Serv class 
>>         o because the QoS objectives for the AF1x Traffic Trunks and 
>>           for the AF2x Traffic Trunks may be of similar nature (e.g. 
>>           both targeting low loss albeit at different levels perhaps), 
>>           the same (set of) Bandwidth Constraint(s) may be applied 
>>           collectively over the AF1x Traffic Trunks and the AF2x 
>>           Traffic Trunks. Thus, the network administrator may only 
>>           define three CTs: one for the EF Traffic Trunks, one for the 
>>           AF1x and AF2x Traffic Trunks and one for the Best Effort 
>>           Traffic Trunks. 
>>     
>>    As another example of mapping of {TA}PSC to CTs, a network operator 
>>    may split the EF traffic into two different sets of traffic trunks, 
>>    so that each set of traffic trunks is subject to different 
>>    constraints on the bandwidth it can access. In this case, two 
>>    distinct CTs are defined for EF: one for the EF traffic subject to 
>>    the first (set of) bandwidth constraint(s), the other for the EF 
>>    traffic subject to the second (set of) bandwidth constraint(s). 
>>     
>>    DS-TE must support at least 2 CTs and up to 8 CTs. Those are 
>>    referred to as CTc, 0 <= c <= MaxCT-1 = 7. 
>>     
>>    In a given network, DS-TE must not require the network administrator 
>>    to always deploy the maximum number of CTs. The network 
>>    administrator must be able to deploy only the number of CTs actually 
>>    utilized. 
>>     
>> 4.3.    Bandwidth Constraints 
>>     
>>    We refer to a Bandwidth Constraint Model as the set of rules 
>>    defining: 
>>    - the maximum number of Bandwidth Constraints; and 
>>    - which CTs each Bandwidth Constraint applies to and how. 
>>     
>>    By definition of CT, each CT is assigned either a Bandwidth 
>>    Constraint, or a set of Bandwidth Constraints. 
>>     
>>    We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1   
>>     
>> 
>>  
>>  Le Faucheur et. al                                                  9 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    Different models of Bandwidth Constraints are conceivable for 
>>    control of the CTs. 
>>     
>>    For example, a model with one separate Bandwidth Constraint per CT 
>>    could be defined. This model is defined by: 
>>    - MaxBC= MaxCT 
>>    - All LSPs supporting Traffic Trunks from CTc use no more than BCc 
>>     
>>    For illustration purposes, on a link of 100 unit of bandwidth where 
>>    three CTs are used, the network administrator might then configure 
>>    BC0=30, BC1= 50, BC2=20 such that: 
>>    - All LSPs supporting Traffic Trunks from CT0 use no more than 30 
>>      (e.g. Voice <= 30) 
>>    - All LSPs supporting Traffic Trunks from CT1 use no more than 50 
>>      (e.g. Premium Data <= 50) 
>>    - All LSPs supporting Traffic Trunks from CT2 use no more than 20 
>>      (e.g. Best Effort <= 20) 
>>     
>>    As another example, a "Russian Doll" model of Bandwidth Constraints 
>>    may be defined whereby: 
>>    - MaxBC= MaxCT 
>>    - All LSPs supporting Traffic Trunks from CTc (with b<=c<=7) use no 
>>      more than BCb 
>>     
>>    For illustration purposes, on a link of 100 units of bandwidth where 
>>    three CTs are used, the network administrator might then configure 
>>    BC0=100, BC1= 80, BC2=60 such that: 
>>    - All LSPs supporting Traffic Trunks from CT2 use no more than 60 
>>      (e.g. Voice <= 60) 
>>    - All LSPs supporting Traffic Trunks from CT1 or CT2 use no more 
>>      than 80 (e.g. Voice + Premium Data <= 80) 
>>    - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use no 
>>      more than 100 (e.g. Voice + Premium Data + Best Effort <= 100). 
>>     
>>    Other Bandwidth Constraints model can also be conceived. Those could 
>>    involve arbitrary relationships between BCb and CTc. Those could 
>>    also involve additional concepts such as associating minimum 
>>    reservable bandwidth to a CT. 
>>     
>>    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?
>> 
>>    The DS-TE technical solution must specify one default
>>    bandwidth constraint model which must be supported by any
>>    DS-TE implementation. However, additional bandwidth  
>>    constraint models may also be specified. The purpose of such a 
>>    default model is to ensure that there is at least one common 
>>    Bandwidth Constraints model implementation across various vendors 
>>    equipment and allows for easier deployment of DS-TE. However, this 
>>  
>>  Le Faucheur et. al                                                 10 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    does not preclude a network operator to activate different Bandwidth 
>>    Constraints models on different links in a network, if he/she wishes 
>>    to do so. 
>>     
>>    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?
>>     
>>    In selection criteria (2), "normal condition" means that the network 
>>    is attempting to establish a volume of DS-TE LSPs for which it is 
>>    designed; "overload condition" means that the network is attempting 
>>    to establish a volume of DS-TE LSPs beyond the one it is designed 
>>    for; "works well" means that under these conditions, the network 
>>    should be able to sustain the expected performance, e.g., under 
>>    overload it is x times worse than its normal performance [BC-MODEL]. 
>>     
>>    These selection criteria will be further discussed and refined as 
>>    part of the ongoing work on BC model selection. In particular, the 
>>    applicability of criterion (5) needs to be qualified. 
>>     
>>    Regardless of the Bandwidth Constraint Model, the DS-TE solution 
>>    must allow support for up to 8 BCs. 
>>     
>> 4.4.    Preemption and TE-Classes 
>>     
>>    [TEWG-FW] defines the notion of preemption and preemption priority. 
>>    DS-TE must retain full support of such preemption. However, a 
>>    network administrator preferring not to use preemption for user 
>>    traffic should be able to disable the preemption mechanisms 
>>    described below. 
>>     
>>    The preemption attributes defined in [TE-REQ] must be retained and  
>>    applicable across all Class Types. The preemption attributes of 
>>    setup priority and holding priority must retain existing semantics, 
>>    and in particular these semantics must not be affected by the 
>>    Ordered Aggregate transported by the LSP or by the LSP's Class Type. 
>>    This means that if LSP1 contends with LSP2 for resources, LSP1 may 
>>    preempt LSP2 if LSP1 has a higher set-up preemption priority (i.e. 
>>    lower numerical priority value) than LSP2's holding preemption 
>>    priority regardless of LSP1's OA/CT and LSP2's OA/CT. 
>>     
>>    We introduce the following definition: 
>>     
>>        TE-Class: A pair of: 
>>                (i)    a Class-Type 
>>                (ii)   a preemption priority allowed for that Class-
>>                       Type. This means that an LSP transporting a 
>>                       Traffic Trunk from that Class-Type can use that 
>>  
>>  Le Faucheur et. al                                                 11 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>                       preemption priority as the set-up priority, as 
>>                       the holding priority or both. 
>>     
>>    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. 
>>     
>>    As an example, the DS-TE solution must allow the network 
>>    administrator to define a Class-Type comprising a single TE-class 
>>    using preemption 0. 
>>     
>>    DS-TE must allow two LSPs transporting Traffic Trunks of the same 
>>    Class-Type to use different preemption priorities, and allow the LSP 
>>    with higher (numerically lower) set-up priority to preempt the LSP 
>>    with lower (numerically higher) holding priority when they contend 
>>    for resources. In other words, DS-TE must allow multiple TE-Classes 
>>    to be defined for a given Class-Type. This effectively allows the 
>>    network administrator to enable preemption within a Class-Type, when 
>>    so desired. 
>>     
>>    As an example, the DS-TE solution must allow the network 
>>    administrator to define a Class-Type comprising three TE-Classes; 
>>    one using preemption 0, one using preemption 1 and one using 
>>    preemption 4. 
>>     
>>    DS-TE must allow two LSPs transporting Traffic Trunks from different 
>>    Class-Types to use different preemption priorities, and allow the 
>>    LSP with higher setup priority to preempt the one with lower holding 
>>    priority when they contend for resources.  
>>     
>>    As an example, the DS-TE solution must allow the network 
>>    administrator to define two Class-Types (CT0 and CT1) each 
>>    comprising two TE-Classes where say: 
>>       -one TE-Class groups CT0 and preemption 0 
>>       -one TE-Class groups CT0 and preemption 2 
>>       -one TE-Class groups CT1 and preemption 1 
>>       -one TE-Class groups CT1 and preemption 3 
>>     
>>    The network administrator would then, in particular, be able to : 
>>    - transport a CT0 Traffic Trunk over an LSP with setup priority=0 
>>      and holding priority=0 
>>    - transport a CT0 Traffic Trunk over an LSP with setup priority=2 
>>      and holding priority=0 
>>  
>>  Le Faucheur et. al                                                 12 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    - transport a CT1 Traffic Trunk over an LSP with setup priority=1 
>>      and holding priority=1 
>>    - transport a CT1 Traffic Trunk over an LSP with setup priority=3 
>>      and holding priority=1. 
>>     
>>    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 
>>     
>>    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. 
>>     
>>    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)? 
>> 
>>    As with existing TE, an LSP which gets preempted is torn down at 
>>    preemption time. The Head-end of the preempted LSP may then attempt 
>>    to reestablish that LSP, which involves recomputing a path by 
>>    Constraint Based Routing based on updated available bandwidth 
>>    information and then signaling for LSP establishment along the new 
>>    path. It must be noted that there may be cases where the preempted 
>>    LSP cannot be reestablished (e.g. no possible path satisfying LSP 
>>    bandwidth constraints as well as other constraints). In such cases, 
>>    the Head-end behavior is left to implementation. It may involve 
>>    periodic attempts at reestablishing the LSP, relaxing of the LSP 
>>    constraints, or other behaviors.  
>>     
>> 4.5.    Mapping of Traffic to LSPs 
>>     
>>    The DS-TE solution must allow operation over E-LSPs onto which a 
>>    single <FEC/{TA}PSC> is transported. 
>>     
>>    The DS-TE solution must allow operation over L-LSPs. 
>>     
>>  
>>  Le Faucheur et. al                                                 13 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    The DS-TE solution may allow operation over E-LSPs onto which 
>>    multiple <FEC/{TA}PSC> of a given FEC are transported, under the 
>>    condition that those multiple <FEC/{TA}PSC> can effectively be 
>>    treated by DS-TE as a single atomic traffic trunk (in particular 
>>    this means that those multiple <FEC/{TA}PSC> are routed as a whole 
>>    based on a single collective bandwidth requirement, a single 
>>    affinity attribute, a single preemption level, a single Class-Type, 
>>    ...). In that case, it is also assumed that the multiple {TA}PSCs 
>>    are grouped together in a consistent manner throughout the DS-TE 
>>    domain (e.g. if <FECx/{TA}PSC1> and <FECx/{TA}PSC2> are transported 
>>    together on an E-LSP, then there will not be any L-LSP transporting 
>>    <FECy/{TA}PSC1> or <FECy/{TA}PSC2> on its own, and there will not be 
>>    any E-LSP transporting <FECz/{TA}PSC1> and/or <FECz/{TA}PSC2> with 
>>    <FECz/{TA}PSC3>). 
>>     
>> 4.6.    Dynamic Adjustment of Diff-Serv PHBs 
>>     
>>    As discussed in section 2.2, DS-TE may support adjustment of Diff-
>>    Serv PHBs parameters (e.g. queue bandwidth) based on the amount of 
>>    TE-LSPs established for each OA/Class-Type. Such dynamic adjustment 
>>    is optional. It is a local matter to the LSR and as such is outside 
>>    the scope of this specification. 
>>     
>>    Where this dynamic adjustment is supported, it must allow for 
>>    disabling via configuration (thus reverting to PHB treatment with 
>>    static scheduler configuration independent of DS-TE operations). It 
>>    may involve a number of configurable parameters which are outside 
>>    the scope of this specification. Those may include configurable 
>>    parameters controlling how scheduling resources (e.g. service rates) 
>>    need to be apportioned across multiple OAs when those belong to the 
>>    same Class-Type and are transported together on the same E-LSP. 
>>     
>>    The dynamic adjustment must take account of the performance 
>>    requirements of each class when computing required adjustments. 
>>  
>> 4.7.    Overbooking 
>>     
>>    Existing TE mechanisms allow overbooking to be applied on LSPs for 
>>    Constraint Based Routing and admission control. Historically this 
>>    has been achieved in TE deployment through factoring overbooking 
>>    ratios at the time of sizing the LSP bandwidth and/or at the time of 
>>    configuring the Maximum Reservable Bandwidth on links. 
>>     
>>    DS-TE must also allow overbooking and must effectively allow 
>>    different overbooking ratios to be enforced for different CTs. 
>>     
>>    DS-TE should optionally allow the effective overbooking ratio of a 
>>    given CT to be tweaked differently in different parts of the 
>>    network. 
>>     
>> 4.8.    Restoration 
>>     
>>  
>>  Le Faucheur et. al                                                 14 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>    With existing TE, restoration policies use standard priority 
>>    mechanisms such as, for example, the preemption priority to 
>>    effectively control the order/importance of LSPs for restoration 
>>    purposes. 
>>     
>>    DS-TE must ensure that similar application of the  use of standard 
>>    priority mechanisms for implementation of restoration policy are not 
>>    prevented since those are expected to be required for achieving the 
>>    survivability requirements of DS-TE networks. 
>>     
>>    Further discussion of restoration requirements are presented in the 
>>    output document of the TEWG Requirements Design Team [SURVIV-REQ]. 
>>     
>>     
>> 5.      Solution Evaluation Criteria 
>>     
>>    A range of solutions is possible for the support of the DS-TE 
>>    requirements discussed above. For example, some solutions may 
>>    require that all current TE protocols syntax (IGP, RSVP-TE, CR-LDP) 
>>    be extended in various ways.  For instance, current TE protocols 
>>    could be modified to support multiple bandwidth constraints rather 
>>    than the existing single aggregate bandwidth constraint. 
>>    Alternatively, other solutions may keep the existing TE protocols 
>>    syntax unchanged but modify their semantic to allow for the multiple 
>>    bandwidth constraints.  
>>     
>>    This section identifies the evaluation criteria that should be used 
>>    to assess potential DS-TE solutions for selection. 
>>     
>> 5.1.    Satisfying detailed requirements 
>>     
>>    The solution must address all the scenarios described in section 2 
>>    and satisfy all the requirements listed in section 3. 
>>     
>> 5.2.    Flexibility 
>>  
>>         -      number of Class Types that can be supported, compared to 
>>                number identified in Requirements section 
>>         -      number of Classes within a Class-Type 
>>     
>>     
>> 5.3.    Extendibility 
>>  
>>         -      how far can the solution be extended in the future if 
>>                requirements for more Class-Types are  identified in the 
>>                future.  
>>     
>> 5.4.    Scalability 
>>  
>>         -      impact on network scalability in what is propagated, 
>>                processed, stored and computed (IGP signaling, IGP 
>>                processing, IGP database, TE-Tunnel signaling ,...). 
>>  
>>  Le Faucheur et. al                                                 15 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>         -      how does scalability impact evolve with number of Class-
>>                Types/Classes actually deployed in a network. In 
>>                particular, is it possible to keep overhead small for a 
>>                large networks which only use a small number of Class-
>>                Types/Classes, while allowing higher number of Class-
>>                Types/Classes in smaller networks which can bear higher 
>>                overhead) 
>>     
>> 5.5.    Backward compatibility/Migration 
>>  
>>         -      backward compatibility/migration with/from existing TE 
>>                mechanisms 
>>         -      backward compatibility/migration when 
>>                increasing/decreasing the number of Class-Types actually 
>>                deployed in a given network. 
>>     
>> @@@ I guess Scalability (5.4) is a metric of complexity, but I'd
>> @@@ like to see something more specific, e.g. "Minimizes <foo>"
>> @@@ etc
>> 
>> 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...
>> 
>>    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. 
>> 
>> @@@ indeed
>> 
>>     
>> 7.      Acknowledgemnt 
>>     
>>    We thank David Allen for his help in aligning with up-to-date  
>>    Diff-Serv terminology. 
>>     
>>     
>> 8.      Normative References 
>>     
>>     
>>    [AF] Heinanen, J et al., "Assured Forwarding PHB Group", RFC2597 
>>      
>>    [DIFF-ARCH] Blake et al., "An Architecture for Differentiated 
>>    Services", RFC2475. 
>>     
>>    [DIFF-MPLS] Le Faucheur et al, "Multi-Protocol Label Switching 
>>    (MPLS) Support of Differentiated Services", RFC3270, May 2002. 
>>     
>>    [DIFF-NEW] Grossman, " New Terminology and Clarifications for 
>>    Diffserv ", RFC3260, April 2002. 
>>     
>>    [EF] Davie et al., "An Expedited Forwarding PHB (Per-Hop Behavior)", 
>>    RFC3246, March 2002. 
>>  
>>  Le Faucheur et. al                                                 16 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>     
>>    [TEWG-FW] Awduche et al, Overview and Principles of Internet Traffic 
>>    Engineering, RFC3272, May 2002.  
>>     
>>    [TE-REQ] Awduche et al, Requirements for Traffic Engineering over 
>>    MPLS, RFC2702, September 1999. 
>>     
>>     
>> 9.      Informative References 
>>     
>>    [CR-LDP] Jamoussi et al., "Constraint-Based LSP Setup using LDP", 
>>    RFC3212, January 2002 
>>     
>>     
>>    [DIFF-FIELD] Nichols et al., "Definition of the Differentiated 
>>    Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC2474. 
>>     
>>    [DIFF-PDB] Nichols et al., "Definition of Differentiated Services 
>>    Per Domain Behaviors and Rules for their Specification", RFC3086. 
>>      
>>    [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
>>    ietf-isis-traffic-04.txt, August 2001. 
>>     
>>    [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 
>>    draft-katz-yeung-ospf-traffic-06.txt, October 2001.  
>>     
>>    [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP 
>>    Tunnels", RFC 3209, December 2001. 
>>     
>>    [SURVIV-REQ] W.S. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, 
>>    T, Griffin, E. Kern, and T. Reddington, "Network Hierarchy and 
>>    Multilayer Survivability," work in progress, October 2001. 
>>     
>>     
>> 10.     Editors' Address: 
>>     
>>    Francois Le Faucheur 
>>    Cisco Systems, Inc. 
>>    Village d'Entreprise Green Side - Batiment T3 
>>    400, Avenue de Roumanille 
>>    06410 Biot-Sophia Antipolis, France 
>>    Phone: +33 4 97 23 26 19 
>>    Email: [email-masked] 
>>     
>>    Wai Sum Lai 
>>    AT&T Labs 
>>    200 Laurel Avenue 
>>    Middletown, New Jersey 07748, USA 
>>    Phone: (732) 420-3712 
>>    Email: [email-masked] 
>>     
>>     
>>  
>>  Le Faucheur et. al                                                 17 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>          Requirements for Diff-Serv-aware Traffic Engineering Sep 2002 
>>  
>>     
>>     
>>     
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>  Le Faucheur et. al                                                 18 
>>  
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>

---

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

Hi again Bert,

>> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
>> Sent: 21 January 2003 17:07
>> To: Tewg (E-mail)
>> Subject: more review comments: draft-tewg-ietf-diff-te-reqts-06.txt
>> 
>> 

That's good news. ^)

Thanks to David for these comments. Proposed resolution embedded:

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

>> >>    Diff-Serv is becoming prominent in providing scalable network 

Can replace with:
"Diff-Serv is used by some Service Providers to achieve scalable network
designs supporting multiple classes of services."

>> >> @@@ that much doesn't seem to be supported.

As previously agreed "need to be" will be replaced by "may be". 

>> >>      -    networks where bandwidth is scarce (e.g. 

Not sure what the issue is here.

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

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

>> >> @@@ what is the defn of "tightly"?

Will replace "that tightly match" by "that better match".

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

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.

>> >> @@@ why is it undesirable? This seems statement seems to 

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

>> >> @@@ seem to be useful (as useful as making the statement in the

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

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

>> >> @@@ (6) Minimizes implementation and deployment complexity?

Agreed.

>> >> @@@ what are these numbers based on (what does "current practical

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

>> >> @@@ like to see something more specific, e.g. "Minimizes <foo>"

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"

>> >>    document must address security aspects. DS-TE is not 

See above re security.

Cheers

Francois

---

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

I am cc:-ing David Meyer so he can jump in if he feels
I am not properrly answering.

Inline
> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> 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,
> 
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.

> designs supporting multiple classes of services."
Seems to be much better already.

> As previously agreed "need to be" will be replaced by "may be". 
Dave, does that address your issue enuf?

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

> signaling, path computation etc. 
Dave? is that sufficient for you?

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

> Will replace "that tightly match" by "that better match".
I would think that that is better understood.

> (instead of "all my packets"). No?
Dave?

> in the context of an example.
Dave?

> policy purposes to keep bandwidth for some other traffic such 
> as Premium VPN).
> 
Dave, does that address your concern?

> as in the scenarios described above in section 3). 
Dave?

> For example, see draft-wlai-tewg-bcmodel-00.txt for quantified
Maybe add a ref to those "work in progress" docs.

> there were no scalability impact in a solution supporting 3,4 or 8.
Dave are you happy with this answer?

Bert