Hi Jensen,
Thanks for bringing the [draft-ietf-alto-cdni-request-routing-alto-03] example
that actually does have a case with 2 used resources and the ambiguity problem
you are pointing.
I would actually also like the insight of the CDNI draft authors on my answer.
(In the examples, I corrected some typos with Upper Case letters).
Thanks, please see below.
Sabine
[draft-ietf-alto-cdni-request-routing-alto-03] provides an example filtered
property map transaction in section 6.2.3:
The request contains:
POST /propmap/lookup/cdnifci-pid HTTP/1.1
...
{
"entities": [
"ipv4:192.0.2.0/24",
"ipv6:2001:db8::/32"
],
"properties": [ "cdni-fci-capabilities", "pid" ]
}
The response contains in its "meta":
...
"dependent-vtags": [
{"resource-id": "my-default-cdnifci-map",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"},
{"resource-id": "my-default-networkmap",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"}
]
...
and provides values for both properties "cdni-fci-capabilities" and "pid".
The request is fine because these 2 properties can be defined on entities in
the requested domains ipv4 and ipv6.
However, the corresponding information resource at "uri"
./propmap/lookup/cdnifci-pid is specified in the example IRD section 3.7.1 as:
"filtered-cdnifci-property-map"
with
"capabilities" : {
"domain-types" : [ "ipv4", "ipv6", "couNtrycode", "asn" ],
"prop-types" : [ "cdni-fci-capabilities", "pid" ]
}
The "uses" member is missing but the response in the example transaction hints
that they are the 2 maps listed in the example response.
The problem with the capabilities of "filtered-cdnifci-property-map" is that
one understands that for instance a "pid" property can be defined on entities
in the "couNtrycode" and "asn" domains, which is not possible.
Therefore, a way to avoid this ambiguity would be to decompose resource
"filtered-cdnifci-property-map" W.R.T. so to say compatible "used" resources as
follows:
"filtered-cdnifci-property-map" : {
"uri" : "http://alto.example.com/propmap/filtered/cdnifci";,
"media-type" : "application/alto-propmap+json",
"accepts" : "application/alto-propmapparams+json",
"uses" : [ "my-default-cdnifci-map" ]
"capabilities" : {
"ENTITY-domain-types" : [ "ipv4", "ipv6",
"couNtrycode", "asn" ],
"prop-types" : [ "cdni-fci-capabilities" ]
}
},
"filtered-cdnifci-property-map" : {
"uri" : "http://alto.example.com/propmap/lookup/cdnifci-pid";,
"media-type" : "application/alto-propmap+json",
"accEPts" : "application/alto-propmapparams+json",
"uses" : [ "my-default-network-map", "my-default-cdnifci-map" ]
"capabilities" : {
"ENTITY-domain-types" : [ "ipv4", "ipv6" ],
"prop-types" : [ "cdni-fci-capabilities", "pid" ]
}
},
And [draft-ietf-alto-unified-props-new] should have a rule to guide the
composition of resources WRT "used" resources and that would look like:
"Each of the resources listed in the "uses" member of an information resource
MUST be compatible with all the elements listed in its "entity-domain-types"
member. Where a "used" resource is defined as compatible if it provides
information that can be mapped to all the listed entity domain types."
For example in the IRD section 7.3 of [draft-ietf-alto-unified-props-new]:
- resources "pid-property-map" and "location-property-map" both use
"default-network-map" which provides information mapped to
"entity-domain-types" "ipv4", "ipv6" in the former and "pid" in the latter.
From: Jensen Zhang <[email protected]>
Sent: Wednesday, October 24, 2018 1:12 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
<[email protected]>
Cc: IETF ALTO <[email protected]>
Subject: Re: [alto] Resume Discussion about the Remaining Issue of
draft-ietf-alto-unified-props
Hi Sabine,
Thanks for your feedback. See my comments inline.
On Thu, Oct 18, 2018 at 1:21 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
<[email protected]<mailto:[email protected]>>
wrote:
Hi Jensen,
Regarding the second point on an unambiguous way to associate a property map
and the information resource it uses, I may have missed something and have a
question on your example:
"uses": ["networkmap1", "pv-costmap1"],
"capabilities": {
"entity-domains": ["ipv4", "ipv6", "ane"],
"properties": ["pid"]
}
Independently of the “uses” member, just looking at the capabilities, I
understand this as:
Client can in particular request the “pid” property of an entity in the “ane”
domain.
Which by the way assumes no entity is a link with endpoints in different PIDs.
As a PIDs is defined in RFC7285 section 5.1 as a set of endpoint addresses,
does this document extend this set to entity addresses?
Good point. Although we can consider to extend the semantics of PIDs, it is not
what this document wants. It is my fault. I took a bad example.
The initial design of this extension was to solve ambiguities by having one
“used” resource per property map, thus “splitting” property maps w.r.t. “used”
maps, see v00 section 2.6 : “Instead of defining the dependency by qualifying
the property name, this document attaches the dependency to the property map as
a whole. Thus all properties in a given property map depend on the same
resource."
Would you have a concrete example where retrieving a property on entities in a
domain requires to both know a network map and a cost-map?
Now I understand your concern. I agree that we need a reasonable example. I
want to take an example to show that one property on entities in a domain may
depend on more than one ALTO resources. But based on our existing standard
drafts, we do not have a reasonable example so far.
But I do think it is necessary to revise the draft to support this. Even there
is no existing standard example requiring multiple dependencies, it is still
possible to happen in the future. If we don't want to make the draft obsolete
very soon, we need to take care. And actually, I find the cdni footprint
property map proposed in draft-ietf-alto-cdni-request-routing-alto may be a
reasonable example.
Before we discuss the property map example, let's clarify one basic concept:
property
Without the context of the entity domain, the concept "property" cannot be
understood. So in this document, we shouldn't use the term "property"
independently.
For example,
the pid property - Invalid
the pid property of the entity in ipv4 domain - Valid
the pid property of the ipv4 entity - Valid
So the statement "all properties in a given property map depend on the same
resource" is not invalid. We should revise it as "all properties of any
entities in a given property map ..."
Now we see the example of the fci footprint property map. From
draft-ietf-alto-cdni-request-routing-alto, an ALTO server can provide the
"cdni-fci-capabilities" property for the cdni footprint entities. In the same
property map, the "cdni-fci-capabilities" property values of the cdni footprint
entities should depend on the same cdni-fci-map.
But there is no entity domain called "cdni footprint". From RFC8006, the cdni
footprint can be ipv4cidr, ipv6cidr, asn and countrycode. As ALTO can provides
the PID entity to express a set of ipv4cidr and ipv6cidr, we can leverage it.
So we can consider the following cdni footprint property map resource:
"cdnifci-prop-map": {
"uri": "http://alto.example.com/propmap/full/cdnifci";,
"media-type": "application/alto-propmap+json",
"capabilities": {
"entity-domains": ["pid"],
"properties": ["cdni-fci-capabilities"]
},
"uses": [...]
}
What the "uses" of this property map should be? The client should have a
network-map to understand what a PID entity is. Then the client should have a
cdni-fci-map to understand what the cdni-fci-capabilities of a PID entity is.
So to interpret this property map, the client requires two ALTO resources.
I believe it is not a special case. In the future, we may have another property
map for the entity-domain "A" and the property "P". The entity in domain A
depends on the resource R1, and the property P of the entity in domain A
depends on the resource R2. So finally, the property P of the entity in domain
A depends on R1 and R2.
Do you think it is reasonable?
Best,
Jensen
Thanks,
Sabine
From: alto <[email protected]<mailto:[email protected]>> On Behalf Of
Jensen Zhang
Sent: Wednesday, September 26, 2018 3:15 PM
To: IETF ALTO <[email protected]<mailto:[email protected]>>
Subject: [alto] Resume Discussion about the Remaining Issue of
draft-ietf-alto-unified-props
Hi ALTOer,
During IETF 102, we agree that the unified properties draft is important and
need to be processed first.. From the update which we presented at IETF 102,
the latest draft has been almost stable. But there are still two unclear points
in the previous revisions:
1. The response of filtered property map query for address blocks.
2. The resource dependencies declaration.
For the first point, we presented the issue and the potential solution during
IETF 102 (p12-p13 of
https://datatracker.ietf.org/meeting/102/materials/slides-102-alto-alto-unified-properties-00.pdf).
The proposed solution should be reasonable. The authors are updating the draft
and including it.
But for the second point, we have not figured out a reasonable solution. So I
want to involve all of the related people to discuss this part.
Briefly, the second point is unclear because the "uses" attribute of a unified
property resource may have ambiguity from the current specification. We take a
simple example to show the ambiguity:
"uses": ["networkmap1", "pv-costmap1"],
"capabilities": {
"entity-domains": ["ipv4", "ipv6", "ane"],
"properties": ["pid"]
}
Based on the current draft, the "uses" attribute is "An array with the resource
ID(s) of resource(s) with which the entity domains in this map are associated",
the client can have several different understandings in this example: (1) all
the entities in this property map depend on networkmap1 or pv-costmap1; (2)
entities in ipv4 and ipv6 domain depend on networkmap1, and entities in ane
domain depend on pv-costmap1; (3) entities in ipv4 domain depend on
networkmap1, entities in ipv6 domain depend on pv-costmap1, entities in ane
domain have no dependency. (4) ...
But all those understandings are not correct. The understanding the server
expects should be: the PID property values of all entities in this map depend
on networkmap1; the entities in ane domain depend on pv-costmap1.
To make the client can understand the resource dependencies of a property map
correctly, we should modify the specification of its "uses" attribute. I have
two proposals:
1. Each combination of "entity-domain" and "property" SHOULD specify its
dependent resource type explicitly. For example, <ipv4, pid> or <ipv6, pid>
depends on a network map; <ane, pid> depends on a network map and a cost map.
2. Each combination of "entity-domain" and "property" SHOULD specify how to use
the dependent resources to interpret this combination. For example, for <pid4,
pid>, the dependent network map is used to validate and interpret the pid
property values; for <ane, pid>, the dependent cost map is used to validate and
interpret the entities in ane domain, and the dependent network map is used to
validate and interpret the pid property values.
If we agree on these two proposals, they will be required for all the
registered ALTO Entity Domains and ALTO Properties, and the future ones. It may
be a critical change but may be necessary..
Do we have any better solution to make the resource dependency declaration
clear? I will appreciate people sharing thoughts..
Best regards,
Jensen
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
