[Teas] WG Action: Rechartered Traffic Engineering Architecture and Signaling (teas)
The IESG <email@example.com> Thu, 13 December 2018 17:15 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F57130DFA; Thu, 13 Dec 2018 09:15:52 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: The IESG <firstname.lastname@example.org>
To: "IETF-Announce" <email@example.com>
Cc: The IESG <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org
Content-Type: text/plain; charset="utf-8"
Date: Thu, 13 Dec 2018 09:15:52 -0800
Subject: [Teas] WG Action: Rechartered Traffic Engineering Architecture and Signaling (teas)
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 17:15:53 -0000
The Traffic Engineering Architecture and Signaling (teas) WG in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Traffic Engineering Architecture and Signaling (teas) ----------------------------------------------------------------------- Current status: Active WG Chairs: Vishnu Beeram <email@example.com> Lou Berger <firstname.lastname@example.org> Secretaries: Matt Hartley <email@example.com> Assigned Area Director: Deborah Brungard <firstname.lastname@example.org> Routing Area Directors: Alvaro Retana <email@example.com> Deborah Brungard <firstname.lastname@example.org> Martin Vigoureux <email@example.com> Technical advisors: Adrian Farrel <firstname.lastname@example.org> Mailing list: Address: email@example.com To subscribe: https://www.ietf.org/mailman/listinfo/teas Archive: https://mailarchive.ietf.org/arch/browse/teas/ Group page: https://datatracker.ietf.org/group/teas/ Charter: https://datatracker.ietf.org/doc/charter-ietf-teas/ The Traffic Engineering Architecture and Signaling (TEAS) Working Group is responsible for defining IP, MPLS and GMPLS traffic engineering architecture and identifying required related control-protocol functions, i.e., routing and path computation element functions. The TEAS group is also responsible for standardizing RSVP-TE signaling protocol mechanisms that are not related to a specific switching technology. Traffic Engineering (TE) is the term used to refer to techniques that enable operators to control how specific traffic flows are treated within their networks. TE is applied to packet networks via MPLS TE tunnels and LSPs, but may also be provided by other mechanisms such as forwarding rules similar to policy-based routing. The MPLS-TE control plane was generalized to additionally support non-packet technologies via GMPLS. RSVP-TE is the signaling protocol used for both MPLS-TE and GMPLS. Centralized and logically centralized control models are also supported, e.g., via Abstraction and Control of Traffic Engineered Networks (ACTN) and stateful-PCE. The TEAS WG is responsible for: a) Traffic-engineering architectures for generic applicability across packet and non-packet networks. This includes, for example, networks that perform centralized computation and control, distributed computation and control, or even a hybrid approach. b) Definition of protocol-independent metrics and parameters (measurement and/or service attributes) for describing links and tunnels/paths required for traffic engineering (and related routing, signaling and path computation). These will be developed in conjunction with requests and requirements from other WGs to ensure overall usefulness. c) Functional specification of extensions for routing (OSPF, ISIS) and for path computation (PCEP), including those that provide general enablers of traffic-engineering systems that may also use RSVP-TE. Protocol formats and procedures that embody these extensions will be done in coordination with the WGs supervising those protocols. d) Functional specification of generic (i.e., not data plane technology-specific) extensions for RSVP-TE, and the associated protocol formats and procedures that embody these extensions. e) Definition of control plane mechanisms and extensions to allow the setup and maintenance of TE paths and TE tunnels that span multiple domains and/or switching technologies, where a domain may be an IGP area, an Autonomous System, or any other region of topological visibility. f) Definition and extension of management and security techniques for TE path and tunnel control. This includes configuring and monitoring RSVP-TE as well as mechanisms used to configure, control, and report OAM within TE networks. YANG and MIB modules may be considered. The TEAS working group is chartered to deliver the following: 1. Definition of additional abstract service, link, and path properties such as jitter, delay, and diversity. Extensions to IGPs to advertise these properties, and extensions to RSVP-TE to request and to accumulate these properties. Work with PCE WG to include these properties in computation requests. 2. Specification of terminology, architecture, and protocol requirements for abstraction and distribution of TE information between interconnected TE domains/layers. 3. Specification and protocol extensions for a GMPLS External Network-to-Network Interface (E-NNI), i.e., multi-domain GMPLS support. 4. Protocol mechanisms to signal associated LSPs in particular with different source nodes. 5. Requirements and protocol extensions for additional protection mechanisms including, for example, end-point protection, protection of P2MP LSPs, and inter-domain protection. 6. YANG models in support of Traffic Engineering, in coordination with working groups working on YANG models for network topology and for technology-specific network attributes. Requirements may be documented in stand-alone RFCs, may be folded into architecture or solutions RFCs, may be recorded on a wiki, or may be documented in an Internet-Draft that is not progressed to RFC. The TEAS WG will coordinate with the following working groups: - With the MPLS WG to maintain and extend MPLS-TE protocol mechanisms and to determine whether they should be generalized. - With the CCAMP WG to maintain and extend non-packet, data plane technology-specific TE protocol mechanisms and to determine whether they should be generalized. - With the LSR (OSPF and ISIS) WG to maintain or extend TE routing mechanisms. - With the PCE WG on uses of a PCE in the traffic-engineering architecture, on PCE extensions per the above, and on RSVP-TE extensions to support PCE WG identified requirements. - With the IDR WG on the use of BGP-LS in TE environments. - With the DetNet WG on mechanisms (YANG models and protocols) to support DetNets. - With the SPRING WG on TE architecture and, where appropriate, TE-related protocol extensions. - With the SFC WG on mechanisms (YANG models and protocols) to support SFCs In doing this work, the WG will cooperate with external SDOs (such as the ITU-T and the IEEE 802.1) as necessary. Milestones: Dec 2018 - Revisit WG status (close if no milestones/deliverables) Apr 2019 - Submit metric recording to IESG for publication Apr 2019 - Submit TE LSP Yang Models to IESG for publication Sep 2019 - Submit RSVP(-TE) Yang Models to (base and MPLS) IESG for publication Oct 2019 - Submit SR&L3 TE Topology Yang Models to IESG for publication Nov 2019 - Submit TE Yang Models informational document to IESG for publication Nov 2019 - Submit PCECC and Native IP documents to IESG for publication Dec 2019 - Submit ACTN YANG Models to IESG for publication Dec 2019 - Submit RMR specific RSVP document(s) to IESG for publication Jan 2020 - Submit SF Aware TE Topology YANG Model to IESG for publication