Hi Dawn, I’m glad they help. I went through your responses. Please see some feedback inline. Thanks, Sabine
From: Dawn Chan [mailto:[email protected]] Sent: Friday, December 15, 2017 4:03 PM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]> Cc: [email protected] Subject: Re: [alto] Piecewise review of draft-ietf-alto-path-vector-01 - All parts - Until Section 4 Overview Hi Sabine, We are updating the path vector draft. Great thanks to the detailed review, your review opinions are of much help. Please see my reply inline. Thanks, Dawn On 13 Dec 2017, at 8:57 PM, Randriamasy, Sabine (Nokia - FR/Paris-Saclay) <[email protected]<mailto:[email protected]>> wrote: 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. [Dawn] Yes, the path vector extension exposes a much more detailed view of network compared to the base ALTO protocol. To support the convey of the path vector information, a new cost metric and a new cost mode are introduced to encode cost values, and a new media type “multipart/related” is imported for receiving responses with composite information. 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, [Dawn] Actually, due to the introduce of “multipart/related”, a new service related to this media type will be added in the next version. - in section 4, a subsection on backwards compatibility [Dawn] Agree. The new subsection considering backwards compatibility will be added. In section 3: the use case should be revised as the provided values are hard to match with the rationale. [Dawn] The use case will be reconsidered. ======================================================== 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 ++” [Dawn] Agree. - 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:” [Dawn] Agree, this will be modified in the next version. - 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. [Dawn] Agree, thanks. - 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. [Dawn] Agree. --- 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. [Dawn] Is more motivation of using pv needs or extend the pv uses to a more general scenario? [[SR]] I mean the paragraph seems to say that PV is only here to inform on bottlenecks where as it can serve other purposes. --- 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. [Dawn] Yes, Such confusion should be avoided. - Reference [I-D.ietf-alto-multi-cost] can now be replaced by RFC 8189. [Dawn] Agree. It was already done. ---------------- 2. Terminology ---------------- - item (ANEP): "CAN" must be in lower case as it is not covered by RFC 2119. [Dawn] Agree, this will be rectified in the next version. ======================================================== DETAILED COMMENTS - section 3 ======================================================== ---------------- 3. Use Case:... ---------------- The example values of link capacity and use case conclusions are hard to understand when one assumes that path capacity = MIN(link capacity) over the links of the path. [Dawn] The example will be considered to be described more clearly. --- Para 1 - sentence 1-2: I propose to re-phrase as follows: "Once routing has been configured in the network, application-layer traffic optimization may want to schedule traffic among application-layer paths." [Dawn] Agree, it seems better. --- Para 4 (after fig.2) - sentence 1: I propose to re-phrase as follows: "Consider an application overlay (e.g., a large data analysis system) which ++ wants ++ to schedule the traffic on two source-destination flows, say eh1 -> eh2 and eh1 -> eh4.”. [Dawn] Agree. --- Para 6 - sentence 2: can be shortened to "In particular --, it needs to provide the following new capabilities—:" [Dawn] Agree. - item 2: "The network needs to provide the necessary abstraction to hide the real topology -- information as possible-- ++ while providing enough information to applications ++.” [Dawn] Agree. --- Para 7 - "The path-vector extension defined in this document --will satisfy all the-- ++ addresses these ++ requirements.” [Dawn] -- will satisfy all the -- ++ meet these ++ requirements will be better. ======================================================== General comments on the document/digest - section 4 ======================================================== - 4.2. Cost Type Extension ( ==> proposed 4.1.3 "Path Vector Cost Type attributes") Table 1: how should the reader understand this? This table should reflect that "hopcount" and "routingcost" may both in either numerical or ordinal mode where as "ane-path" is only in "array" mode. [Dawn] Though the specification that “ane-path” is only in “array” mode is specified in Section5, it would be better to list more combinations in the table as not to confuse the reader. [[SR]] Not sure I understand. Maybe a more elaborated table with some explanation text will help. - (proposed new section) 4.2 Applicable ALTO Services for Path Vector Costs: - Cost Map should not be applicable, as a base protocol client will not understand a PV Cost Map obtained via a GET request. [Dawn] Not totally agree. The new section will be added, but Cost Map actually are applicable. Base ALTO client will not understand a PV Cost Map, but client who support the path vector extension can understand a PV Cost Map obtained via a GET request, though it is not recommended. [[SR]] This is actually the point. A legacy client can request a PV Cost Map but will not understand it. This is why other extensions do not offer this service. And this motivates a section on requirements for PV capable Clients (and Servers). - 4.4 needs a couple of sentences to elaborate on RFC2387 and the consistency with the base protocol Instead of a last paragraph on backwards compatibility: a subsection is needed on "Impact of backwards compatibility on the PV design" and another subsection on "Requirements for PV on Clients and Servers” [Dawn] Such section will be considered. - keywords covered by RFC2119 such as MUST etc. must be used carefully. [Dawn] Agree. References: - [I-D.ietf-alto-multi-cost] should be replaced by [RFC8189]. - [I-D.roome-alto-unified-props] should be replaced by: [I-D.ietf-alto-unified-props-new] [Dawn] Agree, already done. ======================================================== DETAILED COMMENTS - section 4 ======================================================== ---------------- 4. Overview ---------------- Title can be expanded to: "Overview of path-vector extensions". This section is key and needs substantial expansion and many new notions are introduced there. In particular a sub-section with additonal non-normative text defining: - the new cost metric "ane-path" and the type of values that are exposed, with format and example. [Dawn] Such information is in the following Section 4.2. - the property map optionally associated, with format and example. [Dawn] The information is in the following Section 4.3. Additional sub-sections are suggested here, to be completed/updated as needed. Sentence 2: It is unlikely that readers are familiar with [draft-ietf-alto-unified-props-new]. So I propose re-phrasing as follows: "It assumes the readers are familiar with (Filtered) Cost Map and Endpoint Cost Service defined in [RFC7285] and their multi-cost extensions defined in [RFC8189]. ++It also uses features such as++ Filtered Property Map defined in [I-D.ietf-alto-unified-props-new].” [Dawn] Accepted. ---------------- 4.1. Path Vector ---------------- - Title can be expanded to: "The Path Vector Cost Type extensions” [Dawn] Accepted. --- Para 1 - Sentence 1: re-phrasing and expansion proposal: "A path vector is an array of so-called ALTO Abstract Network Elements (ANEs) ++and++ represents an abstract network path between entities such as PIDs or endpoints. ++ An ANE represents a selected part of an end to end path that the ALTO Server considers worth exposing. An ANE is a set of one or more network elements such as links, switches or other equipment. it is expected to have properties that may influence the applications e.g. when they select an endpoint or want to estimate their performance.++” [Dawn] Accepted. - Sentence 2: "Each abstract network element has two attributes: "name" and "properties" (added quotations)++, where "name" can be for example ... and "properties" can be ... ++.” [Dawn] Agree. - Sentence 3: "The abstract network... and the abstract... in ++ separate ++ abstract network element property maps." [Dawn] Agree, thanks. ---------------- (proposed new section) 4.1.1 New Cost Metric and Values for Path Vector ---------------- To represent an abstracted network path, this document introduces a new cost metric named "ane-path". A cost value in this metric is an array containing the names of the ALTO ANEs that the ALTO Server has specified as describing the network path elements. The ANE names array is organized as a sequence beginning at the source of the path and ending at its destination. Each ANE name of the "ane-path" array is encoded as a string that identifies the ANE. ---------------- (proposed new section)4.1.3 New Cost Mode for Path Vector ---------------- A cost mode as defined in Section 6.1.2 of [RFC7285], a cost mode is either "numerical" or "ordinal" and none of these can be used to present a list of ANE names. Therefore, this document specifies a new cost mode named "array" for the cost metric "ane-path". The new cost mode "array" means each cost value in the cost maps is a list. ---------------- 4.2. Cost Type Extension ==> 4.1.3 "Path Vector Cost Type attributes" ---------------- - skip 2 first paragraphs, already in sections 4.1.1 and 4.1.2 - then: The attributes of the Path vector cost type are thus as follows: - Cost metric: "ane-path" - Cost Mode: "array" - Semantics: an array of strings representing the sequence of ANEs in a network path, where each string is the name of an ANE. ***** Table 1: how should the reader understand this? This table should reflect that "hopcount" and "routingcost" may both in either numerical or ordinal mode where as "ane-path" is only in "array" mode. [Dawn] These sections will be reconstructed. ---------------- (proposed new section) 4.2 Applicable ALTO Services for Path Vector Costs ---------------- List here what existing ALTO Services can be used to convey PV costs and related restrictions/conditions that will be detailed in next sections. ***** - Cost Map should not be applicable as a base protocol client will not understand a PV Cost Map obtained via a GET request. - Filtered Cost Maps - Endpoint Cost [Dawn] This issue is already discussed above. ---------------- 4.3. Extended optional property service: ANE Property Map ---------------- - sentence 1: "Given that Cost Map ... there exist bottlenecks ++ shared by ++ different flows.” [Dawn] Accepted. - sentence 2: ***** not all Clients want to have the ANE properties. Suggestion: "However, ++some++ ALTO clients ++ may want to have++ information on specific ++ANE properties such as++ link capacity ++or delay++.” [Dawn] Agree. - sentence 3: "This document adopts the property map resources defined in -- -- [I-D.ietf-alto-unified-props-new] to encode the properties of ++ANEs++.” [Dawn] Accepted. - sentence 4: Suggestion: "Draft [I-D.ietf-alto-unified-props-new] defines a new entity domain called "ane" and each entity in the "ane" domain has an identifier of an ANE. ANE properties are provided in information resources called "Property Map Resource" and "Filtered Property Map Resource”. [Dawn] Agree. - sentence 5: suggestion: An ANE identifier is the ANE name used in the values of the "ane-path" metric defined in the present draft". - sentence 6: "++In the present draft,++ the property map which supports "ane" domain is ++called++ ANE Property Map." [Dawn] Agree, thanks. ---------------- 4.4. ++RFC 2387++ media-type for path-vector: multipart/related ---------------- Instead of a last paragraph on backwards compatibility: a subsection is needed on "Impact of backwards compatibility on the PV design" and another subsection on "Requirements for PV on Clients and Servers" [Dawn] As discussed above, a new service will be provided due to the introduce of this media type. The specification of IRD entry and the service will be updated later. --- Para 2: - sentence 1: replace MUST by "needs to”. - sentence 2:"This ++may cause a++ data synchronization problem” [Dawn] Accepted. --- Para 3: - sentence 1: typo: documents ==> document [Dawn] Yes, will be corrected. - sentence 2: ***** Cost Map ==> ++Filtered++ Cost Map ? Thus, a response can contain both the path vector as a ++Filtered ? ++ Cost Map (or Endpoint Cost Map) and the ++ associated ++ -- -- ++ANE++ Property Map. [Dawn] As discussed above, Cost Map is supported. - sentence 3: ***** can you clarify on the consistency with the base protocol. [Dawn] It will be considered in the later update. _______________________________________________ alto mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
