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

["Scharf, Michael (Nokia - DE/Stuttgart)" <[e-mail]>]

I have quickly scanned through the changes. I agree that my comments are addressed in -01.

Thanks

Michael


> -----Original Message-----
> From: Belotti, Sergio (Nokia - IT/Vimercate)
> Sent: Monday, March 05, 2018 5:54 PM
> To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]>;
> [e-mail]
> Cc: [e-mail]
> Subject: RE: Comments on draft-busibel-teas-yang-path-computation
> 
> 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