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 | |
| Sep 01 | Another update of operational TEMIB draft | |
| Sep 01 | All comments back on TE Diffserv requirements | |
| Oct 01 | 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 |
Current Meeting Report
Minutes of 52nd IETF TEWG
13 December, 2001
Salt Lake City, Utah
Thanks to Josh Broch of AON Networks and Julian Lucek of Juniper for keeping the minutes.
--------------------------------------------------
draft-ietf-tewg-restore-hierarchy-00
- through last call, reviewed in CCAMP, IPO, MPLS
- may need more requirements to add to these
- currently in ADs hands and moving forward with IESG
draft-ietf-tewg-principles-02
- IESG - not really a framework draft. Issues have been resolved.
- on its way to RFC editor
draft-ietf-qos-routing-04
- under consideration as info RFC by IESG
draft-lefaucheur-te-metric-igp-01
- will go to WG last call after meeting for BCP
draft-liljenstolpe-tewg-cwbcp-01
- Will proceed to IESG as info RFC
--------------------------------------------------
Chris: (draft-liljenstolpe-tewg-cwbcp-01.txt)
Described CW's offline TE practice - see proceedings for details.
View MPLS as "IP friendly ATM" - no CSPF, QoS. Actually more like Frame Relay - did not want IP IGP to contaminate MPLS IGP. One IGP for MPLS TE layer, one for IP network.
Hierarchy:
MPLS LSRs
Core Routers
Aggregation Routers
Core routers are completely meshed with FR DLCIs (OC-48/OC-192). Each CR has an IS-IS adjacency with every other core router/
Can run multiple services over TE core.
Robert (SPRINT): If efficiency is a concern (FR-MPLS-IP), why not Frame-based ATM?
Chris: No core routers have Frame based ATM interfaces, so only WAN.
And also fastest ATM interface for routers is OC12, so lots of mux/demux to OC192 backbone.
Q: When migrate network to MPLE-TE, any management problems?
Chris: Not really - home grown tools. Took a few months.
Q: Planning on an MPLS service network?
Chris: Yes, but not same as TE network.
Kireeti: When went from ATM PVCs to MPLS, you presumably do EROs signaled via RSVP. Did that make you happier or sadder?
Chris: I have tools that do PVC mapping - could do that same for MPLS layer. Wanted to do restore at layer 3 so primary and backup paths signaled via RSVP.
Q: When you calculate LSPs offline, do they have to be typed in?
Chris: Automatically push to routers with scripts, but usually do a sanity check before is initiated.
Ananth: When you say MPLS service network, what do you mean?
Chris: Services provided over MPLS; primarily L2/L3 VPNSs.
Ananth: Is MPLS running over ATM?
Chris: No, running over POS.
Jerry: What constrains are taken into account (available bw)?
Chris: Take constrains into account during path computation, but don't put on the router.
Jerry: How often to you recalculate a TE solution?
Chris: Every 6 months as needed.
Francois: Do you do accounting for backup LSPs as well.
Chris: Yes - a percentage of required BW.
Jim: Nice architecture that gives BGP isolation from internal events.
Also can provide multiple services. What about the network has characteristics of TE?
Chris: TE is done at layer 2. Compute paths over the network and can engineer network as things change.
Jim: Can better use topology?
Chris: Yes, and regarding the questions about BW accounting? Assume that I have a hot spot between Denver and Chicago (due to increase of traffic between San Francisco and Chicago). I can easily move the Denver-Chicago traffic.
--------------------------------------------------
Kireeti - TE MIB update (draft-ietf-tewg-mib-01.txt)
Issues
- make mibs read-create
- need to make tePath* (pieces of teTunnelEntry) a separate table
- make index for teTunnelEntry and integer (not string)
32 byte string index breaks many tools, but should work, so make integer.
- do something with EROs
people don't like string of addresses
- why new TC for "addresses"?
Can have ASs, interfaces, IPv4, IPV6. How to support?
- conformance statements
Next Steps
- resolve issues
- compile mib with stricter checking
- reissue draft in Jan, 02
- sufficient chances to have another Last Call
- should also be added to MPLS MIB overview
Q: nexthop is missing LSP ID at tunnel ID.
Kireeti: please mention on list so I don't forget
Jim: Please send email to Kireeti in late Jan so assure we get a revised draft.
--------------------------------------------------
WaiSum Lai: TE measurement draft (draft-ietf-tewg-measure-01.txt)
Jim: purpose of milestone - one can identity concrete measurements for the purpose of TE - independent of technology (ATM, FR, MPLS, ...).
Concerned that draft does not meet objective. Want to have folks read and comment on whether or not objective is satisfied. How many people have read it? (answer, 4 people in audience raise hand)
Waisum: 3 drafts merged together, significant input from 2 SPs authors feel draft complete and achieves WG charter objectives and goals ie doc additional measurements needed for TE
objective: framework doc for traffic metrics needed for successful TE
identifies basic areas of traffic measurement that affect TE focuses on :
o need for uniform definitions across vendors and operators
o traffic offered load versus achieved throughput
o use of node-pair-based traffic data to derive per-service class traffic matrix stats
o stats of carried load vs performance (two aspects: what is coming to the n/w, and what traffic the n/w can handle)
o need for higher order stats for service assurance
What's next - draft summarizes principles of best practice in traffic characterization, performance characterization. Authors want comments, but want to move it to RFC quickly.
Tricci: When you try to measure traffic (incoming load and performance), do you make any assumptions about switches reliability, packet loss, delay variation? Should characterize these things before defining measurements since different vendor's equipment supports different metrics. Also, do you make any assumptions about network architecture?
WaiSum: Draft just identifies metrics - no assumptions as above.
Tricci: Is the assumed network router-based or switch based?
WaiSum: We talk about flow-based metrics, link-based, node-pair based (CR-to-CR), and MPLS LSP (path-based). Mainly rely on SNMP and netflow - don't really have node-pair statistics today.
Jerry: Surprised by comment about this not meeting charter. Work item is very important, draft does excellent job of identifying measurements. Had been many favourable comments.
Jim: I did not see any comments - email sent out on Nov. 15. No one responded. Including me, only five people in this room have read the draft. Hence, my concern as chair. As a member of the WG - sure, you need to measure when you do TE. However, draft contains a laundry list of things around measurement. For example, in order to see available capacity the draft says that you can do active insertion of traffic until congetion shown. The draft also talks about using RMON within network. Are you really recommending these things?
Waisum: For RMON, we use it to manage customer access link. Of course, we don't use it on all access links, only certain customer access links.
This is mentioned as something we do today. The main thing is to understand how much traffic the network carries. We need to measure traffic on a node-pair basis in order to derive traffic matrix statistics. This aspect is being identified as the more important need for TE."
Jim: To rephrase answer - there are things in the draft that are not recommended. There are also recommendations, but these are not clearly distinguished.
Waisum: Suggestions?
Jim: Abstract is fine, but as you get into draft you don't walk away understanding what the MIBs need, or what other technology contains.
Waisum: That would be content for the "solutions draft".
Jim: The item that the WG is interested in is more likely this "solutions" draft.
Kireeti: Including myelf, 5.5 people have read it now. It is a framework doc. I don't expect much more from a f/w doc. Lots of nice things, but what does it mean to me? What are the recs? Need something saying the relevance of the measurement to TE is "..." In order to measure the success of the TE. How do I use the measurements to say whether or not the TE used in the n/w is successful?
This draft? Should probably come up with solutions draft, may get others together to hit target. Should we consider other contributions to achieve objective?
Consensus for something like this in the charter? YES
Do people think that this draft meets objectives of WG?
- does: about 5
- does not: about 5
- holdoff decision at this time: majority
Decided that work item will go on hold for a few weeks so that people can read draft. So read it!
--------------------------------------------------
Wai Sum - Diffserv TE Requirements (draft-ietf-tewg-diff-te-reqts-02.txt)
Design philosophy:
- minimize operational complexity - generality and flexibility not main goal
- leverage existing protocols
- minimize impact on stability and performance of network (avoid new LSAs whenever possible)
- distinguish between LSP and packet-level QoS requirements
- distinguish between network and local views (link local, node local) of BW info
List of issues for discussion:
1) class type - definition
network view - specify how network resources are made available to a class of traffic. Used for constraint-based routing.
link-local view - specify amount of link BW available for each class.
Used for IGP advertisement, admission control and link bandwidth allocation.
2) class type - relationship with priority/preemption
preferred approach is 1-1 correspondence between priority and class-type. Could also be many-to-many (matrix), many-to-one (vector), one-to-many (covered by one-to-one).
3) max number of advertised bw constraints
4) split EF with distinct class types
5) Suppression of preemption
preemption should be optional - not needed in properly dimensioned network.
When used under overload, can lead to instability.
What's Next?
Q: class types initially introduced to handle aggregation - number of class types increased to 8. Can class-types be replaced with "class"?
Francois: This is a recurring misconception. Two motivations - scalability (not important now) and enforcement of common bw constrains across an ordered set of aggregates.
Kireeti added: can just have one class in each type, but class types are still useful because they are more general.
--------------------------------------------------
Francois:
Open Issues - E-LSPs and L-LSPs
What options are required??
1) DS-TE over E-LSP single OA
2) DS-TE over E-LSP multiple OA, single set of attrs
3a) DS-TE over E-LSP, multiple OA, multiple bw, single set of other attrs
3b) DS-TE over E-LSP, multiple OA, multiple set of ATTRS
4) DS-TE over L-LSP, ...
List concensus appears to be:
- clear requirement for (1)
- clear requirement for (4)
- no clear requirement for (2), but it comes for free so might as well have it.
- no requirements for (3b)
Claim
- 3a is a good thing and should be added to the requirements draft. Is essentially and optimization (may reduce number of LSPs over option (4), but requires protocol extensions)
- others say, don't need it - improvement is insignificant.
Proposal: go back to requirements draft. Poll service providers again and find out what SPs want to deploy.
--------------------------------------------------
Sudhakar Ganti (draft-ganti-mpls-diffserv-elsp-01.txt)
Version 1
- presents motivations for multiple OA E-LSPs
Assumptions in current DS-TE
- SPs never deploy LSP tunnels that carry multiple OAs
- each tunnel carriers a single OA
Why now and here in TE-WG?
- DS-TE requirements are being formulated here.
- multiple-OA E-LSPs is precluded in current DS-TE requirements
Recommendations for DS-TE
- add multiple-OA E-LSPs to DS-TE requirements
- consider proposals for multiple-OA signaling mechanisms
- decouple class-=type and preemption priority mapping
- reduce number of preemption levels (3-4)
Tricci: Fully support this draft. Thinks many people are confused and that his draft clarifies the issue.
Francois: Opposite view - so lets see the SPs view of this as a requirement.
Q: When you say that we should decouple priority from classes. What does this mean? How do you use priorities? On the mailing list, can we have a specific discussion about what this actually means. Concerned that multiple-OA have a very limited set of valid cases - other cases can be hazardous and would not put in my networks.
Kireeti: Useful, but we should not do it. Had 1 SP say we need this - reasoning is that we have to many LSPs already. Bottom line is that people don't have enough experience scaling networks with a large number of LSPs. Reduction can only be a factor of 2-4. Let's get to the point - a factor of 2, 4, or 8 is not really useful. Refresh reduction is helping already.
Chris: Echo Kireeti - maybe a bit useful, but deployment of it would be unlikely.
Q: SPs might want to carry vpn traffic of different types from a customer, would be useful for that
Ed: We need to see a consensus that this is necessary before incorporating in requirements draft. You should show the group that this is important.
--------------------------------------------------
Francois - Protocol Extensions for DS-TE
(draft-lefaucheur-diff-te-proto-01.txt)
This draft is the aggregation of Jim's, Kireeti's and previous diff-te proposal.
Open issues - disable preemption
- current solution does not allow preemption across CTs to be disabled
(different CTs always use different preemption)
- this can be fixed (allow CTs to use same preemption)
- should it be done?
Kireeti: It is a good idea to say that the default is index == preemption. Can change mapping via global configuration - same as we do for class-types.
Francois: In terms of mapping, proposing what you said, Index ===> needs to be configured on every box.
Kireeti: We signal setup/hold priority - could signal indices instead.
Francois: when set up lsp have to say what premption and ct is
Q Does the solution allow you to map different EFs to different preemption?
Francois: Yes.
Next Steps
- proposal to adopt as WG document
- should the bw constraint model be move to an "informational"?
Jim: Let's here from Jerry and come back to this.
--------------------------------------------------
Jerry - proposed MPLS diffserv TE class types
draft-ash-mpls-diffserv-te-class-types-00.txt
draft-ash-mpls-diffserv-te-alternative-02.txt
draft-ash-ospf-isis-congestion-control-01.txt
Theme is scalability concerns - draft proposes a small set of well-defined class types (6 in total)
Why?
- scalability (reduce number of possible class types)
- consistent mapping of services across SP network boundaries for
end-to-end QoS
Note - small number of "class types" defined for other standards such as Y.1541 (6 QoS classes)
This is a straw man proposal - specific details of CT definitions TBD.
Referred to work going on in OSPF working group re: other scalability issues.
Bruce: Sympathize about having consistent definitions of class over service providers. Diffserv group decided not to do this --- allow providers to differential themselves. Could standardize some classes (building blocks), but should not constrain all alternatives.
Kireeti: Several things... Defining a consistent class-type mapping is something that does not belong in the TE working group. Going from 8 to 6 or 5 classes is not worth it. Scalability of IGP is also not a TE working group item - let's keep mapping flexible.
Jerry: It is not just an 8 to 6 reduction. There could be 64 PHBs, 8 priorities, any preemption level. If you want to match all of these combinations, then you should define these allocations if you want providers to interoperate.
John: Agree with Bruce. Downfall of ATM was in part due to strictly defined service categories.
Francois: Agree with Bruce. If you are going to document a useful combination of attributes (informational document), that's great.
Should not mandate combinations.
Jon: Goals conflict with proposals - really bad idea.
Bruce: Scalability is a bit of a red-herring. Does not change what is signaled. Not in scope of any existing working group.
Ananth: Suggestion - useful work in terms of a guideline. Can it be an informational document?
Jim: Let's go to the mailing list with additional comments.
Jim: Let's return to discuss proposal to accept Francois's draft as a WG doc.
adopt: about 25
no: about 6
Jim: Will follow-up on the list, but it looks like we have a consensus to adopt.
--------------------------------------------------
Jerry Ash - (draft-ash-multi-area-te-reqmts-01.txt)
Jim: We had an area design team to initiate needs for restoration and hierarchy. Hierarchy draft, say that you just need to be able to signal through multiple IGP areas. Draft went through WG last call without comments. This document came through afterward with more requirements. How pressing are these new requirements?
Jerry:
Do we need multi-area TE? If yes, do we need requirements, what are they, and where should they go?
Draft proposes a set of requirements and compares different multi-area TE approaches against requirements.
Some SPs want it. Some don't - existing stuff works pretty well.
Issues:
- requirements options
- separate requirement draft
- add to draft-ietf-tewg-restore-...
- no requirements
- proposed way to go forward
Jim: As a WG member, and as someone who has designed mpls based data and TDM networks for deployment, I am not in support of looking too far down a road we just got on. Do you use subIP technologies in your network?
Jerry: Yes.
Jim: In TDM network?
Jerry: No.
Jim: I can see where this is nice stuff to have on roadmap, but is it important now? We should be working on more pressing issues.
Ed: Chairs have feedback that we should walk before getting into this.
Kireeti: Do we need requirements? Yes. Requirements say that we want to work on multi-area, single provider TE. Don't need inter-provider TE yet. Maybe we will expand to that a some point, but not now.
Jerry: We need requirements.
Kireeti: draft has 2 parts, requirements. Welcome to post to ccamp ml to see how drafts compare. Don't need i-d in tewg to do that. Enough to know that someone should work on it. A detailed list of what knows to be done, well that was never done for ospf, reqt was just a link-state protocol
Jim: Are some of these issues are address in OIF?
??: Protocol extensions for this are being considered in OIF.
Jerry: Draft has two parts - requirements and also compares existing drafts against requirements. In CCAMP, it was suggested to compare these drafts. This does that comparison.
Ed: How many have read the draft? [ about 20 ]
Q: Philosophy is that we have working code now and will come up with requirements later. There have been multiple proposals. We need a stated list of things against which to evaluate these.
Kireeti: Regarding comparison - I want to compare methods and proposals to figure out where they fit it. You can post this analysis to the list.
Don't need an ID in the TEWG to do that. To know that we have a requirement for multi-area TE and have detailed requirements are two different levels of requirements. It is enough to know that this problem is important - I don't need a detailed list.
Jerry: I agree, we can argue about necessity of requirements.
Adrian: I think that that work should be done. Just having the "need multi-area TE" requirement is not sufficient.
Jim: RSVP spec does not prevent people from signaling through multi-area. What have you seen to indicate that this is a problem.
Adrian: I have customers that want multi-area in their network. They are unclear of feature sets that they should ask for. This WG should provide a roadmap for what is necessary.
Jim: What does current experience indicate? No one has done it.
Adrian: We should look forward.
Ed: This won't be a working group document. Restoration hierarchy has been handed to CCAMP and we are not seeing providers ask for this.
Jerry: I'm one. Vendors are writing drafts, but don't have requirements.
Bert: Requirements done and sent to CCAMP - multi-area, single provider is in scope, but multiple providers are not. Let CCAMP deliver protocols to meet current draft. Very few/none want multiple-provider TE.
Jim: Requirements doc does say single provider, multi-area is good.
Technical merits can be discussed in CCAMP.
Q: As a point of process, can we get a sense of the room.
Jim: Question - we have forwarded a draft to CCAMP. We could do one of three things: pull it back and address in detail multi-area TE, keep it over in CCAMP and generate new requirements here, keep it in CCAMP and hold for now on multi-area TE requirements?
Ed: Just one addition. Very difficult to add multi-area requirements.
We asked and no one responded. Going back and asking is not going to help.
Jim [seperating the question]:
Pull back document? 1 Keep in CCAMP? Everyone else. Proceed with multi-area request now? about 15 Wait? about 15
Jim: 50-50. Not going to pull-back document or add requirements here, but individuals within group free to keep working on there drafts in this WG and we'll revisit this later.
Slides
Agenda
'draft-liljenstolpe-tewg-cwbcp-01'
A Framework for Internet Traffic Engineering Measurement
Requirements for Support of Diff-Serv-aware MPLS Traffic Engineering
Open Issue -- E-LSPs and L-LSPs
Proposed MPLS DiffServ TE Class Types
Protocol Extensions for DS-TE a 'Unified' Approach
Requirements for Multi-Area TE