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

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 27 May 2019 08:35:54 -0500

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

---

From: "Beller, Dieter (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Mon, 27 May 2019 13:51:59 +0000

Hi Pavan, Lou, all,

yes/support as co-author.

Thanks,
Dieter

On 27.05.2019 15:35, Vishnu Pavan Beeram wrote:
All,

draft-zheng-teas-gmpls-controller-inter-work-03 a TEAS working group document.

The poll ends June 10th.

Thanks,
Pavan and Lou

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 28 May 2019 11:43:22 +0800

Hi, All:

Support its adoption.

I think this document gives the overall structural  information for the necessary/benefits/components of central control within traditional GMPLS network.

We have the similar idea to proposal for the Native IP network:

https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/

https://datatracker.ietf.org/doc/draft-ietf-teas-pce-native-ip/

https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/

Based on these proposals, we think that it is possible in future to let the IP and transport converge to provide customers the seamless services and utilize the underlay resources more efficiently.

One proposal for this draft is that about the topology retrieval methods:

Draft https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/  has proposed to achieve this goal via the PCEP protocol, which is similar with the BGP-LS。 I think gathering the topology via the TCP protocol(via BGP-LS/PCEP-LS) will be more flexible for the deployment of Controller.  

I think the authors can include such approach in current polling draft for further discussion.

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Vishnu Pavan Beeram [mailto:[email-masked]] 
发送时间: 2019年5月27日 21:36
收件人: TEAS WG
抄送: TEAS WG Chairs
主题: [Teas] WG adoption poll - draft-zheng-teas-gmpls-controller-inter-work

All,

The poll ends June 10th.

Thanks,
Pavan and Lou

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 28 May 2019 13:28:40 +0800

yes/support

======================
YUNBIN XU   徐云斌
 
宽带网络研究部
中国信息通信研究院（工业与信息化部电信研究院）技术与标准研究所
 
Research Institute of Telecommunications Transmission (RITT),
China Academy of Information Communications Technology(CAICT), MIIT
 
TEL: 86-18601328841，86-10-62300112
E-mail: [email-masked], [email-masked]  
 
From: Vishnu Pavan Beeram
Date: 2019-05-27 21:35
To: TEAS WG
CC: TEAS WG Chairs
Subject: [Teas] WG adoption poll - draft-zheng-teas-gmpls-controller-inter-work
All,

The poll ends June 10th.

Thanks,
Pavan and Lou

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 28 May 2019 02:49:08 -0500

[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)

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 28 May 2019 09:40:29 +0000

Hi Pavan, Lou, all,

"yes/support"

Thanks
Sergio (as co-author)

From: Teas <[email-masked]> On Behalf Of Vishnu Pavan Beeram
Sent: Monday, May 27, 2019 3:36 PM
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: [Teas] WG adoption poll - draft-zheng-teas-gmpls-controller-inter-work

All,

The poll ends June 10th.

Thanks,
Pavan and Lou

---

From: Italo Busi <[email-masked]>
Date: Tue, 28 May 2019 11:33:15 +0000

yes/support

Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : [email-masked]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

From: Vishnu Pavan Beeram [mailto:[email-masked]]
Sent: lunedì 27 maggio 2019 15:36
To: TEAS WG <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>
Subject: [Teas] WG adoption poll - draft-zheng-teas-gmpls-controller-inter-work

All,

The poll ends June 10th.

Thanks,
Pavan and Lou

---

From: Lizhenbin <[email-masked]>
Date: Tue, 28 May 2019 13:01:44 +0000

yes/support

Best Regards,
Zhenbin (Robin)

From: Vishnu Pavan Beeram<mailto:[email-masked]>
Date: 2019-05-27 21:35
To: TEAS WG<mailto:[email-masked]>
CC: TEAS WG Chairs<mailto:[email-masked]>
Subject: [Teas] WG adoption poll - draft-zheng-teas-gmpls-controller-inter-work
All,

The poll ends June 10th.

Thanks,
Pavan and Lou

---

From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <[email-masked]>
Date: Fri, 31 May 2019 09:55:05 +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:[email-masked]] 代表 Vishnu Pavan Beeram
发送时间: 2019年5月28日 15:49
收件人: TEAS WG <[email-masked]>
抄送: TEAS WG Chairs <[email-masked]>
主题: Re: [Teas] WG adoption poll - draft-zheng-teas-gmpls-controller-inter-work

[Chair hat off]

Authors, Hi!

— 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,

On Mon, May 27, 2019 at 8:35 AM Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>> wrote:
All,

The poll ends June 10th.

Thanks,
Pavan and Lou

---

From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <[email-masked]>
Date: Fri, 31 May 2019 10:00:08 +0000

Yes/Support.

Best wishes,
Haomian (as a co-author)

All,

The poll ends June 10th.

Thanks,
Pavan and Lou