Re: [alto] Unified properties salient design points

[Kai Gao <[e-mail]>]

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:
> 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 <http://192.0.2.0/26>”,
>     “ipv4:192.0.2.0/28 <http://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 
> <https://datatracker.ietf.org/doc/html/draft-roome-alto-unified-props-new>
>
> On Wed, Mar 29, 2017 at 4:21 AM, Y. Richard Yang <[e-mail] 
> <mailto:[e-mail]>> 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.
>
>     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
>
>
>
>     _______________________________________________
>     alto mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/alto
>     <https://www.ietf.org/mailman/listinfo/alto>
>
>
>
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto