Early Review of draft-ietf-teas-gmpls-controller-inter-work-11
review-ietf-teas-gmpls-controller-inter-work-11-rtgdir-early-jia-2023-07-03-00
| Request | Review of | draft-ietf-teas-gmpls-controller-inter-work-10 |
|---|---|---|
| Requested revision | 10 (document currently at 17) | |
| Type | Early Review | |
| Team | Routing Area Directorate (rtgdir) | |
| Deadline | 2023-06-30 | |
| Requested | 2023-03-29 | |
| Requested by | Vishnu Pavan Beeram | |
| Authors | Haomian Zheng , Yi Lin , Yang Zhao , Yunbin Xu , Dieter Beller | |
| I-D last updated | 2023-07-03 | |
| Completed reviews |
Genart Last Call review of -14
by Thomas Fossati
(diff)
Rtgdir Last Call review of -14 by Stewart Bryant (diff) Secdir Last Call review of -14 by David Mandelberg (diff) Rtgdir Early review of -11 by He Jia (diff) Opsdir Last Call review of -14 by Yingzhen Qu (diff) Secdir Telechat review of -15 by David Mandelberg (diff) |
|
| Comments |
Version 09 of the document went through a WGLC; Version 10 addresses most of the comments that were raised during WGLC; Authors intend to publish another version to take care of minor editorial nits -- please review version 09 in the meantime. |
|
| Assignment | Reviewer | He Jia |
| State | Completed | |
| Request | Early review on draft-ietf-teas-gmpls-controller-inter-work by Routing Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/rtg-dir/qPoPiV-zyF5jFqodtBmA1gEK7kU | |
| Reviewed revision | 11 (document currently at 17) | |
| Result | Has issues | |
| Completed | 2023-07-03 |
review-ietf-teas-gmpls-controller-inter-work-11-rtgdir-early-jia-2023-07-03-00
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