Hi again, I don't know if it will work, but I try to send my review as an attachment. Cheers, Sabine
>>-----Message d'origine----- >>De : alto [mailto:[email protected]] De la part de EXT Randriamasy, >>Sabine (Nokia - FR) >>Envoyé : vendredi 5 février 2016 18:56 >>À : Gurbani, Vijay (Nokia - US); IETF ALTO >>Objet : Re: [alto] State of the WG >> >> >>Hi Michael, Hans and all, >> >>I have volunteered to review draft-ietf-alto-deployment-13. As time >>passes and the document is long, I prefer to send you my feedback >>piecewise, focusing first on the updated sections. For the sake of >>rapidity, I sometimes put Nits and other feedback together. >> >>So below, you will find my feedback on section 3.6. >>Then, I'll send you my feedback on sections 1 to 3.4 included. >> >>All in all, thanks for this clarified and enriched version of draft- >>ietf-alto-deployments. I found no major issues but some sentences need >>to be re-formulated and figures need be referenced in the text. Don't >>hesitate to get back to me if needed. >> >>Thanks, >>Sabine >> >>------------------------------------------------------ >>I used the following conventions: >> >>(1.2.3) section nb >>(p12) page nb >>para 2 = paragraph 2 >> >>(++ blabla) = added blabla >>(-- blabla) = removed blabla >>"old blabla" ==> "new blabla" = replace "old blabla" by "new blabla" >> >>--------- >>General: >> >>Figures 14 to 20: the caption should be harmonized with the rest of the >>document in that the common nouns should be written in low case and not >>start with a capital letter. >> >>In section 3.6.4 Calculation of Cost Map: many clarifications are >>needed on the path cost calculation >> >>--------- >>(p40) >>--------- >>para 1: "Figure 2" should be replaced by "Figure 15" as fas as I >>understand para 2: "listed information" ==> "listed information(++s)" >> >>--------- >>(p41) >>--------- >>- para 1: "As example" ==> "For example" >>- para 2: "information" ==> "information(++s)" >>- item 1: "Link" ==> "link" >>- (3.6.2), title: for transition to section 3.6.3 I suggest "Potential >>(++ input) Data Processing and Storage" >>- (3.6.2), para 3: to reference Figure 16, I suggest: "Each router >>could..." ==> "(++ As illustrated in Figure 16 for the router R2 of >>Figure 14,) each router could..." >> >>--------- >>(p42) >>--------- >>- item 2: to avoid hinting that an endpoint may be associated to >>several PIDs, I suggest: "AS numbers, or AS distances. >> Endpoints may belong to..." ==> "AS numbers (--,) or AS distances. >> Endpoints may be connected to" >>- para 2: "and/ or" ==> "and/or" >> >>- The presence of the remaining text "A suitable information... belongs >>to its own AS" before Figures 16 and 17 is pretty confusing, especially >>when encountering terms "weights" and "metrics". So I strongly suggest >>to move this remaining text after Figure 17 (p44). >> >>- instead: we need to reference Figure 16 and clarify the example >>attribute "Metric". So I suggest right after "just to name a few", to >>append "Figure 16 provides an example set of attributes associated to >>the router R2 of the exemple network depicted in Figure 14. The >>attribute "Metric" is an example of ... TBC" >> >>--------- >>(p43) >>--------- >>- Figure 16: please clarify what "default client subnet metric" can be >>- para 2: reference to Figure 17 needed. i suugest replacing "Router >>R8... " by "Figure 17 provides values for the same attributes >>associated to router R8. R8... " >> >>--------- >>(p44) >>--------- >>- para 1 (after text moved from p42): Insert ref to fig. 18, >>suggestion: "In the example, the link attributes..." ==> "Figure 18 >>provides an example where the link attributes..." >> >> >>--------- >>(p45) >>--------- >>- (3.6.3) title: in relation to (3.6.2) I suggest: "Calculation of >>Network Map (++from the Input Data)" >>- para 1: suggestion: "presentation of the network to a coarse-grained >>matrix presentation" ==> "(++re)presentation of the network to a >>coarse(++r) grained (++and abstracted) matrix (++re)presentation" >>- para 2: algorithm(++s) can utilize all (?? you mean "all" or "any" ?) >>information .... The functions ... to simplify the map or (--to) hide >>details ... published (--with) (++in) the resulting ALTO network map. >> >>--------- >>(p46) >>--------- >>- para 2: "Figure 14" ==> "Figure 19" >>- (3.6.4), para 1: "calculate values unidirectional" ==> "calculate >>unidirectional values" >> >>--------- >>(p47) >>--------- >>It is necessary to clarify the text on path calculation in this page. >> >>--- para 1: >>- "or subnet the cost" ==> "or subnet (++,) the cost" >>- "cost function may calculate" ==> "cost function may (++first) >>calculate" >>- "In that case a" ==> "In that case (++,) a" >>- "required which decide(--s)" ==> "required to decide..." >>- as this section is about computing values exposed by the ALTO Server, >>I suggested to append to following text. "resulting cost value" ==> >>"resulting cost value (++as RFC7285 allows one cost value only between >>2 PIDs.)" >>- Such (++a) tie-breaker can be (a++) simple function(--s) such as >>minimum, maximum, or average value. >> >> >>--- para 2: reformulation is needed here in order to cover the most >>"popular" optimal path extraction methods. >>- "the minimum path weight." ==> "the minimum weight path." >> >>- I recommend the following insertion: "The path weight is the sum..." >>==> "(++When the link weight is represented by an additive metric,) the >>path weight is the sum...". >>The reason is that: when the link weight metric represents a bandwidth >>performance, the metric composition law is "MIN" and path weight is >>equal to the smallest of the link weights. For a metric such as packet >>loss, the path weight is the multiplication over all links. >> >>- sentence "Hence, the cost function must first determine the path >>before it can determine any other metric value": besed on my previous >>comment, I'd rather say "Hence, the cost function generally extracts >>the optimal path w.r.t. a chosen metric". >> >>- sentence "As a result, the metric value can differ from the >>expectation where the path with the shortest path weight was not >>considered" is hard to understand and could be removed and replaced >>with some elaboration on the Dijkstra example. I will propose some >>formulation right after the next item. >> >>- "But it is also possible..." ==> "(--But) it is also possible..." >> >>- Suggestion for para 2 (let me know if I missed something) "No matter >>what metric the cost function is using, the path from source to >>destination is usually defined by the minimum (-+ weight) path. >> (++When the link weight is represented by an additive metric,) the >>path weight is the sum of the link weights of all traversed links. >> The path may be determined for instance with the Bellman-Ford or >>Dijkstra algorithm. The latter progressively builds the shortest path >>in terms of cumulated link lengths. In our example, the link lengths >>are link weights with values illustrated in Figure 15. (--2 sentences >>removed). (--But) It is also possible that more than one path..." >> >>--- para 3 >>- "values for other PID pairs for arbitrary reasons" ==> " values for >>some PID pairs due to arbitrary reasons" >> >> >>--- para 4 >>- "In this example, the selected >> metric..." ==> "Figure 20 provides an example where the selected >>metric..." >>- "from source to (++ the endpoints connected to the) destination PID": >>otherwise all the values in Figure 20 should be minus 1. >> >>--------- >>(p47) >>--------- >>para 1: "Due to the minimum value tie-breaker 3..." ==> "Due to the >>minimum (++hopcount)value tie-breaker (++,) 3..." >> >> >> >> >> >> >> >> >> >> >> >>>>-----Message d'origine----- >>>>De : alto [mailto:[email protected]] De la part de Vijay K. >>>>Gurbani Envoyé : mardi 26 janvier 2016 16:29 À : IETF ALTO Objet : >>>>[alto] State of the WG >>>> >>>>Folks: The mailing list has been awfully quiet. >>>> >>>>Presently, we have 3 active I-Ds that are being tracked towards >>>>charter >>>>fulfillment: >>>> >>>>1. draft-ietf-alto-deployments is in its second WGLC. The new WGLC >>>>ends >>>> on February 3, 2016. >>>> >>>>2. draft-ietf-alto-incr-update-sse appears to be moving along and >>>>there >>>> do not seem to be any stop gap issues that we are aware of. >>>>Authors, >>>> please inform the WG if there are. >>>> >>>>3. draft-ietf-alto-multi-cost is also fairly mature. >>>> >>>>It seems reasonable to move 2 and 3 ahead. >>>> >>>>Then there are a number of independent submissions dating back to >>Sep- >>>>Oct 2015 timeframe. These have not been updated and nor has there >>>>been much discussion on the mailing list. Some of these submissions >>>>are important for charter deliverables related to graph >>representation >>>>formats. Can the authors of the independent submissions kindly share >>>>what their plans are with respect to the drafts? >>>> >>>>This will help us gauge whether or not we should meet face-to-face in >>>>Buenos Aires or have an interim meeting before it and meet >>>>face-to-face in Berlin. >>>> >>>>Note that while the final plans are still up in the air and subject >>to >>>>change, there is a good chance that neither Jan or I will be able to >>>>make it to Buenos Aires. However, if a F2F meeting is desired, it is >>>>important to get a sense of the energy behind the independent drafts, >>>>as the list traffic has been woefully quiet on this front. >>>> >>>>Thanks, >>>> >>>>- vijay >>>>-- >>>>Vijay K. Gurbani, Bell Laboratories, Nokia 1960 Lucent Lane, Rm. 9C- >>>>533, Naperville, Illinois 60563 (USA) >>>>Email: vkg@{bell-labs.com,acm.org} / [email protected] >>>>Web: http://ect.bell-labs.com/who/vkg/ | Calendar: >>>>http://goo.gl/x3Ogq >>>> >>>>_______________________________________________ >>>>alto mailing list >>>>[email protected] >>>>https://www.ietf.org/mailman/listinfo/alto >> >>_______________________________________________ >>alto mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/alto
Hi Michael, Hans and all, I have volunteered to review draft-ietf-alto-deployment-13. As time passes and the document is long, I prefer to send you my feedback piecewise, focusing first on the updated sections. For the sake of rapidity, I sometimes put Nits and other feedback together. So below, you will find my feedback on section 3.6. Then, I'll send you my feedback on sections 1 to 3.4 included. All in all, thanks for this clarified and enriched version of draft-ietf-alto-deployments. I found no major issues but some sentences need to be re-formulated and figures need be referenced in the text. Don't hesitate to get back to me if needed. Thanks, Sabine ------------------------------------------------------ I used the following conventions: (1.2.3) section nb (p12) page nb para 2 = paragraph 2 (++ blabla) = added blabla (-- blabla) = removed blabla "old blabla" ==> "new blabla" = replace "old blabla" by "new blabla" --------- General: Figures 14 to 20: the caption should be harmonized with the rest of the document in that the common nouns should be written in low case and not start with a capital letter. In section 3.6.4 Calculation of Cost Map: many clarifications are needed on the path cost calculation --------- (p40) --------- para 1: "Figure 2" should be replaced by "Figure 15" as fas as I understand para 2: "listed information" ==> "listed information(++s)" --------- (p41) --------- - para 1: "As example" ==> "For example" - para 2: "information" ==> "information(++s)" - item 1: "Link" ==> "link" - (3.6.2), title: for transition to section 3.6.3 I suggest "Potential (++ input) Data Processing and Storage" - (3.6.2), para 3: to reference Figure 16, I suggest: "Each router could..." ==> "(++ As illustrated in Figure 16 for the router R2 of Figure 14,) each router could..." --------- (p42) --------- - item 2: to avoid hinting that an endpoint may be associated to several PIDs, I suggest: "AS numbers, or AS distances. Endpoints may belong to..." ==> "AS numbers (--,) or AS distances. Endpoints may be connected to" - para 2: "and/ or" ==> "and/or" - The presence of the remaining text "A suitable information... belongs to its own AS" before Figures 16 and 17 is pretty confusing, especially when encountering terms "weights" and "metrics". So I strongly suggest to move this remaining text after Figure 17 (p44). - instead: we need to reference Figure 16 and clarify the example attribute "Metric". So I suggest right after "just to name a few", to append "Figure 16 provides an example set of attributes associated to the router R2 of the exemple network depicted in Figure 14. The attribute "Metric" is an example of ... TBC" --------- (p43) --------- - Figure 16: please clarify what "default client subnet metric" can be - para 2: reference to Figure 17 needed. i suugest replacing "Router R8... " by "Figure 17 provides values for the same attributes associated to router R8. R8... " --------- (p44) --------- - para 1 (after text moved from p42): Insert ref to fig. 18, suggestion: "In the example, the link attributes..." ==> "Figure 18 provides an example where the link attributes..." --------- (p45) --------- - (3.6.3) title: in relation to (3.6.2) I suggest: "Calculation of Network Map (++from the Input Data)" - para 1: suggestion: "presentation of the network to a coarse-grained matrix presentation" ==> "(++re)presentation of the network to a coarse(++r)-grained (++and abstracted) matrix (++re)presentation" - para 2: algorithm(++s) can utilize all (?? you mean "all" or "any" ?) information .... The functions ... to simplify the map or (--to) hide details ... published (--with) (++in) the resulting ALTO network map. --------- (p46) --------- - para 2: "Figure 14" ==> "Figure 19" - (3.6.4), para 1: "calculate values unidirectional" ==> "calculate unidirectional values" --------- (p47) --------- It is necessary to clarify the text on path calculation in this page. --- para 1: - "or subnet the cost" ==> "or subnet (++,) the cost" - "cost function may calculate" ==> "cost function may (++first) calculate" - "In that case a" ==> "In that case (++,) a" - "required which decide(--s)" ==> "required to decide..." - as this section is about computing values exposed by the ALTO Server, I suggested to append to following text. "resulting cost value" ==> "resulting cost value (++as RFC7285 allows one cost value only between 2 PIDs.)" - Such (++a) tie-breaker can be (a++) simple function(--s) such as minimum, maximum, or average value. --- para 2: reformulation is needed here in order to cover the most "popular" optimal path extraction methods. - "the minimum path weight." ==> "the minimum weight path." - I recommend the following insertion: "The path weight is the sum..." ==> "(++When the link weight is represented by an additive metric,) the path weight is the sum...". The reason is that: when the link weight metric represents a bandwidth performance, the metric composition law is "MIN" and path weight is equal to the smallest of the link weights. For a metric such as packet loss, the path weight is the multiplication over all links. - sentence "Hence, the cost function must first determine the path before it can determine any other metric value": besed on my previous comment, I'd rather say "Hence, the cost function generally extracts the optimal path w.r.t. a chosen metric". - sentence "As a result, the metric value can differ from the expectation where the path with the shortest path weight was not considered" is hard to understand and could be removed and replaced with some ellaboration on the Dijkstra example. I will propose some formulation raight after the next item. - "But it is also possible..." ==> "(--But) it is also possible..." - Suggestion for para 2 (let me know if I missed something) "No matter what metric the cost function is using, the path from source to destination is usually defined by the minimum (-+ weight) path. (++When the link weight is represented by an additive metric,) the path weight is the sum of the link weights of all traversed links. The path may be determined for instance with the Bellman-Ford or Dijkstra algorithm. The latter progressively builds the shortest path in terms of cumulated link lengths. In our example, the link lenghts are link weights with values illustrated in Figure 15. (--2 sentences removed). (--But) It is also possible that more than one path..." --- para 3 - "values for other PID pairs for arbitrary reasons" ==> " values for some PID pairs due to arbitrary reasons" --- para 4 - "In this example, the selected metric..." ==> "Figure 20 provides an example where the selected metric..." - "from source to (++ the endpoints connected to the) destination PID": otherwise all the values in Figure 20 should be minus 1. --------- (p47) --------- para 1: "Due to the minimum value tie-breaker 3..." ==> "Due to the minimum (++hopcount)value tie-breaker (++,) 3..."
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
