======================================================================== Internet Traffic Engineering WG (TEWG) ------------------------------------------------------------------------ 53nd IETF, Minneapolis 3:30pm Monday, March 18, 2002 ------------------------------------------------------------------------ Times include discussion Agenda Review, Milestones, Status Chairs 20 min TEMIB Last Call Comments, Resolution Kireeti 20 minutes draft-ietf-tewg-mib-02.txt TEM - Wai Sum 30 minutes draft-ietf-tewg-measure-01.txt Diffserv TE Requirements Jim 20 minutes draft-ietf-tewg-diff-te-reqts-02.txt DSTE Proposal Francois 20 minutes draft-ietf-tewg-diff-te-proto-00.txt ======================================================================== Minutes of TEWG, March 18,2002, 3-530pm 53rd IETF, Minneapolis. Minutes compiled by Ananth Nagarajan and Josh Broch. Reviewed and Edited by Chairs ---------------------------------------------------------- Quick recap of issues: TE implementations - No volunteers to work on drafts, will be pulled from work list. TE applicability: soon to make its way from IESG to RFC editor Restoration hierarchy: with IESG TE measurements: paper still needs work and reviewers Diffserv TE requirements: still needs work. IGP as second TE method: Francois draft will be reissued as a wg document, then through last call and out to the IESG TE MIB: Comments made during last call are being made into revision, will then redo last call. ATT, C&W draft being discussed within IESG ------------------------------------------------------------ Discussion section TE Measurements: Wai Sum Lai draft-ietf-tewg-measure-02.txt Discussed draft status. Results of IETF 52 - add specific recommendations to the draft so as to achieve wg charter's objective and goals. Document additional measurements needed for TE. This work has been incorporated into the 02 version of the draft. Recent comments on list, yet to be accounted for, but will be added after the meeting. Wants comments to incorporate into draft for last call on draft. Proposed items for inclusions: 1 Use of node-pair based traffic data to derive per service class traffic matrix statistics,statistics of carried load versus performance. Possible MIB extensions needed. 2. Traffic data collection methods: need for uniform definitions across vendors and SPs, distinction between traffic offered load versus achieved thruput, need for higher order statistics for service assurance, need for packet sampled measurements to preserve detail, statistical estimation and information modeling. 3.requirements for different storage and archive solutions, use of offline bulk file transfer to reduce processing overhead, use of data correlation/suppression/filtering to prune down volume of TE data, use of TE data to engineer LSPs for VPNs. Comments/questions: Q: Shahram Davari: are you suggesting end-to-end user traffic versus, probe kind of traffic. A: Wai Sum: if you view network as a collection of nodes, traffic between any two pairs of nodes will be measured. Shahram: time difference/delay between time packet is injected to when it is received, packets in transit may lead to error. A: Wai Sum:traffic volume-based measurements (measurement interval defined) will help. three types of timeframes defined. Q: recommend standard evaluations and measurements. is this a follow up activity? A: after framework, MIB extensions, etc. will be done to carry out these recommendations. Chris: comment on shahram's comment on accuracy, depends on architecture of network and infrastructure. A Layer 2 solution can give accurate numbers throughout the mesh. Ed Kern: we need more discussion on this draft both before and if necessary during last call. -------------------------------------------------------------------------- TEMIB Kireeti Kompella: Revision of draft (rev2) reports all paths as opposed to just the active path Now three tables: tunnel info, path info, and path hop info. Version 03 of the draft is completed and will be published after the meeting Changed indexing and added conformance statement. Also added storagetype to each table and added basic security considerations To do: Adress Textual Conventions for v4,v6, AS numbers, unnumbered interfaces, and LSP id's. (ways to implement involve writing, reuse bits, or reuse mpls tc mib) Comments: Tom Nadeau: Prefer that you use mpls TC. Kireeti: if no objections, that is what we will do. ----------------------------------------------------------------------------- Diffserv TE requirements: Jim Boyle Things added to draft since last revision: Mapping diffserv traffic to lsps - one OA to one LSP - both E-lsp and l-lsp. Also multiple OAs to one LSP with ONE bandwidth value TE Class concept added: TE class is a pairing of CT and preemption priority. EAch CT has one or more active TE classes, 2 TE classes in different CTS can have same preemption priority, up to 8 TE classes supported. Added example in Section 3.2 (EF class types), Minor editorial changes. Comments that were rejected: Mapping multiple OAs to multiple LSPs. Authors feel requirements are fully developed, very few open issues, propose going to WG last call. Comments solicited. Comments: Dave McDysan: regarding preemption. Might be helpful to state that one might not want to really preempt traffic, rather make sure that higher priority classes have sufficient bandwidth. Low priority classes can be retried with lower bw or be routed over longer paths. Jim: Should basically add verbiage that describes what happens as the result of preemption? Dave: yes - want happens after preemption. Francois: preemption inherited from existing mpls/te work. Did not redefine these things. Seems like these issues are basic TE and should not have a lengthy discussion in this document. Jim: Can add this without a problem. Francois: to address dave's comment, we inhibited preemption from existing TE work, not redefined, just focused on how this affects DS-TE. what Dave said is more applicable to general TE. Jim: one or two sentences does not affect the draft. Comment (?) : a couple of sections don't have requirements. A "default" model may be a good idea. Shahram: is preemption now decoupled from CT? Jim: yes. Sudhakar: how to make sure configuration is correct on each LSR? Jim: diligence. Sudhakar: misconfiguration may cause problems. Jim: this is a common problem with many protocols. Adding info in protocol to reduce this, doesn't always solve the problem. Sudhakar: Could be a multi-area problem too. Jim: OK Francois: this misconfiguration issue has come up many times. A fundamental property of diffserv is to be flexible, but entirely relies on correct configuration. A clear decision in the MPLS WG is to stay with the principle of correct configuration, and not add signaling mechanisms to correct misconfiguration. Same principle is recommended here - rely on correct configuration of diffserv. Francois: previous comment clarification sought (default model) Jim: reqts draft is loose on bandwidth constraints. but DSTE draft has a "MUST" on bandwidth constraints. Francois: Reqts draft has a statement on default model Jim: make this a MUST --------------------------------------------------------------------------- Francois - Diffserv TE protocol draft-ietf-tewg-diff-te-proto-00.txt Updates to draft: Now will allow preemption across CTs to be disabled (allows different CTs to use same preemption, or any preemption level indpt of CTs. IGP now allows 8 BW values can now be each used to advertise arbirtry pair . Allows explicit RSVP signaling of CT. Set up priority versus holding priority (possible to be different) Provided TE-class mapping examples. CT object for signaling, routing, neither (email thread): Conclusion: agreed on desirable behavior - should be possible to allow establishement of CTO lsps, across non DS-TE support LSRs, and new DS-TE supporting LSRs, and CT1,2,3... across old (non-dS-TE) lsrs should be disallowed. Also, kept current text in draft, because it matched this desirable behavior (signal CTO LSP without CT object). Appropriate class num format also chosen for this. bandwidth model: protocols specification separated from bandwidth constraint model. i.e., protocols specified independently of model. Added formulas in Appendix for Russian Dolls model. Live Demonstration of Russian Doll model. (nested CTs) :-) RSVP-TE/CR-LDP protocol changes: added CT object (TLV for LDP), and associated error handling. IGP changes: Bandwidth constraint model Id added inside BC sub-TLV. Added BC0 in BC sub-TLV so that a single sub-TLV can be used for all bandwidth constraints. Aligned to terminology changes in requirements draft. Added section for full backwards compatible with non-DS (traditional) TE. Next steps: issue next revision with editorial changes, and issue last call to all relevant WGs (TEWG, MPLS, CCAMP, ISIS). Comments: Sudhakar: why do we have to advertise bandwidth constraint model via signaling? Francois: this is optional, you do not have to. Sudhakar: if not necessary, why are signaling extensions necessary? Francois: this is an optional sub-TLV. Ganti: Why are we doing this extension? Jim: Can you restate the question? Ganti: Is it necessary to signal bw constraints model? Francois: it is optional. Jim: Are you talking IGP or signaling? There is a CT object in the signaling protocol. Ganti: But there is a sub-tlv. [insert confusion and then understanding that discussion is about IGP extensions notRSVP-TE signalling] Jim: The whole concept of having optional tlvs in the igp is to help the head end predict what will happen when it signals a path. The reason that it is optional is because not everyone agrees that you want this in the IGP. Francois: There are no new *required* TLVs for the IGP. ?- could we not signal complicated models? Francois: can do it, but not desirable, therefore optional. bottomline - none of these extensions to IGP are REALLY mandatory, all optional. IT enables you to do accurate head-end prediction. ?- When traffic is mapped on LSPs, you did DS-TE. What is future work planned on interworking of DS-TE with policing units on network (example), for multivendor interoperability? Francois: IETF builds blocks, but shouldn't standardize these functions. could have BCPs. ---End of session----