Subject: [alto] FW: I-D Action: draft-wu-alto-json-te-00.txt

From: Qin Wu <[email-masked]>
Date: Mon, 8 Jul 2013 07:48:23 +0000

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-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 08, 2013 3:21 PM
To: [email-masked]
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-masked]
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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 14 Jul 2013 22:01:14 -0400

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?

- If so, a feedback is that ALTO Cost Metric need to follow the RFC 6390:

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?

- 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 <- "}" ?
    "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. 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?

- 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? 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],

Please let me know if I understand you correctly.

Thanks!

Richard

On Mon, Jul 8, 2013 at 3:48 AM, Qin Wu <[email-masked]> wrote:

>         Title           : JSON Format Extensions for Traffic Engineering
> (TE) performance metrics in the ALTO Information Resource Directory
>         Author(s)       : Qin Wu
>                           Liang Xia
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 16 Jul 2013 01:46:33 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Y. Richard Yang
Sent: Monday, July 15, 2013 10:01 AM
To: Qin Wu
Cc: [email-masked]; Xialiang (C)
Subject: Re: [alto] FW: I-D Action: draft-wu-alto-json-te-00.txt

Hi Qin,

- 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.

[Qin]: Agree, however we are not new cost metric in the current draft, currently we consider link delay as constraint of 'routingcost'.

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": {

            "endpoints": {

                    "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": {

                  }

              }

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;

     [PIDFilter  pids;]

} ReqFilteredCostMap;

object {

     PIDName srcs<0..*>;

     PIDName dsts<0..*>;

} PIDFilter;

object {

     CostType   cost-type;

     [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:

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):

[Qin]:Good point, . We can make this more clear in the next version, thank for your proposed change.

Thanks!

Richard
On Mon, Jul 8, 2013 at 3:48 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Hi,folks:

Regards!
-Qin
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, July 08, 2013 3:21 PM
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-wu-alto-json-te-00.txt

Abstract:

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 16 Jul 2013 14:09:03 -0400

Hi Qin,

Please see below.

On Mon, Jul 15, 2013 at 9:46 PM, Qin Wu <[email-masked]> 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-masked] [mailto:[email-masked]] *On Behalf
> Of *Y. Richard Yang
> *Sent:* Monday, July 15, 2013 10:01 AM
> *To:* Qin Wu
> *Cc:* [email-masked]; 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:****
>
> ** **
>
> 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’.****
>
> ** **
>
>
>      BCP0170) (Status: BEST CURRENT PRACTICE)****
>
> ** **
>
> 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],****
>
>                   }****
>
>               }****
>
>  ** **
>
> filtering. ****
> ** **
> [Qin]:Correct, agree.****
>
> ** **
>
> ****
> 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?****
>
> ** **
>
> 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-masked]> wrote:****
>
> Hi,folks:
> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>directories:
> http://www.ietf.org/shadow.html
> https://www.ietf.org/mailman/listinfo/alto****
>
> ** **
>

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Jul 2013 01:17:19 +0000

Hi, Richard:
Here is my reply inline below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Y. Richard Yang
Sent: Wednesday, July 17, 2013 2:09 AM
To: Qin Wu
Cc: [email-masked]; 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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Y. Richard Yang
Sent: Monday, July 15, 2013 10:01 AM
To: Qin Wu
Cc: [email-masked]<mailto:[email-masked]>; Xialiang (C)
Subject: Re: [alto] FW: I-D Action: draft-wu-alto-json-te-00.txt

Hi Qin,

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):

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