Re: [alto] Unified properties salient design points

[Shawn Lin <[e-mail]>]

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