[secdir] [new-work] WG Review: Traffic Engineering Architecture and Signaling (teas)

The IESG <iesg@ietf.org> Tue, 25 November 2014 21:14 UTC

Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 809C61A875C; Tue, 25 Nov 2014 13:14:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1416950063; bh=Y4d2t1FegxuREBt5vK6R5fxEKbCse29Fzyi9zmnPdwo=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=U4RXh5/jPyAOLiqT4/h1ZdpLdMdEKdkelJsqz1J2uUUAUg8bkEKJaJ/FWRy/KRJM0 /YBsRFXBypGLkdFNj8qMDv6hOWWhoeGHLRM3K0vTt3cU1YE9plYLp0dtDWfrUB4otR 21U5/BTlttwjBR8WwlNxmAe8SYIfWZyUoI5oko3g=
X-Original-To: new-work@ietfa.amsl.com
Delivered-To: new-work@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3B11A6FF7; Tue, 25 Nov 2014 13:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgnFVPS__xdP; Tue, 25 Nov 2014 13:13:05 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EA51A7012; Tue, 25 Nov 2014 13:13:05 -0800 (PST)
MIME-Version: 1.0
From: The IESG <iesg@ietf.org>
To: new-work@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141125211305.29982.31871.idtracker@ietfa.amsl.com>
Date: Tue, 25 Nov 2014 13:13:05 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/raih-LkITlkeUwA3y14fpJgwVI8
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.15
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: new-work-bounces@ietf.org
Sender: "new-work" <new-work-bounces@ietf.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/q--US75xBHd4c6iSgVWTpKLIDC4
X-Mailman-Approved-At: Tue, 25 Nov 2014 13:22:20 -0800
Subject: [secdir] [new-work] WG Review: Traffic Engineering Architecture and Signaling (teas)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Nov 2014 21:14:24 -0000

A new IETF working group has been proposed in the Routing Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2014-12-02.

Traffic Engineering Architecture and Signaling (teas)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Deborah Brungard <db3546@att.com>
  Lou Berger <lberger@labn.net>

Assigned Area Director:
  Adrian Farrel <adrian@olddog.co.uk>

Mailing list
  Address: teas@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/teas
  Archive: http://www.ietf.org/mail-archive/web/teas/

Charter:

The Traffic Engineering Architecture and Signaling (TEAS) Working
Group is responsible for defining MPLS and GMPLS traffic 
engineering architecture, standardizing the RSVP-TE signaling
protocol, and identifying required related control-protocol 
functions, i.e., routing and path computation element functions. 

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. 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.

The TEAS WG is responsible for:

 a) Traffic-engineering architectures for generic applicability
    across packet and non-packet networks. This includes both 
    networks that include the use of PCE and those that do not.
    The PCE architecture itself is out of the WG scope.

 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 (PCE) to provide general 
    enablers of traffic-engineering systems that 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 RSVP-TE signaling. 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 end-point protection, protection of P2MP 
    LSPs, and inter-domain protection.

 6. YANG models for a Traffic Engineering Database 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 OSPF and ISIS WGs to maintain or extend TE routing 
   mechanisms for MPLS-TE and GMPLS.

 - 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.

In doing this work, the WG will cooperate with external SDOs (such
as the ITU-T and the IEEE 802.1) as necessary.

Milestones:

TBD

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work