italobusi
commented
6 years ago Regarding comment 4.
The implicit assumptions in section 2.1 is that the entity above the Optical Controller has full visibility of the IP domain topology and an abstracted view of the Optical domain topology but needs to provide an optimal multi-layer path.
For example, looking at Figure 3, If it was only an optical connectivity use case, the Optical domain controller could know that the best optical path is VP1-VP4 but only the entity above the Optical Controller can compute the best multi-layer path by knowing the IP topology and the paths computed by the Optical domain controller.
We understand that there are more complex IP/optical integration use cases but we would prefer not to create too much dependency between this draft and the work to be done in TEAS to clarify how ACTN applies to the IP/optical integration use cases.
We are thinking about three possible resolutions: 1) clarifying the assumptions above (and in particular the absence of topology abstraction between the IP controller and the Orchestrator) 2) rename the Orchestrator as "IP/Optical Integration APP" clarifying that this APP can be part of the IP controller 3) merge the Orchestrator and the IP controller into a single entity
What do you think?
Sergio and Italo
sergiobelotti
Hi all,
I have read draft-busibel-teas-yang-path-computation-03 again after a while, and this has triggered some comments. As far as I can see, my observations are mostly about content organization, and none of these comments affects the YANG model itself. As a result, I believe these are all non-blocking comments that can be sorted out when the I-D is a WG document. The document is certainly the right starting point for a WG document. I support WG adoption.
As I am an author, I have explicitly flagged comments related own text.
Comments:
"Intended status: Informational": I believe the YANG model should be published on standards track
Abstract and introduction: If the objective is to standardize the YANG model, the abstract and introduction could focus more on that aspect
Introduction and other sections: The exact use of the term "PCE" may have to be reviewed, e.g., in statements such as "... allowing the Path Computation Element (PCE) within the Orchestrator to perform multi-domain path computation...". An orchestrator may not necessarily implement exactly what I think is defined as "PCE", e.g., when the orchestrator deals with multi-point services. But this is orthogonal to the content of the document.
Section 2.1: I think this use case 1 should be renamed, as there is no real IP/optical integration in the use case. To me, the use case is about providing optical connectivity, not about any multi-layer functionality in the IP layer. Also, I think the use case could also be applied to non-IP traffic - the question what traffic is transported IMHO does not affect the path computation in scope of the document.
Figure 1: This figure should either be improved or removed. One could understand from this rendering that the considered routers in the IP network are all edge routers (PEs or ASBR). If a full IP network should be rendered, P routers would have to be shown, too, in order to make the figure realistic. As already explained, the IP network topology and the "IP controller" probably do not matter for this use case. They should IMHO be removed as that aspect doesn't matter for this document. For the use case only the interface between the orchestrator and the optical domain controller matters.
Figure 2: This figure is not correct in the IP layer. For instance, the IP domain controller will know the IP links (IGP links) between the "IP nodes", and these IP links are missing in this figure. I find this figure in the IP layer confusing. Anyway, I don't think this figure is needed for the following discussion of how to provision optical services.
Section 2.1.1: "In this use case, the orchestrator needs to setup an optimal path between two IP routers R1 and R2." This wording is confusing as "path" could also refer to an IP path. I think a better alternative would be: "In this use case, the orchestrator needs to setup optimal (optical) connectivity between two IP routers R1 and R2" (or whatever other term that cannot be confused).
Section 2.3: This use case 3 makes some assumptions that can be questioned, e.g., "In this use case, a virtual machine within Data Center 1 (DC1) needs to transfer data to another virtual machine that can reside either in DC2 or in DC3.". I think we have already discussed in the context of an ACTN framework whether a WAN controller would really deal with individual virtual machines, and whether this is a useful granularity for an EMS/NMS/controller in the WAN. For the ACTN framework, I think the consensus was to focus on the attachment points of the data center, not VMs. At minimum, a similar change seems to make sense here. In addition, this use case also neglects the impact of the data center network, which would require a lot of additional discussion. For connectivity provisioning, I think use case 3 is identical to use case 1, and beyond that there are no clear requirements. As a result, use case 3 could IMHO be removed from the document without any impact.
Section 3: "Interactions with TE Topology": If the objective is to standardize a YANG model, one might expect in a section with this title a discussion on how the YANG models uses the TE model, e.g., how the RPC is augmented etc. Instead I believe this section more focuses on why a path computation YANG model is needed. The content is highly useful, but I think it overlaps with Section 4. I think Section 3 and 4 (and partly even Section 6) could be merged into an overall motivation section with less overlap. The numerical examples could perhaps also be moved to an appendix. Note that I do believe that the numerical examples are very useful and should be included in the document - but it may not have to be normative.
Section 4 (well, my own text): "Path computation requests should be closely aligned with the YANG data models that provide (abstract) TE topology information, i.e., [TE-TOPO] as well as that are used to configure and manage TE Tunnels, i.e., [TE-TUNNEL]." This and following text is very old wording from early drafts. I think this objective is achieved now, and this text can be rephrased in a follow-up version of the I-D. I apologize for the legacy text, I should have looked at this earlier.
Section 5: While the document may reference ACTN in the introduction as context, I believe the main content of the I-D should be agnostic of whether the ACTN framework is assumed, or not. Path computation can also be used in context outside of ACTN, e.g., within systems that make different assumptions and design choices. I think this draft should be agnostic to ACTN outside e.g. the introduction. Otherwise e.g. the I-D would have to be updated if the ACTN framework is modified. And I don't think that any dependency on ACTN is needed for the actual modeling. As this draft is useful no matter whether an implementation follows the ACTN assumptions or not, I think in Section 5 all ACTN terminology should be removed.
If the YANG model shall be the main contribution, Section 6 has to be extended with an introduction of the actual YANG model and its modeling design choices, e.g., how to use "synchronization" in the YANG model.
Section 6.2 could be a main section, IMHO.
Section 6.2.1: I wonder why "pathComputationService" and some few other YANG constructs uses capital letters; this is certainly possible but is it intentional?
In a later version of the ID, it may make sense to include an actual example for a path computation request (e.g., for XML encoding in NETCONF).
As mentioned earlier, I believe all these issues can be addressed when the document is a WG document.
Thanks
Michael