Scenarios and Simulation Results of PCE in a Native IP Network
RFC 8735
Yes
No Objection
Abstain
Note: This ballot was opened for revision 08 and is now closed.
Alvaro Retana Abstain
The integration of distributed protocols and centralized control in a Hybrid network is not a new topic. I feel conflicted about the publication of this document as an RFC because it doesn't contribute much to the existing literature...except maybe for the explicit suggestion of using "PCE in a native IP network". Specifically, the interaction of the distributed and centralized components can result in added operational complexity and new security vulnerabilities. Neither of these issues are mentioned. I appreciate the work that the authors have put into this document, but because of it being incomplete and only having "tepid support" [1] from the WG, I have decided to ABSTAIN and not stand in the way of publication. [1] https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/shepherdwriteup/
Roman Danyliw Abstain
==[ Summary I am balloting as an ABSTAIN because the primary contribution of this draft appears to be the simulation results. However, these results appear to be already published in greater detail in http://ieeexplore.ieee.org/document/8657733. I have no commentary on the utility of the CDDR Scenarios found in Section 3. ==[ Details I have reservations about the approach taken in Section 4. As a stand-alone write-up, it insufficiently describes the simulations in question. Furthermore, the content in this section copies verbatim or re-phrases the source material of these simulations from an already published academic paper (without citation). See http://ieeexplore.ieee.org/document/8657733. In particular: -- The entirely of Section 4.1 (text and diagrams) is a cut-and-paste from Section V.B of the academic paper. -- The simulation results of Section 4.4 in this draft align with the analysis in Section V.C of the academic paper. -- The simulation results of Section 4.5 in this draft align with analysis in Section V.D of the academic paper. Without the benefit of the academic paper cited above, I would have had the following feedback on Section 4: -- Section 4. What use case is being simulated isn’t clear. The text is Section 3.1 states that “Section 4 of this document describes the simulation results of this use case”. However, the topology for the simulation described in Section 4.2 looks different than the one in Figure 1 (of Section 3.1). -- Section 4. A few questions about the simulation design: Only the results were presented. How were the simulations constructed and results evaluated? Section 4.0 states that this section “illustrate[s the] CCDR algorithm”. Where is that algorithm defined? Is that Section 7 of draft-ietf-teas-pce-native-ip or http://ieeexplore.ieee.org/document/8657733? What specific algorithms was used to create the contrasting charts in Figures 7 and 8? Section 4.2 said that “[t]he number of links connecting one edge node to the set of core nodes is randomly between 2 to 30, and the total number of links is more than 20000.” Section 4.3 said that “[i]n the CCDR simulation, the dimension of the traffic matrix is 500*500. About 20% links are overloaded when the Open Shortest Path First (OSPF) protocol is used in the network.”, What is the basis of these choices? Are they representative of a given use case? What is the relationship between the Sections 4.2 and 4.3, and the simulation results in Sections 4.4 and 4.5 Additional feedback includes: -- Section 5. The purpose of this section isn’t clear. -- Missing references Section 1. A reference to CCDR is needed. Also, given that CCDR is the basis of the simulation, it needs to be normative. Section 5. A reference is needed for the IEEE document.
Éric Vyncke Abstain
I share Alvaro's and TSV reviewer feeling about this is not a usual RFC but rather a scientific paper (even if the results are not really a surprise). So, I am abstaining. Some comments though: - why using OSPF and not IS-IS for the comparison ? Not that it would change a lot IMHO - when using generated topologies, little is written on how it is generated (as it could introduce some bias changing the results of section 4.4) - using the new format for XML2RFC could have included SVG for graphics Interesting read anyway -éric
(Deborah Brungard; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
Thanks for the updates in the -11! This version does a much better job at convincing the reader that CCDR can be an effective solution to the stated problems in real-world networks.
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
(Alissa Cooper; former steering group member) Abstain
I agree with Éric and Alvaro. It's not clear what is gained by publishing this as an RFC rather than a research paper, especially given the lack of support in the WG.
(Barry Leiba; former steering group member) (was No Objection) Abstain
In light of Roman's comments about the academic paper, I agree and join in the "Abstain" group. It would be better just to have the other documents refer to the academic paper, rather than to republish a portion of that paper in the RFC series.
(Martin Vigoureux; former steering group member) Abstain
Thank you Roman for finding the paper. It seems to me that there is much more details in the paper than in the draft. As such I don't really see the value of publishing a subset as a draft and then an RFC.