Hi Sabine, Thanks a lot for the review! I am currently busy but I will look into it as soon as possible.
Thanks Michael -----Original Message----- From: alto [mailto:[email protected]] On Behalf Of EXT Randriamasy, Sabine (Nokia - FR) Sent: Monday, February 08, 2016 5:50 PM To: Randriamasy, Sabine (Nokia - FR); Gurbani, Vijay (Nokia - US); IETF ALTO Subject: Re: [alto] State of the WG Hi again, Apologies, I should also have reviewed the text of my e-mail. The attached review "feedback_deployment_13_section1-to-3-4_sr.txt" I just sent STOPS at beginning of 3.4, as I wanted to focus on the last updates. Thanks, Sabine >>-----Message d'origine----- >>De : Randriamasy, Sabine (Nokia - FR) >>Envoyé : lundi 8 février 2016 17:42 >>À : Randriamasy, Sabine (Nokia - FR); Gurbani, Vijay (Nokia - US); >>IETF ALTO Objet : RE: [alto] State of the WG >> >>Hi Michael, Hans and all, >> >>As promised, here is my feedback to sections 1 to 3.4 included. I >>tried to separate "Nits only" and "nits + comments". >>In a first step, I am sending the review as an attachment. >> >>Again, thanks a lot for the work, this text is very well structured, >>clear and interesting. Some parts need a bit of clarifications and >>also, some re-phrasing to highlight the advantages of ALTO Services >>and providing incentives to use them is suggested here and there. >> >>Thanks, >>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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
