[Teas] Genart last call review of draft-ietf-teas-gmpls-controller-inter-work-14
Thomas Fossati via Datatracker <noreply@ietf.org> Sun, 23 June 2024 11:30 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from [10.244.2.13] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 0C712C14F6E8; Sun, 23 Jun 2024 04:30:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Thomas Fossati via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.16.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171914225568.114483.9127212926630846642@dt-datatracker-ff65ff8f7-whn7d>
Date: Sun, 23 Jun 2024 04:30:55 -0700
Message-ID-Hash: ZOFFKAFNASKMGCTYGPEO7W7XHQQNBZQW
X-Message-ID-Hash: ZOFFKAFNASKMGCTYGPEO7W7XHQQNBZQW
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-teas-gmpls-controller-inter-work.all@ietf.org, last-call@ietf.org, teas@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Thomas Fossati <thomas.fossati@linaro.org>
Subject: [Teas] Genart last call review of draft-ietf-teas-gmpls-controller-inter-work-14
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/2wGBvc1gOO1Kg7mzlq70LVvbzfQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>
Reviewer: Thomas Fossati Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-teas-gmpls-controller-inter-work-?? Reviewer: Thomas Fossati Review Date: 2024-06-23 IETF LC End Date: 2024-06-26 IESG Telechat date: Not scheduled for a telechat Summary: The document is clear. Major issues: None Minor issues: My complete lack of expertise in the field prevents me from making concrete suggestions (and I apologise for that), but I've found the "Manageability Considerations" section to be a bit lacking in terms of content and exposition - at least compared to the rest of the document. The "Security Considerations" are also a bit dry. In particular, collecting all the references that apply in one place would be handy. Nits/editorial comments: A few editorial suggestions follow. Abstract, paragraph 5: OLD: On the other hand, with the development of software-defined transport networking technology, a set of NEs can be controlled via centralized controller hierarchies to address the issues from multi- domain, multi-vendor, and multi-technology. An example of such centralized architecture is Abstraction and Control of Traffic Engineered Networks (ACTN) controller hierarchy described in RFC 8453. NEW: The advancement of software-defined transport networking technology enables a group of network elements to be managed through centralized controller hierarchies. This helps to tackle challenges arising from multiple domains, vendors, and technologies. An example of such a centralized architecture is the Abstraction and Control of Traffic Engineered Networks (ACTN) controller hierarchy, as described in RFC 8453. Abstract, paragraph 6: OLD: 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. NEW: Both the distributed and centralized control planes have their respective advantages and should complement each other in the system, rather than competing. This document outlines how the GMPLS distributed control plane can work together with a centralized controller system in a transport network. Section 1., paragraph 3: OLD: GMPLS can be applied for the Network Element (NE) level control in such centralized controller architectures. A centralized controller may support GMPLS enabled domains and 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 the GMPLS control plane interworks with a centralized controller system in a transport network. NEW: GMPLS can be used to control Network Elements (NE) in such centralized controller architectures. A centralized controller may support GMPLS-enabled domains and communicate with a GMPLS-enabled domain where the GMPLS control plane handles service provisioning from ingress to egress. In this scenario, the centralized controller sends a request to the entry node and does not need to configure all NEs along the path within the domain from ingress to egress, thus leveraging the GMPLS control plane. This document describes how the GMPLS control plane interworks with a centralized controller system in a transport network. Section 2., paragraph 1: OLD: This section provides an overview of the GMPLS control plane and centralized controller systems and the interactions between the GMPLS control plane and centralized controllers, for transport networks. NEW: This section presents an overview of the GMPLS control plane, centralized controller systems, and their interactions in transport networks. Section 2., paragraph 2: OLD: A transport network [RFC5654] is a server-layer network designed to provide connectivity services for client-layer connectivity. This facilitates client traffic to be carried transparently across the server-layer network resources. NEW: A transport network [RFC5654] is a server-layer network designed to provide connectivity services for client-layer connectivity. This setup allows client traffic to be carried seamlessly across server-layer network resources. Section 5.3., paragraph 1: OLD: The PCE has been introduced in [RFC4655] as a functional component that provides services to compute paths in a network. In [RFC5440], the path computation is accomplished by using the TED, which maintains a view of the link resources in the network. The emergence of PCE efficiently improves the quality of network planning and offline computation. However, there is a risk that the computed path may be infeasible if there is a diversity requirement, because stateless PCE has no knowledge about the former computed paths. NEW: The PCE was first introduced in [RFC4655] as a functional component that offers services for computing paths within a network. In [RFC5440], path computation is achieved using the TED, which maintains a view of the link resources in the network. The introduction of PCE has significantly improved the quality of network planning and offline computation. However, there is a potential risk that the computed path may be infeasible when there is a diversity requirement, as stateless PCE lacks knowledge about previously computed paths. Section 5.3., paragraph 4: OLD: In a centralized controller system, the PCE can be implemented in a centralized controller, and the centralized controller performs path computation according to its local policies. On the other hand, the PCE can also be placed outside of the centralized controller. In this case, the centralized controller acts as a PCC to request path computation to the PCE through PCEP. One of the reference architecture can be found in [RFC7491]. NEW: In a centralized controller system, the PCE can be implemented within the centralized controller. The centralized controller then calculates paths based on its local policies. Alternatively, the PCE can be located outside of the centralized controller. In this scenario, the centralized controller functions as a PCC and sends a path computation request to the PCE using the PCEP. A reference architecture for this can be found in [RFC7491]. Section 7.5., paragraph 1: OLD: Given the important role in the network, the reliability of controller is critical. If the controller is shut down or disconnected from the network, it is highly desirable that all of the services currently provisioned in the network continue to function and carry traffic. Furthermore, protection switching to pre-established paths should also function. Additionally, it is desirable to provide protection mechanisms, such as redundancy, so that full operational control can be maintained even when one instance of the controller fails. This can be either achieved by controller back up or functionality back up. There are several of controller backup or federation mechanisms in the literature. It is also more reliable to have some function back up in the network element, to guarantee the performance in the network. NEW: The reliability of the controller is crucial due to its important role in the network. It is essential that if the controller is shut down or disconnected from the network, all currently provisioned services in the network continue to function and carry traffic. In addition, protection switching to pre-established paths should also work. It is desirable to have protection mechanisms, such as redundancy, to maintain full operational control even if one instance of the controller fails. This can be achieved through controller backup or functionality backup. There are several controller backup or federation mechanisms in the literature. It is also more reliable to have function backup in the network element to guarantee performance in the network.
- [Teas] Re: Genart last call review of draft-ietf-… Linyi (Yi)
- [Teas] Genart last call review of draft-ietf-teas… Thomas Fossati via Datatracker