[Teas] 答复: Proposed charter update

"Dongjie (Jimmy)" <jie.dong@huawei.com> Fri, 26 October 2018 15:20 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2581130DF9; Fri, 26 Oct 2018 08:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AW1LEdyqKIkC; Fri, 26 Oct 2018 08:20:29 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47B21298C5; Fri, 26 Oct 2018 08:20:28 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 84386688DC22F; Fri, 26 Oct 2018 16:20:24 +0100 (IST)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 26 Oct 2018 16:20:26 +0100
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.120]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Fri, 26 Oct 2018 23:20:19 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Lou Berger <lberger@labn.net>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>
Thread-Topic: [Teas] Proposed charter update
Thread-Index: AQHUbTQ/t1+rLogtnUejOkTDIqY74aUxm8VQ
Date: Fri, 26 Oct 2018 15:20:19 +0000
Message-ID: <76CD132C3ADEF848BD84D028D243C927C2BC8FBC@NKGEML515-MBS.china.huawei.com>
References: <CA+YzgTsRGs8tyn4d8jykTLtUNJ=bTXrsG5N+bDpu99mAUufx5g@mail.gmail.com> <7f08f61c-aec4-cbfa-2d8f-e3d9ddf0dfaa@labn.net>
In-Reply-To: <7f08f61c-aec4-cbfa-2d8f-e3d9ddf0dfaa@labn.net>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.189.24]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/ipB2XtJ1GzWUz2-34kLJIRUCuKc>
Subject: [Teas] =?utf-8?b?562U5aSNOiAgUHJvcG9zZWQgY2hhcnRlciB1cGRhdGU=?=
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Oct 2018 15:20:34 -0000

Hi Lou, 

Thanks for the update of the charter. 

In the charter the definition of TE is: "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 "

One questions I'd like to ask is what is the relationship between TE and QoS? RSVP-TE was defined for both explicit path control and bandwidth reservation, in which the bandwidth reservation mechanism follows the Int-Serv QoS mode. Although currently DiffServ is widely used due to its simplicity and scalability, it is not clear whether Diff-Serv is good enough for the emerging or future applications. Thus I'd like to know whether future work about resource reservation and possible extensions related to Int-Serv/Diff-Serv QoS modes will be in the scope of TEAS charter?

Best regards,
Jie

> -----邮件原件-----
> 发件人: Teas [mailto:teas-bounces@ietf.org] 代表 Lou Berger
> 发送时间: 2018年10月26日 22:00
> 收件人: Vishnu Pavan Beeram <vishnupavan@gmail.com>;; TEAS WG
> <teas@ietf.org>;; TEAS WG Chairs <teas-chairs@ietf.org>;
> 主题: Re: [Teas] Proposed charter update
> 
> Hi,
> 
> 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
>      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 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
>            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.
> 
> The changes from the discussion can be found at:
> 
> https://docs.google.com/document/d/1l5y3nH3KmOQbHOMp_RFm1SK5riS5qi1k
> lve--kyUbSU/edit?ts=5bc7216c
> 
> 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:
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_d
> >
> ocument_d_1l5y3nH3KmOQbHOMp-5FRFm1SK5riS5qi1klve-2D-2DkyUbSU_edit-
> 3Fus
> >
> p-3Dsharing&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI
> &r=C
> >
> FHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=6pI1yDFJYCLr4YBDXOEJ
> FxWzJ
> >
> QMmsW5q1X0ic60qgM4&s=XHgp3ISuFZZj_FUiGKK2ZjRndlSyIxgomtfqyEt3DRU&
> e=
> >
> > 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
> >
> >
> 
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas