[Teas] 答复: WG adoption poll - draft-zheng-teas-gmpls-controller-inter-work

"Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <zhenghaomian@huawei.com> Fri, 31 May 2019 09:55 UTC

Return-Path: <zhenghaomian@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 C85871200B2; Fri, 31 May 2019 02:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 FHmBn9NJiTHW; Fri, 31 May 2019 02:55:14 -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 E88AF12001B; Fri, 31 May 2019 02:55:13 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C081387F1C66B049A755; Fri, 31 May 2019 10:55:11 +0100 (IST)
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 31 May 2019 10:55:11 +0100
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 31 May 2019 10:55:11 +0100
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Fri, 31 May 2019 10:55:10 +0100
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.177]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0439.000; Fri, 31 May 2019 17:55:06 +0800
From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <zhenghaomian@huawei.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>
CC: TEAS WG Chairs <teas-chairs@ietf.org>
Thread-Topic: [Teas] WG adoption poll - draft-zheng-teas-gmpls-controller-inter-work
Thread-Index: AQHVFJExZz2fb7GlfU+YLSnm2+ZHPaZ/pGoAgAVd/SA=
Date: Fri, 31 May 2019 09:55:05 +0000
Message-ID: <E0C26CAA2504C84093A49B2CAC3261A43B7E4594@dggeml511-mbx.china.huawei.com>
References: <CA+YzgTsnw95oMFswug+RcVUPC9tpCdVdrdvPyOr8xxELxvfQwQ@mail.gmail.com> <CA+YzgTuDEpxUg4iTG5P0ipR=VbuKqVj=NzzTa82FyPsojk8APA@mail.gmail.com>
In-Reply-To: <CA+YzgTuDEpxUg4iTG5P0ipR=VbuKqVj=NzzTa82FyPsojk8APA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.57.78.212]
Content-Type: multipart/alternative; boundary="_000_E0C26CAA2504C84093A49B2CAC3261A43B7E4594dggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/7MxW1swwqErUk7CICb0ifvVIBB0>
Subject: [Teas] =?utf-8?b?562U5aSNOiAgV0cgYWRvcHRpb24gcG9sbCAtIGRyYWZ0?= =?utf-8?q?-zheng-teas-gmpls-controller-inter-work?=
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, 31 May 2019 09:55:17 -0000

Hi Pavan,

Thanks for your questions. It seems the concern is about that the document is lacking some clarity what the document is trying to address. We tried to describe the scope of the document in the abstract and in the introduction, we listed the related text here as italic:

Last paragraph of the abstract:
   Instead of competing with each other, both the distributed and the  centralized control plane have their own advantages, and should be  complementary in the system. This document describes how the GMPLS distributed control plane can interwork with a centralized controller system in a transport network.

Introduction:
   Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends MPLS to support different classes of interfaces and switching capabilities such as Time-Division Multiplex Capable (TDM), Lambda Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network element (NE) running a GMPLS control plane collects network information from other NEs and supports service provisioning through signaling in a distributed manner. More generic description for Traffic-engineering networking information exchange can be found in [RFC7926].

   On the other hand, Software-Defined Networking (SDN) technologies have been introduced to control the transport network in a centralized manner. Central controllers can collect network information from each node and provision services to corresponding nodes. One of the examples is the Abstraction and Control of Traffic Engineered Networks (ACTN) [RFC8453], which defines a hierarchical architecture with Provisioning Network Controller(PNC), Multi-domain Service Coordinator(MDSC) and Customer Network Controller(CNC) as central controllers for different network abstraction levels. A Path Computation Element (PCE) based approach has been proposed as Application-Based Network Operations (ABNO) in [RFC7491].

   In such centralized controller architectures, GMPLS can be applied for the NE-level control. A central controller may support GMPLS enabled domains and may interact with a GMPLS enabled domain where the GMPLS control plane does the service provisioning from ingress to egress. In this case the centralized controller sends the request to the ingress node and does not have to configure all NEs along the path through the domain from ingress to egress thus leveraging the GMPLS control plane. This document describes how GMPLS control interworks with centralized controller system in transport network.
The text above is trying to address the interworking of GMPLS control network domains and domains controlled by centralized SDN controllers (hybrid network architecture), which existing RFCs/I-Ds are not addressing. The document is not trying to compare the two different control architectures (distributed vs. centralized). We, the authors of this draft, believe that operators have the choice to select one of the two control architectures for their domains, which are complementary and hence domain interworking of a heterogeneous network is an important aspect.
If you believe that the scope of the draft is not described clearly enough you’re welcome to suggest some improvements. According to previous discussion this was agreed to be done after WG adoption. Text dealing with non-headend (TE Tunnel transit) control is certainly something that can be added to section 7.

Please let us know if you have further concerns.

Best wishes,
Haomian

发件人: Teas [mailto:teas-bounces@ietf.org] 代表 Vishnu Pavan Beeram
发送时间: 2019年5月28日 15:49
收件人: TEAS WG <teas@ietf.org>;
抄送: TEAS WG Chairs <teas-chairs@ietf.org>;
主题: Re: [Teas] WG adoption poll - draft-zheng-teas-gmpls-controller-inter-work

[Chair hat off]

Authors, Hi!

I would like to see the following discussed on the list:

— Please explain what is it that this document is trying to say that hasn’t been discussed before (imho, this isn’t clearly articulated in the document).. There are sufficient number of existing documents that discuss how GMPLS paths can be computed, placed, optimized, rerouted and maintained in the network. There are also a fair number of documents that discuss how these paths can be controlled (at the head end) by a PCE based controller. Is the document just trying to say that these GMPLS paths can also be controlled (at the head end) via non-PCEP means (is that all that this document is trying to say)?

— In a document about the interworking of “distributed and centralized control”, I would have liked to see some discussion on the pros and cons of (/recommendations on) distributing or centralizing certain TE functions. Is non-headend (TE Tunnel transit) control out of scope? Please do explain the overall scope of this document?

Regards,
-Pavan (as a WG participant)

On Mon, May 27, 2019 at 8:35 AM Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>> wrote:
All,

This is start of a two week poll on making
draft-zheng-teas-gmpls-controller-inter-work-03 a TEAS working group document.
Please send email to the list indicating "yes/support" or "no/do not
support". If indicating no, please state your reservations with the
document. If yes, please also feel free to provide comments you'd
like to see addressed once the document is a WG document.

The poll ends June 10th.

Thanks,
Pavan and Lou