Re: [Teas] Proposed charter update

Lou Berger <> Fri, 26 October 2018 14:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 935CA130DDF for <>; Fri, 26 Oct 2018 07:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (768-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wHCJqkgFIjJ5 for <>; Fri, 26 Oct 2018 07:00:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D86D212D4F1 for <>; Fri, 26 Oct 2018 07:00:00 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 3E775215D50 for <>; Fri, 26 Oct 2018 07:59:59 -0600 (MDT)
Received: from ([]) by cmsmtp with ESMTP id G2edgJuzfj0soG2edgtq3N; Fri, 26 Oct 2018 07:59:59 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=kRgE54wEOhowywFFRk4oinoOn/LMYopGMGVW9aTLwHc=; b=gqpweSc2v5laKYwDQHQik6ufGm recTPGqFWslAURz+CgC7SirpZ10YZQudGh3oCI249dJmjowlg25aczVFEaGOKVnSBAbe2F+9L1m25 AJyz+PG6CDn9Zwc1DJccCt1CI;
Received: from ([]:53448 helo=[IPv6:::1]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <>) id 1gG2ec-0028pD-SG; Fri, 26 Oct 2018 07:59:58 -0600
To: Vishnu Pavan Beeram <>, TEAS WG <>, TEAS WG Chairs <>
References: <>
From: Lou Berger <>
Message-ID: <>
Date: Fri, 26 Oct 2018 09:59:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-L: No
X-Exim-ID: 1gG2ec-0028pD-SG
X-Source-Sender: ([IPv6:::1]) []:53448
X-Email-Count: 12
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <>
Subject: Re: [Teas] Proposed charter update
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Oct 2018 14:00:05 -0000


The discussion on the charter seems to have closed.  The plan is for us 
(chairs) to summarize the changes in Bangkok, and then get the changes 
approved by the IESG.  As charters are actually owned by the AD, Deborah 
will be the one moving the proposed revision through  this process.

The version that resulted from the  discussion is:

     Draft Update to TEAS WG Charter

     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

      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

        f) Definition and extension of management and security
           techniques for for TP 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

       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

        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

       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

        - With the MPLS WG to maintain and extend MPLS-TE protocol
          mechanisms and to determine whether they should be

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

The changes from the discussion can be found at:

Lou (and Pavan)
On 10/8/2018 2:49 AM, Vishnu Pavan Beeram wrote:
> Hi,
> Over the past few months we've noted that our charter could use a bit of
> an update to match the current state of TEAS and other working groups.
> We've taken a pass at this and have a proposed revision.  Once the WG
> agrees on changes, we'll pass those changes along to our AD who is the
> actual owner of our charter.  The text is enclosed below as well as
> available with changes tracked at:
> Please discuss any proposed changes on the list, i.e., changes to the
> charter that are suggested in the google-doc but not agreed to here 
> will be ignored.
> We'd like to have the changes agreed to by the end of this month so the
> IESG may have time to review/act before  IETF103.
> Thank you,
> Pavan and Lou