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