Subject: [alto] Unified properties salient design points

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 28 Mar 2017 16:21:12 -0400

Dear all,

As multiple discussions, we feel that the unified properties draft (),
although not a working group draft, can be an important piece to help
finish several remaining working items.

For those who are not tracking the document, the design might appear to be
simple: it is after all just a simple key-value map. When conducting a real
design, many issues, many quite general, however, appear. Hence the design
can benefit from good feedback from the good talents of this group. The
objective of this email is to make clear the salient points of the current
design. We will go over and discuss them Friday during the WG session.

D1. The goal is to provide properties to entities.

D2. Each entity must have an entity name to be identified. An entity name
is a typed (domained) string, in a format of <domain>:<name>, e.g.,
"ipv4:192.1.1.1", "pid:myid1", "ane:myane111". The <domain> provides
essentially the type of the name.

D3. There are essentially three types of domains: global, per-resource,
per-query (dynamic):

D3.1 ipv4 and ipv6 are global, in that they are not dependent on particular
resources;

D3.2 pid depends on a particular network map resource;

D3.3 ane (abstract network element) may depend on a particular query of an
ALTO resource. So far we cannot handle such case well. There can be
multiple design options, but each adds more complexity.

D4. Aggregation of entities is allowed, to improve scalability. Hence, an
entity name may be either an individual entity or a set. An example is an
IP prefix.

D4.1 An implication of 4. is that we need to handle property inheritance.
Multi-inheritance is tricky, as OOP multi-inheritance demonstrated. So far
longest prefix matching (LPM) avoids the problem. But we need to decide if
we want to have a spec on future design of this aspect.

D5. Property names are in a global namespace, to enforce global, consistent
usage of property names.

It is not a long list but contains many interesting design points.

Looking forward to good discussions soon!

Richard

---

From: Shawn Lin <[email-masked]>
Date: Thu, 30 Mar 2017 23:22:54 +0800

Hi Richard and all,

I have some thoughts about capabilities definition in property map.
Currently, the capabilities is defined like this:

object {
    DomainName domain-types<1..*>;
    PropertyName prop-types<1..*>;
} PropertyMapCapabilities

It looks all good for IRD example in 7.3 in [EPM] because “ipv4” and “ipv6”
are all belong to Internet Address Domain. But I think this capabilities
definition does not expose the relationship between domain types and
property types. Different domain types may have different set of property
types and a same property name in different domain type may have different
meanings (section 2.5 in [EPM]).

Let us consider the following example, a client receives a IRD information
from a ALTO server,

“my-property-map”: {
    …
    “capabilities”: {
        “domain-types”: [ “ipv4”, “pid” ],
        “prop-types” : [ “country”, “state”, “property-only-for-domain-
type-pid”]
   }
    …
}

and this client may construct its filter property map request like below
since it does not know property “property-only-for-pid” is only for domain
type pid.

{
    “entities”: [ “ipv4:192.0.2.0/26”, “ipv4:192.0.2.0/28” ],
    “properties”: [ “property-only-for-domain-type-pid”]

}

Responses of this request will be always empty, while this client never
knows that it construct a meaningless request.

One potential solution is that we can define capabilities as a map, domain
-> {properties}.

object {
    DomainName domain-types<1..*>;
    DomainPropertyTypes domain-prop-types<1..*>;
} PropertyMapCapabilities
object {
     [JSONString domain-type];
     PropertyName prop-types<1..*>;
} DomainPropertyTypes;

The IRD information in above example can be modified like this:

“my-property-map”: {
    …
    “capabilities”: {
        “domain-types”: [ “ipv4”, “pid” ],
        “prop-types” : [
            [“country”, “state”],  // ipv4->{properties}
            [“country”, “state”, “pid-specified-property”]]    //
pid->{properties}
   }
    …
}

With additional information of the relationship between domain types and
properties types, the client will not send meaningless request any more. :)

Bests,
Shawn Lin

[EPM] https://datatracker.ietf.org/doc/html/draft-roome-alto-
unified-props-new

On Wed, Mar 29, 2017 at 4:21 AM, Y. Richard Yang <[email-masked]> wrote:

> D3.1 ipv4 and ipv6 are global, in that they are not dependent on
> particular resources;
>
> D5. Property names are in a global namespace, to enforce global,
> consistent usage of property names.
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>

---

From: xin wang <[email-masked]>
Date: Thu, 30 Mar 2017 18:46:52 +0000

Dear Richard and all,

I think one interesting problem for unified properties is that how to support more powerful filtered property map. Specifically, a server should be able to answer the requests like “can you give me the properties of all endpoints in pid1?” or “can you give me the locations of links whose bandwidth is larger than 100Mbps?"

There are several potential ways to achieve that:

a. Filter entities based on their properties
This would be very similar with the “where” statement in SQL. The problem of this approach would be how to make servers express their filtering capabilities easily. For example, a server should be able to tell clients like “you cannot filter entity1 based on property1” or “you can use the regular expression to filter the property2 for entity2”. It is important to make clients understand what they can do with filtered property map.

b. Provide a tree structure to organize entities
Every node in the tree is an entity. Servers define the structure of the tree. Specifically, they define edges like a pid entity can have children nodes which are endpoint entities. Therefore clients can ask “give me all endpoint entities who are the children of pid1 entity”. However, this tree structure cannot help for the question “can you give me the locations of links whose bandwidth is larger than 100Mbps?”

Thanks,
Xin

________________________________
From: alto <[email-masked]> on behalf of Y. Richard Yang <[email-masked]>
Sent: Tuesday, March 28, 2017 16:21
To: IETF ALTO
Subject: [alto] Unified properties salient design points

Dear all,

As multiple discussions, we feel that the unified properties draft (), although not a working group draft, can be an important piece to help finish several remaining working items.

For those who are not tracking the document, the design might appear to be simple: it is after all just a simple key-value map. When conducting a real design, many issues, many quite general, however, appear. Hence the design can benefit from good feedback from the good talents of this group. The objective of this email is to make clear the salient points of the current design. We will go over and discuss them Friday during the WG session.

D2. Each entity must have an entity name to be identified. An entity name is a typed (domained) string, in a format of <domain>:<name>, e.g., "ipv4:192.1.1.1", "pid:myid1", "ane:myane111". The <domain> provides essentially the type of the name.

D3. There are essentially three types of domains: global, per-resource, per-query (dynamic):

D3.1 ipv4 and ipv6 are global, in that they are not dependent on particular resources;

D3.3 ane (abstract network element) may depend on a particular query of an ALTO resource. So far we cannot handle such case well. There can be multiple design options, but each adds more complexity.

D4. Aggregation of entities is allowed, to improve scalability. Hence, an entity name may be either an individual entity or a set. An example is an IP prefix.

D4.1 An implication of 4. is that we need to handle property inheritance. Multi-inheritance is tricky, as OOP multi-inheritance demonstrated. So far longest prefix matching (LPM) avoids the problem. But we need to decide if we want to have a spec on future design of this aspect.

D5. Property names are in a global namespace, to enforce global, consistent usage of property names.

Richard

---

From: Kai Gao <[email-masked]>
Date: Thu, 30 Mar 2017 15:05:49 -0400

Hi all,

Shawn has raised an important issue that in a single unified property 
map, suggesting that entities of ALL "domain-types" MUST contain ALL 
types declared in "prop-types".

Regarding D3 in Richard's original post about "addressing" in different 
domains, one possibility is to define a global addressing for all domain 
types. For example, per-resource domain such as PID can have addresses 
like "PID:${network-map-id}.${PID}" while dynamic queries can also have 
addresses like "ane:${query-id}:${ane-id}" or even 
"ane:${pv-service-id}.${query-id}.${ane-id}.

Meanwhile, it seems reasonable that this unified property map should 
include corresponding network maps or cost services in "uses" field of 
its IRD entry.

Universal addressing assumes users can make queries on any property 
type, which may make optimization impossible if user only requires a 
subset of prop types.

Regards,
Kai

On 03/30/2017 11:22 AM, Shawn Lin wrote:
> It looks all good for IRD example in 7.3 in [EPM] because “ipv4” and 
> “ipv6” are all belong to Internet Address Domain. But I think this 
> capabilities definition does not expose the relationship between 
> domain types and property types. Different domain types may have 
> different set of property types and a same property name in different 
> domain type may have different meanings (section 2.5 in [EPM]).
>
>
> Let us consider the following example, a client receives a IRD 
> information from a ALTO server,
>
>     “my-property-map”: {
>         …
>         “capabilities”: {
>             “prop-types” : [ “country”, “state”,
>     “property-only-for-domain-type-pid”]
>        }
>         …
>     }
>
> and this client may construct its filter property map request like 
> below since it does not know property “property-only-for-pid” is only 
> for domain type pid.
>
>     {
>         “entities”: [ “ipv4:192.0.2.0/26 <http://192.0.2.0/26>”,
>     “ipv4:192.0.2.0/28 <http://192.0.2.0/28>” ],
> Responses of this request will be always empty, while this client 
> never knows that it construct a meaningless request.
>
> One potential solution is that we can define capabilities as a map, 
> domain -> {properties}.
>
>     object {
> With additional information of the relationship between domain types 
> and properties types, the client will not send meaningless request any 
> more. :)
>
> Bests,
> Shawn Lin
>
> [EPM] 
> https://datatracker.ietf.org/doc/html/draft-roome-alto-unified-props-new 
> <https://datatracker.ietf.org/doc/html/draft-roome-alto-unified-props-new>
>
> On Wed, Mar 29, 2017 at 4:21 AM, Y. Richard Yang <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear all,
>
>     As multiple discussions, we feel that the unified properties draft
>     (), although not a working group draft, can be an important piece
>     to help finish several remaining working items.
>
>     For those who are not tracking the document, the design might
>     appear to be simple: it is after all just a simple key-value map.
>     When conducting a real design, many issues, many quite general,
>     however, appear. Hence the design can benefit from good feedback
>     from the good talents of this group. The objective of this email
>     is to make clear the salient points of the current design. We will
>     go over and discuss them Friday during the WG session.
>
>     D2. Each entity must have an entity name to be identified. An
>     entity name is a typed (domained) string, in a format of
>     <domain>:<name>, e.g., "ipv4:192.1.1.1", "pid:myid1",
>     "ane:myane111". The <domain> provides essentially the type of the
>     name.
>
>     D3.3 ane (abstract network element) may depend on a particular
>     query of an ALTO resource. So far we cannot handle such case well.
>     There can be multiple design options, but each adds more complexity.
>
>     D4. Aggregation of entities is allowed, to improve scalability.
>     Hence, an entity name may be either an individual entity or a set.
>     An example is an IP prefix.
>
>     D4.1 An implication of 4. is that we need to handle property
>     inheritance. Multi-inheritance is tricky, as OOP multi-inheritance
>     demonstrated. So far longest prefix matching (LPM) avoids the
>     problem. But we need to decide if we want to have a spec on future
>     design of this aspect.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/alto>
>
>
>
>

---

From: Shenshen Chen <[email-masked]>
Date: Fri, 31 Mar 2017 03:34:03 +0800

Dear Richard and all,

I'd like to participate in the discussion and got some thoughts after
reading the previous discussion and
"draft-roome-alto-unified-props-new-00". Here they are:

IMHO Map and constraints solver (which contains linear/set constraints
for ALTO, e.g, le, eq, subset, superset) are some kind of silver
bullets for data-structure and algorithm respectively. Thus, about
"the powerful filtered property map" Tony just mentioned, I prefer the
solution a., which is similar to the general filter mentioned in
https://mailarchive.ietf.org/arch/msg/alto/TYmEmha7SvMaquS_BhXTBcCmZ5c.

In D3.3, per-query is definitely stateful, but per-resource may not.
The per-query could be considered as per-resource by specifying
property map (with different vtag) for each query. Determined by the
implementation, it's possible to use a generic prop-map for every
query which is stateless.

In D4, I think the set of entities belongs to an aggregation could be
considered as a kind of property. IP prefix implies a set of IPs in a
compact way, but others may not. ALTO provide the dependency based on
resource. The user can trace dependency on their on by querying such
property for an aggregation  (e.g., IP-prefixes for PID) and using it
as a constraint in "the powerful filtered property map".

Best Regards,
Shenshen