Re: [alto] Ato extension for representing SDN policies

["RANDRIAMASY, SABINE (SABINE)" <[e-mail]>]

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:[e-mail]] De la part de Wendy Roome
>>Envoyé : mardi 14 avril 2015 22:35
>>À : [e-mail]
>>Objet : Re: [alto] Ato extension for representing SDN policies
>>
>>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, "[e-mail]" <[e-mail]>
>>wrote:
>>
>>>Message: 1
>>>Date: Wed, 8 Apr 2015 13:18:44 +0000
>>>From: ChenGuohai <[e-mail]>
>>>To: ??? <[e-mail]>, Richard Yang Y. <[e-mail]>
>>>Cc: "[e-mail]" <[e-mail]>
>>>Subject: Re: [alto] Ato extension for representing SDN policies
>>>Message-ID: <[e-mail]>
>>>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
>>>
>>
>>
>>_______________________________________________
>>alto mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/alto