Hi Qin, Please see below.
On Mon, Jul 15, 2013 at 9:46 PM, Qin Wu <[email protected]> wrote: > 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.* > *** > > ** > Adding new Cost Metrics may not be too much an impact, but does require registration. The idea of "coupling" is interesting. By coupling, I think you mean using the new metrics as constraints but retrieve "routingcost". In a general setting, I believe that an SQL-like syntax can be quite helpful when defining the filtering service (see page 49): select CostMap<cost-type1> where <PIFilter condition> and <constraints> The current syntax of each constraint item <constraint> is simple: [gt | lt | ge | le | eq ] <value> ... but one way to make it more general is <cost-type2> [gt | lt | ge | le | eq ] <value> ... The current syntax essentially omits <cost-type2> and assumes that it is <cost-type1>. But I feel that the line right above can be more general. I feel that extension to the more general syntax will be beneficial, but may be in the next version. What do you think? Richard > ** > > - 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.**** > > “**** > > ** > I see. I was referring to something like "ms" (milliseconds). > ** > > - 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]> 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]] > On Behalf Of [email protected] > Sent: Monday, July 08, 2013 3:21 PM > To: [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] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>directories: > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto**** > > ** ** >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
