Subject: Re: [alto] Ato extension for representing SDN policies

From: Wendy Roome <[email-masked]>
Date: Tue, 14 Apr 2015 16:35:25 -0400

Guohai,

https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/
presents an extension to add time-dependency to cost maps. Eg, the
extended cost map could say the cost from A->B is 20 from 9:00 to 12:00,
and 10 from 12:00 to 17:00, etc.

Would that solve your problem?

	- Wendy Roome

On 04/08/2015, 15:00, "[email-masked]" <[email-masked]>
wrote:

>Message: 1
>Date: Wed, 8 Apr 2015 13:18:44 +0000
>From: ChenGuohai <[email-masked]>
>To: ??? <[email-masked]>, Richard Yang Y. <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [alto] Ato extension for representing SDN policies
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset="gb2312"
>
>Hi Huaming,All
>Getting policy rules does benefit to traffic optimization. In addition to
>that it can reduce ALTO request and response.
>For example, a policy is that band between a pair of src(A)and dst is 20M
>between 11:00 to 14:00 and is 10M for other time. And band between other
>src(B,C,D ....) and this dst is 15M. The ALTO client can use this policy
>in selecting more optimal peers without sending ATLO cost map request to
>ALTO server now and then.
>ALTO client select src(A) as the peer between 11:00 to 14:00 and one of
>src(B,C,D....) at other time.
>Make sense?
>
>BR
>Guohai
>

---

From: ChenGuohai <[email-masked]>
Date: Wed, 15 Apr 2015 11:05:54 +0000

hi Wendy,
Extension in 'https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/' works for this kind policy,And there are many other kind policies  in ECA modes, ECA stands for Event Condition and Action.
BRGuohai
> Date: Tue, 14 Apr 2015 16:35:25 -0400
> From: [email-masked]
> To: [email-masked]
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Thu, 23 Apr 2015 08:25:55 +0000

Hi Huaming and Guohai,

Thanks for bringing this case. I've been looking at a way to support your example policy settings with ALTO. Indeed, ALTO is also meant to convey provider policy and preferences terms of values assigned to metrics and properties on end to end paths. In your example "policy" is expressed in terms of a triplet conveying (protocol, port, QoS). 

One issue: QoS and policy as you mention ("These rules maybe include source/destination address, protocols, ports, QoS, actions and so on") can be specified with multiple metrics and properties. So defining it as a specific set of metric is tricky as the set may vary among providers.

Instead, the ALTO protocol and its multi-cost extension allows you specifying your policy in the way proposed below:  

- The client requests and gets every metric of the set that "composes" this policy. All the available metrics of the provider ALTO server are specified in the IRD. 
- If the composition of this set needs to be specified, the IRD may be used in a way to be discussed among the WG.

If as Guohai suggests, one of the metrics is time sensitive, the ALTO Client can get the corresponding calendar, specified in https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/ as Wendy proposes.

I'll get back on policy-based EPG overlapping several PIDs is a next mail. 

Any thoughts on the proposal below? 

Thanks,
Sabine

-------------------------------------------------------------
GUOHAI proposal

"multi-cost-types" : [
        {"cost-mode": "policy", "cost-metric": "policy"},
        {"cost-mode": "policy", "cost-metric": "policy"}
      ]
    }
    "cost-map" : {
      "PID1": { "PID1":[null,null],   "PID2":[<TCP,80,10M>,<UDP,120,20M>]},
      "PID2": { "PID1":[<TCP,80,10M>,<UDP,120,20M>], "PID2":[null,null]}
         }

New proposal

"multi-cost-types" : [
        {"cost-mode": "string", "cost-metric": "transport-protocol-id"},
        {"cost-mode": "string", "cost-metric": "port-number"}
        {"cost-mode": "numerical", "cost-metric": "bandwidth"}
      ]
    }
    "cost-map" : {
      "PID1": { "PID1":[null,null],   "PID2":[<TCP,80,10M>,<UDP,120,20M>]},
      "PID2": { "PID1":[<TCP,80,10M>,<UDP,120,20M>], "PID2":[null,null]}
         }

This proposal puts the Port Nb in "string" mode as this is handled as an ID rather than a quantity. 

-------------------------------------------------------------

>>-----Message d'origine-----
>>De : alto [mailto:[email-masked]] De la part de Wendy Roome
>>Envoyé : mardi 14 avril 2015 22:35
>>À : [email-masked]
>>Objet : Re: [alto] Ato extension for representing SDN policies
>>
>>Guohai,
>>
>>extended cost map could say the cost from A->B is 20 from 9:00 to
>>12:00, and 10 from 12:00 to 17:00, etc.
>>
>>>Getting policy rules does benefit to traffic optimization. In addition
>>>to that it can reduce ALTO request and response.
>>>For example, a policy is that band between a pair of src(A)and dst is
>>>20M between 11:00 to 14:00 and is 10M for other time. And band between
>>>other src(B,C,D ....) and this dst is 15M. The ALTO client can use
>>this
>>>policy in selecting more optimal peers without sending ATLO cost map
>>>request to ALTO server now and then.

---

From: ChenGuohai <[email-masked]>
Date: Fri, 24 Apr 2015 02:53:46 +0000

Hi Sabine,Many thanks for your effort.I must say that draft @ https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/ can solve the example problem. If the policy is time-varying ,there are may be some composite cost-type. Policy may be expressed in (time period, protocol,port, QOS).

BR,Guohai
> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Thu, 23 Apr 2015 08:25:55 +0000