Hi,

I have reviewed this document (draft-ietf-alto-path-vector-19) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

This draft proposes an extension to the ALTO protocol to allow the definition of Abstract Network Elements (ANEs) on a path between two endpoints that can be considered when orchestrating connectivity between those endpoints, rather than just computing based on the abstract cost of a path.  A Path Vector allows a set of such ANEs to be defined for a path.  

Caveats:

I previously reviewed the -17 version of the draft; this review focuses on how the points from that review have been addressed.

Overall:

The authors have addressed my comments from the previous review of -17.  The comments on my review from Kai were very helpful.  I believe the document is now Ready for publication from my perspective.

General comments:

The new bottleneck and service edge resource examples in 4.2, and the new text in 5.1, are useful additions to the draft, helping clarify the form of the ANEs.

The clarifications made are also useful, e.g. on the use of “domain”, around the information exposed regarding topology, and regarding exposing potential capacity available rather than actually making specific reservations of capacity.

I think it would still be useful to add further text on the single “entity domain” concept, and to be explicit about what that means in practice.  The new text in 6.2 is useful, but stating clearly what the practical implication is would be helpful.

Nit:

The authors have addressed my comments about use cases, SENSE and WLCG in 4.2.1, though where they say “Applications such as large-scale data analytics” I would expect to see “Applications which need to perform large scale data transfers” rather than explicit saying “analytics”.  It’s the transfer that needs the capacity rather than the resulting analysis / computation on the data.  Then you might add something saying “such as the WLCG”, as that is currently the largest example of a distributed computation collaboration in the R&E world.

Tim