2.7.3 Internet Traffic Engineering (tewg)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-14

Ed Kern <ejk@tech.org>
Jim Boyle <jboyle@pdnets.com>
Sub-IP Area Director(s):
Scott Bradner <sob@harvard.edu>
Bert Wijnen <bwijnen@lucent.com>
Sub-IP Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: te-wg@ops.ietf.org
To Subscribe: te-wg-request@ops.ietf.org
In Body: subscribe
Archive: http://ops.ietf.org/lists/te-wg
Description of Working Group:
Internet Traffic Engineering is defined as that aspect of Internet network engineering concerned with the performance optimization of traffic handling in operational networks, with the main focus of the optimization being minimizing over-utilization of capacity when other capacity is available in the network. Traffic Engineering entails that aspect of network engineering which is concerned with the design, provisioning, and tuning of operational internet networks. It applies business goals, technology and scientific principles to the measurement, modeling, characterization, and control of internet traffic, and the application of such knowledge and techniques to achieve specific service and performance objectives, including the reliable and expeditious movement of traffic through the network, the efficient utilization of network resources, and the planning of network capacity.

The Internet Traffic Engineering Working Group defines, develops, specifies, and recommends principles, techniques, and mechanisms for traffic engineering in the internet. The working group also serves as a general forum for discussing improvements to IETF protocols to advance the traffic engineering function.

The primary focus of the tewg is the measurement and control aspects of intra-domain internet traffic engineering. This includes provisioning, measurement and control of intra-domain routing, and measurement and control aspects of intra-domain network resource allocation. Techniques already in use or in advanced development for traffic engineering include ATM and Frame Relay overlay models, MPLS based approaches, constraint-based routing, and traffic engineering methodologies in Diffserv environments. The tewg describes and characterizes these and other techniques, documents how they fit together, and identifies scenarios in which they are useful.

The working group may also consider the problems of traffic engineering across autonomous systems boundaries.

The tewg interacts with the common control and measurement plane working group to abstract and define those parameters, measurements, and controls that traffic engineering needs in order to engineer the network.

The tewg also interacts with other groups whose scopes intersect, e.g. mpls, is-is, ospf, diffserv, ippm, rap, rtfm, policy, rmonmib, disman, etc.

The work items to be undertaken by TE WG encompass the following categories:

- BCP documents on ISP uses, requirements, desires (TEBCPs)

- Operational TE MIB (TEMIB)

- Document additional measurements needed for TE (TEM)

- TE interoperability & implementation informational notes (TEIMP)

- Traffic Engineering Applicability Statement (TEAPP)

For the time being, it also is covering the area of verification that diffserv is achievable in traffic engineered SP networks. This will entail verification and review of the Diffserv requirements in the the WG Framework document and initial specification of how these requirements can be met through use and potentially expansion of existing protocols.

Goals and Milestones:
Done  Solicit TEBCP drafts concerning requirements, approaches, lessons learned from use (or non use) of TE techniques in operational provider environments.
Done  Review and comment on operational TEMIB
Done  TEBCPs submitted for WG comment
Done  Comments to TEBCP authors for clarifications
Done  First draft of TEAPP
Done  First draft of TEM
Done  TE Framework Draft to AD/IESG for review.
Done  Drafts available for E-LSP and L-LSP Diffserv TE
Done  Another update of operational TEMIB draft
Done  All comments back on TE Diffserv requirements
Done  Submit revised TEBCPs and REAPP to AD/IESG for review
OCT 01  Progress operational TE MIB to AD review
OCT 01  Submit TEM draft for AD review
NOV 01  Any necessary protocol extensions for Diffserv TE sent to protocol relevant WGs for review.
DEC 01  Recharter
JAN 02  Progress Diffserv TE E-LSP and L-LSP Diffserv TE drafts together to AD/IESG for review
  • - draft-owens-te-network-survivability-03.txt
  • - draft-ietf-tewg-mib-04.txt
  • - draft-ietf-tewg-qos-routing-04.txt
  • - draft-ietf-tewg-diff-te-reqts-07.txt
  • - draft-srisuresh-ospf-te-05.txt
  • - draft-ietf-tewg-measure-05.txt
  • - draft-ietf-tewg-diff-te-proto-03.txt
  • - draft-ietf-tewg-te-metric-igp-02.txt
  • - draft-ietf-tewg-diff-te-russian-01.txt
  • Request For Comments:
    RFC3272 I Overview and Principles of Internet Traffic Engineering
    RFC3346 I Applicability Statement for Traffic Engineering with MPLS
    RFC3386 I Network Hierarchy and Multilayer Survivability

    Current Meeting Report

    IETF 56 Internet Traffic Engineering 
    AgendaMarch 17th - 
    Minutes         Subject                         
    15              Agenda / WG Update              
    15              TE-Preemption techniques        de 
    45              Diffserv TE                     
    Francois                - 
    Requirements                - 
    Protocol                - BC 
    Models                  - 
    Russian                  - 
    MAM                  - 
    MAR                - DSTE MIB                      
    30              Multi Area / Multi AS 
    TE                - draft-zhang update            
    Zhang                - 
    15              Perennial update on TEWG MIB    
    Others as time 
    Drafts for 
    WG Update 
    WG Items Status (see specific discussions 
       IGP as second metric                 RFC-ED / normative reference 
       CW BCP                               RFC-ED, author 
       TEWG MIB                             Ready for WG Last 
       Diffserv TE Requirements             
       Diffserv TE Protocol                 Ready for WG Last 
       Diffserv Bandwidth models (all to be progressed as 
       - Russian Doll Model                 Ready for WG Last 
       - Maximum Allocation                 Revise and reissue as WG 
    					Then will go to Last 
       - Maximum Allocation w/ Reservation  Revise to cover 
       TE Measurement                       
    Started of with Diffserv 
    DSTE Requirements Update - 
    Francois- version 7 updated sent to IESG which has already 
    approved- removed concept of "default" BC 
    model- alignment of Diffserv 
    DSTE Protocol Draft - 
    Francois- Changes from version 2 to 
    3- removed concept of "default" BC 
    model- ready for last 
    call- will send notice to other WGs (e.g. OSPF, ISIS, 
    DSTE Russian Doll BC Model (RDM) - 
    Francois- Changes from version 0 to 
    1- removed concept of "default" BC 
    model- Security consideration 
    updated- no current known open 
    issues- ready for last 
    call- DSTE w/ RDM has limited deployment experience 
    now- question as to which track to follow (experimental, 
    Chairs: After some discussion, it seems the way to go forward is to make all 
    of them experimental, then as they get some use, move them toward 
    standard.  [there was a call for comment, but no questions raised at this 
    It was agreed that RDM should go forward to WG last call [note, that 
    version 2 will be what is used for 
    DSTE Maximum Allocation Model (MAM) - 
    Francois- multiple analysis drafts, both biased, and neither really a 
    tion- thus, specification draft put 
    forward- propose that we make this WG document in next 
    revision- then issue next revision (working with Waisum) and take to WG last 
    call.- progress BC model analysis in a document separate from individual BC 
    Dave McDysan: Will this include a discussion against the scenarios in the 
    After discussion it was determined that in the Russian dolls draft, there is a 
    discussion of how it meets the requirements, so this will also be done in 
    the maximum allocation 
    It was agreed that diff-te-mam should be accepted as WG document and that 
    next rev should be moved to Last 
    DSTE Maximum Allocation Model (MAM) - 
    Waisum- Slides may not match what Francois discussed, but only since they were 
    prepared last week, in general he echos what Francois 
    outlined- Drafts intent was specification and comparison of 
    performance- Main difference with RDM is higher degree of sharing with tradeoff of 
    service isolation impact (ala 
    preemption)- Proposing it as an applicability statement to MAM (or BC models more 
    Chair proposed to move this draft forward as an individual 
    informational RFC. Waisum 
    DSTE Maximum Allocation with Reservation Model (MAR) - 
    Jerry- Some amount of discussion on list (esp. between Jerry and 
    Francois)- Feels all models should work well with or without 
    preemption.- This is especially important with lack of "default" 
    Francois had some comments on whether all the assumptions have been fully 
    outlined in the MAR draft, Jerry agreed that they he will revise the draft to 
    cover this more fully.  
    DSTE MIB - Tom 
    Nadeau- Linked into MPLS WG TE 
    MIB- Not tightly coupled to any specific BC 
    model- Comment from Bert that while this is worthwhile thing to work on, there 
    are some significant comments that need to be incorporated   into base MPLS 
    MIB documents, and he'd like to see progress on that   before worrying 
    about which WG DSTE MIB should be 
    Preemption algorithm and analysis - 
    Jaudelice- (see presentation and 
    Chair comment: There's been a lot of discussion on this work, in terms of 
    what our scope should be, where should protocols be discussed, and 
    whether to accept this particular on as the WG document to be the 
    requirements draft.  At this time we have several WG items that are very 
    near to completion and that is our top objective now.  We can continue to 
    have discussions on the list in terms of requirements, and even 
    discussions on how current protocols meet or fall short of these 
    requirements, but we are not ready now to adopt drafts in this area now as WG 
    draft-zhang- updates from draft 1 to 
    2- incorporated several comments from the 
    list- echoed that now is the time for this 
    work.- show of hands showed that most in the room had read this 
    Chair - Question on whether we should address Inter-area as well as 
    Inter-as.  Raymond indicated that most folks are not that interested area, 
    however a show of hands indicated that several in the room were 
    interested in inter-area.  Question on if this draft could cover that as 
    JPV and Raymond said that the SPs co-authoring the inter-AS TE 
    requirements draft are not interested to extend the scope of this draft to 
    inter-area TE. There could be a separate draft for inter-area TE 
    JPV mentioned that although some solutions will be both applicable to 
    inter-area and inter-AS, the set of requirements will likely be 
    different in particular the aspects related to policy, 
    confidentiality and 
    Vijay - Some of this seems to be looking very far down the road, why focus 
    protocol changes in support of inter-as while not even figuring out how to 
    work out some of the issues that might be experienced within one 
    network, or across networks within one company.  Many of the larger 
    companies actually have one global 
    Yonghwan Kim: Indicated that this is not necessarily universal, they have 
    quite a deal of traffic they would like to engineer, but their current 
    architecture has regional AS 
    Comment:  Did the Hierarchy / Restoration RFC3386 discuss 
    Answer: No, there was some discussion, but nothing firm was finalized and 
    there was an explicit door left open for 
    JPV indicated that he hoped that this moves forward quickly, as 
    customers are waiting for this, and we are delaying that. 
    Jim indicated that if customers are waiting, then by all means provide them 
    with a solution.  In fact, some experience in this regard migh be a good 
    thing before final specification.  What expectation is there on 
    timeframe for the IETF to develop requirements and 
    Francois mentioned that DSTE is an example of something whose 
    standardisation lingered because it took a lot of discussion to agree that it 
    should be worked on.  This has resulted in proprietary deployed 
    Bert echoed that there is nothing wrong with going out and developing 
    solutions to problems for operators.  In fact having some experience fed 
    back into the specification process might help us better define our 
    There was some objection to this idea, since if solutions are 
    developed in a proprietary manner, proprietary solutions can become 
    de-facto standards, then what is the role of the 
    It could be seen to imply that the proposed progression 
    was:   demonstrated solution -> 
       requirements -> 
    specificationwhich seems 
    Francois pointed out that progress on items already in our charter can be 
    done independently of discussion on multi-as requirements, and he feels 
    that by not making draft-zhang a WG document, we are only delaying our 
    progress.  It is his belief that draft-zhang will become more fully 
    reviewed and make better progress as a WG document, and that lack of a WG 
    document in this area indicates that the WG is not committed to 
    progress on this subject.  This was echoed by Bruce Davie, George 
    Swallow and Jean Phillipe 
    Jim agreed that the effort is orthogonal, but felt that, for instance some 
    had indicated that although there were clearly folks who felt they had 
    requirements for inter-as, there were also folks that indicated an 
    interest in inter-area.  It might be best to consolidate the 
    requirements for these in a coherent requirements document instead of 
    doing requirements piecemeal as they develop.  Or at least we should 
    explicitly decide to group these or work on them separately.  It might also 
    be good to analyze the potential scope and to make sure that we focus on 
    particular subset of 
    There were several other comments that are not captured in the notes, but it 
    certainly seemed that several felt that the path being proposed would do 
    nothing more than 
    JVP asked where he should be discussing the different proposed 
    solutions that he has, and Jim replied that he can have individual 
    contributions to the IETF, and that in the context of making sure we have 
    flushed out the requirements correctly we can discuss these on TEWG list.  
    JVP's response was that it was clear that over 80% were 
    enthusiastic about the current requirements draft, and that any delay to 
    make it a WG document will result in eventual delay in the solutions being 
    This number seemed at least to the ADs and to the chairs to be a bit high, 
    given some comments of concern for the potential impact on routing 
    scalability and manageability for making the wrong choices in this area.  It 
    certainly was clear that the document had been read by most in the 
    Jim tried to determine to what extent there was support in the room for 
    pushing forward with draft-zhang, compared to those that did not support it 
    moving forward at this time either because they had particular issues with it 
    in particular or felt there needed to be more discussion in 
    After much discussion on how to capture this in a clear question, it was 
    agreed just to leave it at those that thought we should accept 
    draft-zhang as a WG document (to capture multi-as requirements), and those 
    that felt that it should not be a WG document at this 
    There was an overwhelming majority of folks in the room that felt that it 
    should be adopted as a WG document 
    At this point there was little more to discuss, other then to continue with 
    following the discussion up on the list (and for the chairs and IESG to 
    figure out what if any charter update is required at this 
    ----------TEWG Mib Update - 
    The draft has been revised to be inline with the MPLS WG document 
    TCs.Need to confirm if it compiles cleanly, and if necessary revise draft (by 


    Maximum Allocation Bandwidth Constraints Model For Diffserv-TE & Performance Comparison
    Protocol Extensions for DS-TE
    Bandwidth Constraints Models for DS-TE
    Inter-AS MPLS Traffic Engineering
    Max Allocation with Reservation (MAR) BW Constraint Model for MPLS/DiffServ TE & Performance Comparisons
    Diff-Serv-aware MPLS Traffic Engineering Network Management Information Base Using SMIv2
    LSP Preemption Policies for Diff-Serv-aware MPLS Traffic Engineering
    Inter-AS MPLS TE Requirements
    Requirements for DS-TE