[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] 答复: Proposed charter update
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
- [Teas] Proposed charter update Vishnu Pavan Beeram
- Re: [Teas] Proposed charter update Andrew G. Malis
- Re: [Teas] Proposed charter update Lou Berger
- Re: [Teas] Proposed charter update Andrew G. Malis
- Re: [Teas] Proposed charter update Vishnu Pavan Beeram
- Re: [Teas] Proposed charter update Lou Berger
- [Teas] 答复: Proposed charter update Aijun Wang
- Re: [Teas] Proposed charter update Dhruv Dhody
- Re: [Teas] 答复: Proposed charter update Lou Berger
- Re: [Teas] Proposed charter update Lou Berger
- Re: [Teas] Proposed charter update Dhruv Dhody
- [Teas] 答复: 答复: Proposed charter update Aijun Wang
- Re: [Teas] 答复: 答复: Proposed charter update Lou Berger
- Re: [Teas] 答复: 答复: Proposed charter update Aijun Wang
- Re: [Teas] Proposed charter update Lou Berger
- [Teas] 答复: Proposed charter update Dongjie (Jimmy)