NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Ed Kern <ejk@tech.org>
Jim Boyle <jimpb@nc.rr.com>
Scott Bradner <sob@harvard.edu>
Bert Wijnen <bwijnen@lucent.com>
Bert Wijnen <bwijnen@lucent.com>
Abha Ahuja <ahuja@wibh.net>
General Discussion:te-wg@ops.ietf.org
To Subscribe: te-wg-request@ops.ietf.org
In Body: subscribe
Archive: ftp://ops.ietf.org/pub/lists
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.
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 |
Jan 01 |
|
Comments to TEBCP authors for clarifications |
Jan 01 |
|
First draft of TEIMP |
Jan 01 |
|
First draft of TEAPP |
Feb 01 |
|
First draft of TEM |
Feb 01 |
|
TE Framework Draft to AD/IESG for review. |
Feb 01 |
|
Another update of operational TEMIB draft |
Feb 01 |
|
All comments back on TE Diffserv requirements |
Mar 01 |
|
Drafts available for E-LSP and L-LSP Diffserv TE |
Mar 01 |
|
Submit revised TEBCPs and REAPP to AD/IESG for review |
Apr 01 |
|
Progress operational TE MIB to AD review |
Apr 01 |
|
Any necessary protocol extensions for Diffserv TE sent to protocol relevant WGs for review. |
May 01 |
|
Progress Diffserv TE E-LSP and L-LSP Diffserv TE drafts together to AD/IESG for review |
May 01 |
|
TEIMP draft to AD review |
Jun 01 |
|
Update operational TE MIB draft |
Jun 01 |
|
Submit TEM draft for AD review |
Jun 01 |
|
Recharter |
· A Framework for Internet Traffic Engineering
· Traffic Engineering & QoS Methods for IP-, ATM-, & Based Multiservice Networks
· Requirements for support of Diff-Serv-aware MPLS Traffic Engineering
----------------------------------------------------
Minutes of the TE WG meeting, 8/9/01, 9 - 11:30 AM
51st IETF, London.
Minutes compiled by Bala Rajagopalan
Reviewed and Edited by Chairs
----------------------------------------------------
Quick Recap on Shows of Hand.
o) Hold off for now on moving draft-team-restore-hierarchy-00.txt to ccamp.
o) Fair amount of folks are interested in Diffserv/TE but haven't read or commented on draft-ietf-tewg-diff-te-reqts-01.txt
o) Folks at TEWG meeting actually in favor of entertaining drafts discussing different issues which involve no protocol changes (e.g. how to use IGP or EGP to manipulate traffic loads, ways to use LSPs that aren't in full mesh, proper capacity planning impact on utilization, etc..)
Quick Recap on some Dates Discussed.
o) End of August: Operators actually interested in Diffserv TE, read the requirements draft draft-ietf-tewg-diff-te-reqts-01.txt and provide feedback to list. Would like to wrapup the requirements draft by end of August!
o) First week of September: After this time, please don't raise new issues with draft-team-restore-hierarchy-00.txt. The goal is to have the team revise and republish so as to be able to "hand off" to ccamp for consideration by last day of September.
Note on Restoration/Hierarchy Team. I (Jim Boyle), had mentioned that there is in effect no need for this team to remain a team now that the document is a WG item. The lack of logic of this has been amply pointed out to me, as has the precedent of keeping the team in tact. So, that said, the team is still in tact and responsible for incorporating relevant feedback from the working group.
----------------------------------------------------
0. Agenda bashing - Ed Kern.
Bert: The meeting should be for "discussing" work not "presenting" stuff.
Jim Boyle (Going over the milestones): BCP docs on TE techniques are done. Operational TE MIB will be updated. TE implementation description: No progress. This milestone may be dropped. TE applicability statement will go to WG last call. The TE framework is with the IESG. The diffserv work will be the focus for the next several months. Requirements for restoration and hierarchy will be discussed. Need to move quickly on this so that ccamp can work on protocols.
Jim Boyle (Going over the milestones):
- BCP docs on TE techniques are done.
- Operational TE MIB will be updated
- TE implementation: No progress. This milestone will be dropped as discussed at last meeting.
- TE applicability statement: will go to WG last call soon.
- TE measurement. 3 drafts have been merged with little fanfare. Merged draft to go to WG last call soon.
- TE framework is with the IESG.
The diffserv work will be the focus for the next several months.
Requirements for restoration and hierarchy will be discussed. Need to move quickly on this so that ccamp can work on protocols.
Ed: TE framework has received some initial comments. The draft may be called "Isssues for TE" (or something to that effect). Will move to informational RFC by Salt Lake meeting.
Presentations (or should they be called "discussions"? :-) )
1. draft-team-restore-hierarchy-00.txt: W. S. Lai
The initial findings are preliminary. Comments and feedback solicited.
- No standard terminology has been used in drafts published so far on protection, restoration and survivability.
Yong Xue (on hierarchy): better term would be "partition" rather than hierarchy.
Lai: We'll consider this in our next version.
Comment: Routing algorithm must be capable of finding back-up and primary path. Should focus on this.
Jim: The doc. focuses only on requirements, not protocol mechanisms.
Kireeti: 1. Should talk to people in IPORPR and IPO about their requirements. 2. List and prioritize requirements. 3. This should be a WG doc.
Ed: Will be a WG doc.
Sudheer: Is there a 50 ms rest. time requirement?
Lai: We're still looking into rest. time requirements.
Jim: Need to get comments asap on the requirements.
Bert: Is this a WG doc?
Jim: Will decide after the next presentation.
Yong Xue: The rest. requirements should get feedback from IPO as it is in their charter to describe IP-optical integration. Also, restoration is a transport network feature.
Jim: Will send a pointer to IPO. Don't agree that this is purely a transport network feature.
Lai: (says he doesn't agree that this is purely a transport feature).
2. draft-owens-te-network-survivability-01.txt: Fifi Helstrand
Fifi: Either the draft merges with the design team draft or becomes a standalone WG draft.
Jim: The drafts can stay independent, at least for the moment. Encourage people to read and comment. We'll decide after that on the disposition of the draft.
Ed: Specific stuff from the draft can get into the DT draft.
Dave: Network layers and technologies is missing in the DT draft. This draft covers it. Terminology alignment is also needed between the drafts. The editorial style is also more clear in this draft. Comparison of technologies may be appropriate for framework draft and not for a requirement draft.
Jim: Should we accept the DT document as a WG doc?
(show of hands)
Jim: The doc is accepted as a WG doc. Send comments to the list.
Jim: The doc is hazy on hierarchy. Is this time to push it over to ccamp?
(discussion, show of hands)
Jim: The consensus is to hold off for a bit, and flush out the requirements before moving it to ccamp. Comments needed asap.
Kireeti: Would like to see one more draft. When can we expect the next draft?
Jim: End of september. First week of september cutoff for receiving the comments. Revise and post new version by last day of september, hand over to ccamp.
3. draft-ietf-tewg-diff-te-reqts-01: Jim Boyle
Jim: Read the draft for requirements for diffserv TE and comment. Need to do this before the protocol work begins.
Lai: The term "cos type" is not used in the doc, whereas it is used in other te docs. ITU-T is doing a lot of work on qos classes. The doc. should align the terminology, therefore. Draft also deals with failure recovery. The restoration design doc covers restoration requirements. The draft may cover some of this.
Jim: If there is strong objection to the terminology in the draft, we can change. Otherwise, the terminology can remain. Restoration - not an immediate concern for the document.
4. draft-lefaucheur-diff-te-proto-00.txt : Francois LeFaucheur
(Description of pros & cons of proposal)
Jim: Are LSPs AF1 or AF2 specific?
Francois: Either AF1 or AF2.
(Missed a couple of quick questions & answers here)
Bruce Davie: There can be a mapping between classes and class types.
Jim: Things such as overbooking on a per class/per link basis etc can be done today, without being explicit.
Ganti: Thought class-type could be used per AF. If not, not sure how constraint-based routing can be done. Class-type per link is more useful. Would like to see max limit for EF+AF. Would like to see support simultaneously for both max limit on individual classes (eg. AF1) and on class-types (eg. AF1+AF2).
Francois: Many things can be done. However, adding more capabilities could make it complex.
Bruce: Overbooking on a per class type per link, is this a property of your proposal?
Francois: This is NOT a property of this proposal. Each solution proposed (including this) has some attractive features. Need to put them all together. We need a bit more SP input to decide which features to package together to come up with the final solution.
Unknown: Think it's a good idea to have per class type per link. Have two different type of overbooking - for access and for core.
Lai: The major scalability concern is the processing of LSAs. Need to limit this.
Francois: Discussed.
5. Diff Serv TE: Kireeti Kompella
Lai: Preemption - there is no need for this in provisioning.
Jim: If a link has all best effort and want to set up EF, will there be no preemption?
Lai: No. Jerry Ash will talk later about this.
Kireeti: Scalability - LSA processing is an issue. Keeping the LSA simple helps. Other problem is the size of the db. Higher number of classes is a problem.
Jim: Predictability - how do know how many different classes are there, and what other routers are doing?
Kireeti: You don't know what the other routers are doing.
6. draft-boyle-tewg-ds-nop-00.txt: Jim Boyle
Visually compared different proposals. (see presentation)
7. draft-bittar-rao-ospf-diffserv-mpls-01.txt : Not discussed.
8. draft-ash-mpls-diffserv-te-alternative-02.txt: Gerry Ash
Ash: Considers other proposals not scalable due to more LSA generation. Proposes a measurement based reservation plus crankback in an MPLS framework.
Rob Coltun: Are you stating that Link state protocol implementations have a problem?
Ash: No, the protocol itself has problems. Trying to fix them for both PNNI and OSPF.
9. MPLS support of diffserv using E-LSP: Sudhakar Ganti
Francois: The MPLS WG discussed such a proposal and decided not to add it to the spec.
Ganti: My motivation comes from protection and restoration.
Francois: Where do we need per OA admission control without needing different routes for different OAs?
Ganti: There is such a need.
Unknown: What's the conclusion on the draft?
Kireeti: State what the problem being solved in this doc and put it in TE. Protocol work belongs in MPLS.
Bruce: This draft is a comment on MPLS diffserv extensions (which has passed last call). Can't see how this can be considered as a WG draft.
Jim: Need service provider input on the requirements. That's the focus now, rather than protocol mechanisms (referring to all proposals). The requirements draft has been posted to the list, it's a bit amazing that several people are present who are interested in this work but haven't reviewed the requirements draft. Let's have all comments back on requirements by end of August.
10. Other topics: draft-wang-te-hybrid-approach-00.txt: Y. Wang
Jim: This draft considers how to use existing protocols, not changes to any protocols. Question: do we want to consider work of this sort (i.e., how to use IGPs or EGPs) in this WG? Personally, I think other fora and outlets can handle this.
Unknown: These drafts should be considered here because we can learn something here.
Unknown: I think it's a good idea to get away from the n-squared problem. You're however not considering unequal cost paths for load balancing.
Ganti: Not everything can be done with just routing manipulation.
Kireeti: Want to understand what's the n-squared problem?
Jim: The assumption that the TE application requires an overlay of LSPs.
Kireeti: There is a difference between n-square adjacencies, and having n-squared LSPs. The latter is not necessarily a routing problem.
Jim: Do we want to entertain these types of drafts?
(Show of hands)
Jim: Yes is the consensus, but need to check with ADs.
Rob Coltun: This is not a black-and-white thing. Need to figure out which proposals have an operational aspect and use and consider them.
11. draft-lefaucheur-te-metric-igp-00.txt: Francois LeFaucheur
Francois: Proposes the doc. to progress as a BCP doc.
Jim: Discuss progression on the list.
12. SRGs : Sudhir Dharanikotta
(No discussion)
13. Summary: Ed Kern
Read the two drafts: the restoration and the diffserv requirements draft.
Network Hierarchy and Multilayer Survivability
Protocol Extensions for Support of DS-TE
Diff Serv TE Issues
Comparing Drafts
Alternative Technical Solution for MPLS DiffServ TE
MPLS Support of Differentiated Services Using E-LSP
A Scalable Traffic Engineering Solution
Use of IGP Metric as a second TE Metric
Inter-Domain Routing with Shared Risk Groups