Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
I have two points for discussion: (1) If this document was subject to the approval requirements for standards action, it would basically be suffering from "death by abstain"; this seems like a good signal for the IESG to discuss whether it makes sense to approve this document even though the more-lenient document-action requirements would otherwise let it go forward. (2) The document seems incomplete to me. It has some aspects of being all/any of a use-cases document, an architecture document, and an applicability analysis, but does not seem to have a complete treatment for any of them. To be clear, there is enough in the document to indicate that the topic merits further work, and there are some interesting results, but I'm not sure that publication as an RFC is appropriate for this document in this form. Specifically: (2a) use-cases: we see the examples of star topology with BRAS/SR and the simulated network in Figure 6, but there is not much discussion of where these (or similar) scenarios arise in practice, how common they are, and how closely the simulation reflects actual usage. (2b) architecture: a very high-level picture is given ("use a PCE to engineer some of the IP traffic on a network and improve overall efficiency"), but we don't see much about how PCCs will be involved and apply the computed paths or what requirements will need to be met by the protocols and components used to instantiate the architecture (2c) applicability: we see some scenarios where the proposed technology shows drastic improvement over the alternative selected for comparison, but there is little to give confidence that this reflects a broad maxima that is robust to environmental variations. Is the alternative selected for comparison an appropriate one for the cases in question? How would the propsal react in the face of changes in the environment it runs in, such as link or node failure, changes in the baseline usage, or traffic spikes? What timescale can it react in and what level of visibility does the PCE need into current conditions in order to be reliable?
If we're using a PCE in a native IP network, how do the computed routes get applied; are we using source routing or just being careful about the prefixes in use? (Are there going to be any scaling concerns?) Section 3.1 I don't understand what Figure 1 is intending to convey. Are "Private Cloud Site" and "Public Cloud Site" supposed to be separate boxes on the edge of the distributed control network? Why is the "Cloud Based Application" in neither of the named clouds? Section 3.2 Network topology within a Metro Area Network (MAN) is generally in a star mode as illustrated in Figure 2, with different devices "Generally" within what scope, commercial ISPs? I know of things that could be called MANs that use a different topology. Section 4.1 nit: several sentences are missing spaces after the full stop. Section 4.2 Is a fully-linked core of 100 nodes representative of typical deployments? That's a lot of links not going to customers! Section 4.3 The traffic matrix is generated based on the link capacity of topology. [...] I don't know how to interpret this statement. It does sound like the traffic matrix is generated in a somewhat arbitrary fashion, with no stated effort to keep it aligned with real-world traffic patterns.
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.
==[ 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.
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.
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"  from the WG, I have decided to ABSTAIN and not stand in the way of publication.  https://datatracker.ietf.org/doc/draft-ietf-teas-native-ip-scenarios/shepherdwriteup/
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.
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