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