Subject: [alto] Some considerations about the unified property

From: Jensen Zhang <[email-masked]>
Date: Mon, 27 Mar 2017 20:01:45 +0800

Hi all,

I'd like to resume the discussion about the unified property. From the
discussion [0] between Wendy and Richard, the argument is about: 1) the
hierarchy and inheritance issue. 2) the consistency of the same property
across domains. Here I have some more considerations about this topic.

1. The hierarchical data scheme. The current data scheme is like {Entity ->
{PropertyType -> PropertyValue}}. I'm thinking about if it is possible to
define a more general scheme. Wendy proposed a new approach about unified
cost scheme [1]. And the main argument I remembered is that this approach
is not downward compatible. I do not also want to deprecate the legacy ALTO
services. But why not propose this approach as an extension of the property
map?

2. More general query filter. The unified-prop draft proposes the filtered
property service whose filter is a set of entities. Why not allow the
client to query the property map by setting the constraints of property
values (like constraints in filtered cost map)? Furthermore, we can
introduce an SQL-like feature for the filtered property map service. The
following gives a potential example:

Request:

{
  "entities": [ "flow:1", "flow:2", "flow:3" ],
  "propertyies": [ "ip_src", "ip_dst", "tcp_src" ],
  "constraints": [ "[2] eq 80" ] // Means only selecting the flows whose
tcp_src is equal to 80
}

Welcome to give any comments or propose some new points to discuss.

Best,
Jensen

[0] https://mailarchive.ietf.org/arch/msg/alto/aSg36442jx4-Qtz7mBvfxDsqGSE
[1] https://mailarchive.ietf.org/arch/msg/alto/2l31OYpqzREMe2vBMApZmdhrR80

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 28 Mar 2017 10:48:22 -0400

Dear Jensen,

Thanks a lot for the comment. Please see below.

On Mon, Mar 27, 2017 at 8:01 AM, Jensen Zhang <[email-masked]>
wrote:

> 1. The hierarchical data scheme. The current data scheme is like {Entity
> -> {PropertyType -> PropertyValue}}. I'm thinking about if it is possible
> to define a more general scheme. Wendy proposed a new approach about
> unified cost scheme [1]. And the main argument I remembered is that this
> approach is not downward compatible. I do not also want to deprecate the
> legacy ALTO services. But why not propose this approach as an extension of
> the property map?
>

Let me clarify. Do you mean the scheme of unifying everything into a
mapping of key to value, e.g,

>  Cost Map: (pid, pid)  =>  value
>            Endpoint Costs:  (addr, addr) =>  value
>            Endpoint Props:  (addr, prop-name)  =>  value
>            MultiCost Map:   (pid, pid, cost-type)  =>  value
>            MultiCost Calendar Map: (pid, pid, date-range, cost-type)
>         =>  value
>            Network Map:  (cidr)  =>  pid

I see that this is a more general design but at the same time it helps to
first solve all of the remaining chartered items, before further extension.
Agree?

>   "constraints": [ "[2] eq 80" ] // Means only selecting the flows whose
This is indeed a quite interesting, unifying idea. One concern is that it
adds more complexity. Do you have use cases where this extension, in
particular, the addition of constraints, help?

Richard