Last Modified: 2003-01-14
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.
| 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 |
| RFC | Status | Title |
|---|---|---|
| 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 |
---------------------------------------- IETF 56 Internet Traffic Engineering AgendaMarch 17th - 1930-2200 Minutes Subject Who 15 Agenda / WG Update Chairs 15 TE-Preemption techniques de Oliveira 45 Diffserv TE Francois - Requirements - Protocol - BC Models - Russian - MAM - MAR - DSTE MIB Nadeau 30 Multi Area / Multi AS TE - draft-zhang update Zhang - Q&A 15 Perennial update on TEWG MIB Kireeti Others as time permits. Drafts for Meeting: http://www.ietf.org/internet-drafts/draf t-deOliveira-diff-te -preemption-01.txt http://www.ietf.org/internet-drafts/draf t-ietf-tewg-diff-te- reqts-07.txt http://www.ietf.org/internet-drafts/draf t-ietf-tewg-diff-te- proto-03.txt http://www.ietf.org/internet-drafts/draf t-wlai-tewg-bcmodel- 01.txt http://www.ietf.org/internet-drafts/draf t-ietf-tewg-diff-te- russian-01.txt http://www.ietf.org/internet-drafts/draf t-lefaucheur-diff-te -mam-00.txt http://www.ietf.org/internet-drafts/draf t-ash-mpls-dste-bcmo del-max-alloc-resv-01.txt http://www.ietf.org/internet-drafts/draf t-zhang-mpls-interas -te-req-02.txt http://www.ietf.org/internet-drafts/draf t-vasseur-inter-as-t e-00.txt http://www.ietf.org/internet-drafts/draf t-vasseur-mpls-nodei d-subobject-00.txt ttp://www.ietf.org/internet-drafts/draft -vasseur-mpls-loose- path-reopt-01.txt http://www.ietf.org/internet-drafts/draf t-ietf-tewg-mib-04.t xt http://www.ietf.org/internet-drafts/draf t-sivabalan-diff-te- bundling-01.txt WG Update : WG Items Status (see specific discussions below) IGP as second metric RFC-ED / normative reference hold CW BCP RFC-ED, author revision TEWG MIB Ready for WG Last Call Diffserv TE Requirements RFC-ED Diffserv TE Protocol Ready for WG Last Call Diffserv Bandwidth models (all to be progressed as Expiremental) - Russian Doll Model Ready for WG Last Call - Maximum Allocation Revise and reissue as WG document Then will go to Last Call - Maximum Allocation w/ Reservation Revise to cover comments. TE Measurement IESG ---------------------------------------- Started of with Diffserv TE Diffserv TE DSTE Requirements Update - Francois- version 7 updated sent to IESG which has already approved- removed concept of "default" BC model- alignment of Diffserv terminology 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, MPLS) 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, standards?) 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 poi nt] It was agreed that RDM should go forward to WG last call [note, that version 2 will be what is used for this]. DSTE Maximum Allocation Model (MAM) - Francois- multiple analysis drafts, both biased, and neither really a specifica 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 Model specs. Dave McDysan: Will this include a discussion against the scenarios in the requirements document? 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 specification. It was agreed that diff-te-mam should be accepted as WG document and that next rev should be moved to Last Call. 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 generally) Chair proposed to move this draft forward as an individual informational RFC. Waisum agreed. 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" model 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 in. ---------------------------------------- Preemption algorithm and analysis - Jaudelice- (see presentation and draft) ---------------------------------------- Multi-AS Requirements 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 d ocuments. Multi-AS 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 draft. 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 well ? 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 requirements though. 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 security. 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 network. 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 structure. Comment: Did the Hierarchy / Restoration RFC3386 discuss multi-area? Answer: No, there was some discussion, but nothing firm was finalized and there was an explicit door left open for this. 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 specifications? 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 implemen tations. 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 requir ements. 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 IETF? It could be seen to imply that the proposed progression was: demonstrated solution -> requirements -> specificationwhich seems cumbersome. 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 Vasseur. 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 this. 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 delay. 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 spe cified. 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 room. 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 general. 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 time. There was an overwhelming majority of folks in the room that felt that it should be adopted as a WG document now. 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 time). ---------------------------------------- ----------TEWG Mib Update - Kireeti 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 March 31st). |