[Teas] Rtgdir early review of draft-ietf-teas-gmpls-controller-inter-work-11

He Jia via Datatracker <noreply@ietf.org> Mon, 03 July 2023 15:20 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8177EC15152E; Mon, 3 Jul 2023 08:20:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: He Jia via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-teas-gmpls-controller-inter-work.all@ietf.org, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168839761047.2375.2013146980278262042@ietfa.amsl.com>
Reply-To: He Jia <hejia@huawei.com>
Date: Mon, 03 Jul 2023 08:20:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/VvfBq2IZh9uNp5gK0dUAIN-B_Is>
Subject: [Teas] Rtgdir early review of draft-ietf-teas-gmpls-controller-inter-work-11
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 03 Jul 2023 15:20:10 -0000

Reviewer: He Jia
Review result: Has Issues

Summary:

I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG.

Comments:

1) Section 2.1 describes GMPLS control plane as a distributed control system.
"Controller" is used in this section as distributed on each node, while
"controller" in most of the other places in this draft indicates a centralized
controller. This may cause confusion. A GMPLS control plane instance is also
used in this section to support the NE level control. It is suggested to align
the terminologies and eliminate confusion.

2) Section 2.3,  the logic of the two paragraphs under Figure 1 is not too
clear. What does "Alternatively" in the second paragraph intend to substitute?
The first paragraph already describes domain 1 uses NETCONF/YANG and/or PCEP.
The second paragraph (starting with "Alternatively")  describes NETCONF again.
It is not an alternative but an enhanced descripion, is it? Besides, is the
description of MDSC also the same in these two paragraphs?

3) Section 5.1, is "Yang Path Computation requests [PAT-COMP]" the only way for
controller interaction in case of path computation?

Nits:

1) Section 4.3, s/notification that permits to notify the client about topology
changes/notification of topology changes to the client 2) Section 5.1,
s/service e2e path setup/e2e service path setup 3) Section 5.2, TED lacks of an
expanded explanation, although the explanation appears later in Section 5.3. 
s/TED/ Traffic Engineering Database (TED) in Section 5.2 4) Section 7.1, s/The
topology on network element/The topology on a network element 5) Section 7.3.3,
the first paragraph, s/the detail extensions/the detailed extensions 6) Section
7.4.3, the last paragraph, s/could be taken place/could take place 7) Section
7.4.4, the fourth paragraph, s/failure occurs.../failure that occurs... 8)
Section 9, s/The security requirements in both system still applies/The
security requirements in both systems still apply