Re: [Teas] Comments on draft-busibel-teas-yang-path-computation

["Belotti, Sergio (Nokia - IT/Vimercate)" <[e-mail]>]

Hi Michael,
thanks for your comments. We have just uploaded the 01 version of the draft addressing your comments as described in line below.
Please review, and let us know if you have pending concerns.

Cheers
Italo and Sergio 

-----Original Message-----
From: Scharf, Michael (Nokia - DE/Stuttgart) [mailto:[e-mail]] 
Sent: Wednesday, November 1, 2017 10:19 AM
To: [e-mail]
Cc: [e-mail]
Subject: Comments on draft-busibel-teas-yang-path-computation 

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
> We agree and updated the 01 version accordingly

* Abstract and introduction: If the objective is to standardize the YANG model, the abstract and introduction could focus more on that aspect
> We agree and addressed in new vesrion 01.

* 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.

> A clear PCE definition has been added aligned with IETF concepts and clarified text where it was needed.

* 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.
> As discussed we have updated the text to clarify (e.g. we used packet/optical coordinator term)  

* 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.
> We have modified picture and clarified in a note the real IP connectivity meaning in the picture.

* 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.
> Linked to above comment, we have also modified this picture.

* 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).

> Update text as suggested 

* 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.

> We have modified text using Data center resources terms , not "computing resources" and not virtual machine. Clarified that the Cloud Orchestrator needs to make a decision for optimal connection based on TE Network constraints and data centers resources .

* 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.

> The sections 3, 4, and 6.1 have been restructured and put together in a new section 3 .

* 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.

> Updated text as suggested by Michael.

* 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.

> We agree to avoid ACTN dependence terminology . Updated text accordingly.

* 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 has been restructured to host Yang model description.

* Section 6.2 could be a main section, IMHO.

> Done

* 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?

> We have cleaned and aligned the naming conventions for Yang constructs.

* 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).

> We have tracked this comments open issue in github (#40)


As mentioned earlier, I believe all these issues can be addressed when the document is a WG document.

Thanks

Michael