Hi, Richard: Here is my reply inline below. From: [email protected] [mailto:[email protected]] On Behalf Of Y. Richard Yang Sent: Wednesday, July 17, 2013 2:09 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, Please see below. On Mon, Jul 15, 2013 at 9:46 PM, Qin Wu <[email protected]<mailto:[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]> [mailto:[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]<mailto:[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". [Qin]: Yes, My initial idea is calculating "routingcost" based on existing metrics advertised by draft-ietf-ospf-te-metric-extensions-04. Just like MoS Score metric calculation, MoS Score for one application is calculated based on some other metrics like packet loss, delay, jitter. But not sure "routing cost" can be calculated in the same way since 'routing cost' is more general metric and it is not clear to how routing cost is calculated by reading ALTO base protocol and whether calculation of 'routingcost' should take performance metrics into account or not. 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. [Qin]: Perfect, I get your point, so that means we still need to extend syntax of "constraint" defined in ALTO base protocol? I feel that extension to the more general syntax will be beneficial, but may be in the next version. What do you think? [Qin]: Sure, thanks for your good suggestions. I think it is very reasonable. Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
