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

["Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <[e-mail]>]

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:[e-mail]] 代表 Vishnu Pavan Beeram
发送时间: 2019年5月28日 15:49
收件人: TEAS WG <[e-mail]>
抄送: TEAS WG Chairs <[e-mail]>
主题: 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 <[e-mail]<mailto:[e-mail]>> 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