Hi, Richard: Thank for your valuable review, you have a good understand to this draft. Please see my reply inline below.
Regards! -Qin From: [email protected] [mailto:[email protected]] On Behalf Of Y. Richard Yang Sent: Monday, July 15, 2013 10:01 AM To: Qin Wu Cc: [email protected]; Xialiang (C) Subject: Re: [alto] FW: I-D Action: draft-wu-alto-json-te-00.txt Hi Qin, Thanks for the work on TE performance metrics. Here are some quick comments: - It is not fully clear to me if you want to consider linkdelay, linkjitter, ... as new Cost Metrics also or they will be only constraints of the "routingcost" Cost Metric. Does it make sense to consider them as Cost Metrics? [Qin]:You raised a very good question. We can either put performance metrics like link delay, link jitter as constraints of the "routing cost" with few impact on ALTO base protocol or consider them as new cost metrics with more extension to ALTO base protocol. My current take is the benefit of coupling link delay, link jitter with "routing cost" is to provide finer granularity for "routing cost" since routing cost can be calculated based on constraints likelink delay, link jitter as input. Decoupling link delay, link jitter from 'routing cost' lost such benefit. - If so, a feedback is that ALTO Cost Metric need to follow the RFC 6390: [Qin]: Agree, however we are not new cost metric in the current draft, currently we consider link delay as constraint of 'routingcost'. 6390 Guidelines for Considering New Performance Metric Development. A. Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also BCP0170) (Status: BEST CURRENT PRACTICE) In particular, Sec. 5.4 of RFC 6390 specifies a template for specifying additional performance metrics (Cost Metrics). I believe that we will follow the template. As an example, the template specifies Units of Measurement (item iv) which are missing in the draft. How about we follow the template? [Qin]: If you believe we should define new Cost metric, I think we should follow RFC6390 template. However we are not supposed to define new metrics in this draft rather than reference the metrics that have already been defined in draft-ietf-ospf-te-metric-extensions Or draft-ietf-isis-te-metric-extensions. Another clarification to your question, is actually we have already specified measurement unit for each performance metric even though they are existing metrics defined somewhere else, see 'linkdelay' example in the draft: " Value type: A single number value containing an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part. " - In your example json: "data": { "cost type": { "cost-mode": "numerical", "cost-metric":"routingcost"}, "constraints" : {"linkdelay"}, "endpoints": { "srcs": [ "ipv4:192.0.2.2" ], "dsts": [ "ipv4:192.0.2.89", "ipv4:198.51.100.34", "ipv4:203.0.113.45" ] } // YRY: missing <- "}" ? [Qin]: Good catch, thanks. "map": { "ipv4:192.0.2.2": { "ipv4:192.0.2.89": 0.0[linkdelay eq 0.0], "ipv4:198.51.100.34": 15.0[linkdelay eq 3.0], "ipv4:203.0.113.45": 1.0[linkdelay eq 12.0], } } Is the example query or response? I understand that they are response, but I feel that it can be helpful to start with specifying the input of filtering. [Qin]:Correct, agree. Let's see if my understanding of your input is correct. The current spec is: object { CostType cost-type; [JSONString constraints<0..*>;] [PIDFilter pids;] } ReqFilteredCostMap; object { PIDName srcs<0..*>; PIDName dsts<0..*>; } PIDFilter; You appear to extend the request format to be: object { CostType cost-type; [JSONString constraints<0..*>;] [Endpoints endpoints;] // YRY: new? [PIDFilter pids;] } ReqFilteredCostMap; I feel that you are extending the syntax of "constraints" (see top of page 49 of -17). Will it be helpful to define the grammar first? [Qin]: Just to clarify, we follow the existing grammar defined in the section 10.4.1.3 of ALTO base protocol draft: " 10.4.1.3<http://tools.ietf.org/html/draft-ietf-alto-protocol-17#section-10.4.1.3>. Accept Input Parameters An ALTO Client supplies the endpoint cost parameters through a media type "application/alto-endpointcostparams+json", with an HTTP POST entity body of a JSON Object of type ReqEndpointCostMap: object { CostType cost-type; [JSONString constraints<0..*>;] EndpointFilter endpoints; } ReqEndpointCostMap; object { [TypedEndpointAddr srcs<0..*>;] [TypedEndpointAddr dsts<0..*>;] } EndpointFilter; " Rather than the grammar you are referring to, in this case, do you believe we should define new grammar? - Regarding response, I read that you want the response to include the values of multiple attributes. For example, from your example, you are trying to say that: from "ipv4:192.0.2.2" to "ipv4:198.51.100.34" has routing cost 15 and delay 3. Is this correct? [Qin]: Correct There are discussions on extending the map to report multiple attributes., and personally, I will find the following format easier to read (more symmetric): ipv4:198.51.100.34": ["routingcost": 15.0, "linkdelay":3.0], [Qin]:Good point, . We can make this more clear in the next version, thank for your proposed change. Please let me know if I understand you correctly. Thanks! Richard On Mon, Jul 8, 2013 at 3:48 AM, Qin Wu <[email protected]<mailto:[email protected]>> wrote: Hi,folks: Here is the initial draft (v-00)to discuss Json format representation for TE performance metrics advertised by OSPF in the ALTO information resource Directory. The URL link is available at: http://tools.ietf.org/html/draft-wu-alto-json-te-00 Your comments and feedback are welcome! Regards! -Qin -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of [email protected]<mailto:[email protected]> Sent: Monday, July 08, 2013 3:21 PM To: [email protected]<mailto:[email protected]> Subject: I-D Action: draft-wu-alto-json-te-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : JSON Format Extensions for Traffic Engineering (TE) performance metrics in the ALTO Information Resource Directory Author(s) : Qin Wu Liang Xia Filename : draft-wu-alto-json-te-00.txt Pages : 16 Date : 2013-07-08 Abstract: The base ALTO specification defines two properties for cost metric attribute in the Cost MAP, including 'hopcount' and 'routingcost'. This specification adds five new properties and one new parameter for Traffic Engineering(TE) performance related constraint attribute associated with cost metric attribute 'routingcost' in the ALTO Information Resource Directory: Link Delay, Delay Variation, Packet Loss, Residual Bandwidth, Available Bandwidth,linkstate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-wu-alto-json-te There's also a htmlized version available at: http://tools.ietf.org/html/draft-wu-alto-json-te-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ 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
