Thanks for the review and please see the responses inline.
Best,
Kai
> -----Original Messages-----
> From: "Tim Chown via Datatracker" <noreply@xxxxxxxx>
> Sent Time: 2021-12-01 19:44:33 (Wednesday)
> To: ops-dir@xxxxxxxx
> Cc: draft-ietf-alto-path-vector.all@xxxxxxxx, last-call@xxxxxxxx, alto@xxxxxxxx
> Subject: [alto] Opsdir telechat review of draft-ietf-alto-path-vector-19
>
> Reviewer: Tim Chown
> Review result: Ready
>
> 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.
Thanks for the previous review. It helps us a lot to improve the draft.
> 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.
Thanks for the comment. The problem with "domain" is not limited to this draft and
is raised in another review of the unified property document where the term is
defined. We are coordinating between these two documents to see how this can be
solved coherently.
> 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.
>
This is a very help suggestion. We will adopt the suggested text in the next revision:
Applications which need to perform large scale data transfers can benefit ...
... One such example is the Worldwide LHC Computing Grid (WLCG), the largest example
of a distributed computation collaboration in the research and education world.
>
>
>
> _______________________________________________
> alto mailing list
> alto@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/alto
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
