Hello authors of PV extension, Please find below the first part of my review of draft-ietf-alto-path-vector-01. I prefer to send revisions covering groups of sections rather than a too long e-mail covering the whole document. Below is my feedback until section 3 included. Next parts will follow. The general comments on the document may also be incremented in upcoming revision parts.
Thanks, Sabine ======================================================== General comments on the document - part 1 ======================================================== This draft introduces extensions that significantly opens the perspectives for ALTO will definitely gain traction to use ALTO, among others as it will enable to abstract heterogenous network topologies and technologies. It introduces significant extensions such as a new media-type and provides a composite network information. It provides many details on format specifications. Though, the many significant new features must be presented and explained beforehand with clear and illustrations. For example some text on a key change which are: (i) the new cost type, with associated metric and mode and the kind of values provided for this metric (ii)the possibility of receiving responses with composite information on path costs, insight on abstracted path elements and their properties. What would be helpful is for instance: - a section explaining listing the requirements for PV-capable clients and servers, as a new media-type is introduced, - in section 4, a subsection on backwards compatibility In section 3: the use case should be revised as the provided values are hard to match with the rationale. ======================================================== DETAILED COMMENTS - until section 2 included ======================================================== TITLE: the Cost Mode associated to the metric "ane-path" is "array". So something like "Path Vector (cost) information" ABSTRACT: "... query information ++ on selected parts of an e2e path ++ such as capacity regions ... " ---------------- 1. Introduction ---------------- Some reorganization would help this section to better motivate the PV extension. --- Para 2 - 1st sentence "new emerging use cases, such as inter-datacenter flow scheduling and scientific high-performance computing data transfers ++ and end to end paths crossing heterogeneous technologies ++" - last sentence: the base ALTO protocol is not mandated to provide the 2 services listed below. Therefrom the proposed extensions. How about re-phrasing as follows: "For these use cases ALTO services should provide the following functionalities:" - In addition to shared bottleneck a Client may want just to be aware of the type of network elements with their properties that an end to end path is going through. So the following item2 should be replaced by this one. - item 1 - last sentence: put MUST in lower case. Normative terms should be avoided at this stage. - item 2 - first sentence: typo: Some ==> some. This item as it is written describes a functionality already specified in RFC 8189. So it could be replaced by the abovementioned one. --- Para 3: 2nd sentence: "The path-vector extension specifies how to encode the shared bottlenecks..." PV should be motivated by more than 1 single use case. The paragraph may add that the PV extension introduces a qualitative cost type listing selected groups of one or more abstracted network elements in an e2e path and optionally conveys some of their properties. --- Para 4 needs clarification. - explain "such as those introduced in the base protocol". - sentence: "However, the pathvector extension in this document has introduced a new cost type which complicates the situation". As, the reader does not know the PV extension yet. It would be clearer to say that RFC 8189 supporting multi-cost ALTO transactions cannot convey abstracted network elements properties nor can it use the PV specific cost type in its constraints. - Reference [I-D.ietf-alto-multi-cost] can now be replaced by RFC 8189. ---------------- 2. Terminology ---------------- - item (ANEP): "CAN" must be in lower case as it is not covered by RFC 2119.
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
