Hello authors of PV extension and all, Please find below my review of draft-ietf-alto-path-vector-01, covering section 4. There is a "digest" part including some points subject to WG discussion on top of this long e-mail, before the detailed comments.
For the caption, in sentences: "... bla bla ...", text between "++ ++", "-- --" means respectively ++added text++ and --deleted text-- Thanks, Sabine ======================================================== 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. - (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. - 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" - keywords covered by RFC2119 such as MUST etc. must be used carefully. 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] ======================================================== 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. - the property map optionally associated, with format and example. 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]." ---------------- 4.1. Path Vector ---------------- - Title can be expanded to: "The Path Vector Cost Type extensions" --- 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.++" - Sentence 2: "Each abstract network element has two attributes: "name" and "properties" (added quotations)++, where "name" can be for example ... and "properties" can be ... ++." - Sentence 3: "The abstract network... and the abstract... in ++ separate ++ abstract network element property maps." ---------------- (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. ---------------- (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 ---------------- 4.3. Extended optional property service: ANE Property Map ---------------- - sentence 1: "Given that Cost Map ... there exist bottlenecks ++ shared by ++ different flows." - 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++." - sentence 3: "This document adopts the property map resources defined in -- -- [I-D.ietf-alto-unified-props-new] to encode the properties of ++ANEs++." - 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". - 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." ---------------- 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" --- Para 2: - sentence 1: replace MUST by "needs to". - sentence 2:"This ++may cause a++ data synchronization problem" --- Para 3: - sentence 1: typo: documents ==> document - 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. - sentence 3: ***** can you clarify on the consistency with the base protocol.
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
