Dear Jensen,

Thanks a lot for the comment. Please see below.

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

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

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?


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


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

Reply via email to