[alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt

Discussion:

i***@ietf.org

2018-06-29 17:28:40 UTC

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF.

Title : Unified Properties for the ALTO Protocol
Authors : Wendy Roome
Shiwei Dawn Chen
Sabine Randriamasy
Y. Richard Yang
Jingxuan Jensen Zhang
Filename : draft-ietf-alto-unified-props-new-04.txt
Pages : 30
Date : 2018-06-29

Abstract:
This document extends the Application-Layer Traffic Optimization
(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
properties" to domains of other entities, and by presenting those
properties as maps, similar to the network and cost maps in ALTO.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Randriamasy, Sabine (Nokia - FR/Paris-Saclay)

2018-06-29 18:11:39 UTC

Permalink

Hello,

The main updates in this new version relate to the consistency procedure between ALTO Address Type Registry and
ALTO Entity Domain Registry as discussed during the ALTO WG session in London. This is addressed in section 9. IANA Considerations, where 9.2 specifies the ALTO Entity Domain Registry and 9.2.1. proposes an algorithm to ensure consistency between both registries.

Other updates include:
- in section 1. Introduction: a paragraph introducing ALTO Entity domains,
- In section 6.3, some rewording to clarify between "pid" and "PID" to avoid headaches,
- section 7.3 example IRD: name update for the Endpoint property resource
- section 7.4: example transaction
- Section 10 References: updates and reformatting
- usage of expression "ALTO Entity Domain" throughout the document

Your feeback will be highly appreciated

Thanks
Sabine, Jensen, Dawn

-----Original Message-----
From: alto [mailto:alto-***@ietf.org] On Behalf Of internet-***@ietf.org
Sent: Friday, June 29, 2018 7:29 PM
To: i-d-***@ietf.org
Cc: ***@ietf.org
Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF.

Title : Unified Properties for the ALTO Protocol
Authors : Wendy Roome
Shiwei Dawn Chen
Sabine Randriamasy
Y. Richard Yang
Jingxuan Jensen Zhang
Filename : draft-ietf-alto-unified-props-new-04.txt
Pages : 30
Date : 2018-06-29

Abstract:
This document extends the Application-Layer Traffic Optimization
(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
properties" to domains of other entities, and by presenting those
properties as maps, similar to the network and cost maps in ALTO.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-04

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Qiao Xiang

2018-07-08 03:16:09 UTC

Permalink

Dear Sabine, Jensen and Dawn,

I finished my review on Section 1-6 of the Unified Property draft. In the
attached file,, all the comments are marked wtih "[qiao]". I will send out
the reviews for the remaining sections soon.

Most of my comments are related to consistency and clarity. However, there
are two technical issues I want to emphasize here, to seek the opinions
from you and other WG members:

1. In Section 4.4: in the PropertyMapCapabilities object to define the
capabilities of a Property Map: the types of entity domains and the types
of properties provided in this map are each defined using a list,
respectively. With such a spec, how should the client know which domain has
which property? Consider the case where the server announces that it has a
property map with two entity domains d1 and d2, and property p1 and p2. If
the client wants to know the property of some entities in domain d1, it
sends a filtered property map query to the server. But it turns out, the
server only provides property p1 for domain d2. As such, the client gets a
bunch of "null" or error code. Only by now the client knows that the server
only provides property p1 for domain d2 entities, but a round-trip is
wasted. Simple as this example is, it can turn into a much troubling
scenario: imaging X (e.g., 10) domains and Y (e.g., 20) properties.

One solution to fix this issue, proposed during my offline discussion with
Jensen, is to redefine the PropertyMapCapabilities using an array of
(entity, property) combination.

2. In Section 6.3, the writing seems to only focus on the pid property of
IP entities. But conceptually other entity domains may also have a "pid"
property, right? I understand that this section is mainly to discuss the
compatibility with the pid property provided by ALTO EPS service, but it
should be stated clearly so that the readers would not be confused.

Please let me know if you have any thoughts on these. Thanks.

Best
Qiao

On Fri, Jun 29, 2018 at 2:11 PM Randriamasy, Sabine (Nokia -

Post by Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
Hello,
The main updates in this new version relate to the consistency procedure
between ALTO Address Type Registry and
ALTO Entity Domain Registry as discussed during the ALTO WG session in
London. This is addressed in section 9. IANA Considerations, where 9.2
specifies the ALTO Entity Domain Registry and 9.2.1. proposes an algorithm
to ensure consistency between both registries.
- in section 1. Introduction: a paragraph introducing ALTO Entity domains,
- In section 6.3, some rewording to clarify between "pid" and "PID" to avoid headaches,
- section 7.3 example IRD: name update for the Endpoint property resource
- section 7.4: example transaction
- Section 10 References: updates and reformatting
- usage of expression "ALTO Entity Domain" throughout the document
Your feeback will be highly appreciated
Thanks
Sabine, Jensen, Dawn
-----Original Message-----
Sent: Friday, June 29, 2018 7:29 PM
Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF.
Title : Unified Properties for the ALTO Protocol
Authors : Wendy Roome
Shiwei Dawn Chen
Sabine Randriamasy
Y. Richard Yang
Jingxuan Jensen Zhang
Filename : draft-ietf-alto-unified-props-new-04.txt
Pages : 30
Date : 2018-06-29
This document extends the Application-Layer Traffic Optimization
(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
properties" to domains of other entities, and by presenting those
properties as maps, similar to the network and cost maps in ALTO.
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-04
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-04
Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

--
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University

Jensen Zhang

2018-07-09 07:13:53 UTC

Permalink

Hi Qiao,

Thanks for your review. Authors will consider your comments and update the
document soon. About the technical issues you mentioned, see my comments
inline:

Thanks,
Jensen

Post by Qiao Xiang
Dear Sabine, Jensen and Dawn,
I finished my review on Section 1-6 of the Unified Property draft. In the
attached file,, all the comments are marked wtih "[qiao]". I will send
out the reviews for the remaining sections soon.
Most of my comments are related to consistency and clarity. However, there
are two technical issues I want to emphasize here, to seek the opinions
1. In Section 4.4: in the PropertyMapCapabilities object to define the
capabilities of a Property Map: the types of entity domains and the types
of properties provided in this map are each defined using a list,
respectively. With such a spec, how should the client know which domain has
which property? Consider the case where the server announces that it has a
property map with two entity domains d1 and d2, and property p1 and p2. If
the client wants to know the property of some entities in domain d1, it
sends a filtered property map query to the server. But it turns out, the
server only provides property p1 for domain d2. As such, the client gets a
bunch of "null" or error code. Only by now the client knows that the server
only provides property p1 for domain d2 entities, but a round-trip is
wasted. Simple as this example is, it can turn into a much troubling
scenario: imaging X (e.g., 10) domains and Y (e.g., 20) properties.
One solution to fix this issue, proposed during my offline discussion with
Jensen, is to redefine the PropertyMapCapabilities using an array of
(entity, property) combination.
Sure, we already discussed offline. But after that, I rethink about this

problem. In a single property map resource, the "prop-types" and the
"entity-domain-types" should be fully bound. So if an ALTO server wants to
provide property p1 and p2 for domain d1, and only property p1 for domain
d2, the best practice should be to separate domain d1 and d2 to different
property maps. Does it make sense?

Waiting for more comments from others.

Post by Qiao Xiang
2. In Section 6.3, the writing seems to only focus on the pid property of
IP entities. But conceptually other entity domains may also have a "pid"
property, right? I understand that this section is mainly to discuss the
compatibility with the pid property provided by ALTO EPS service, but it
should be stated clearly so that the readers would not be confused.
Although we do not mention that "pid" property must bind with the IP

entities, I'm not sure whether we should emphasize this. Because in this
document, we only define IP domain and PID domain. And only IP domain may
own the "pid" property. If the future documents define another entity
domain owning a property called "pid", it can specify the semantics by
itself.

Post by Qiao Xiang
Please let me know if you have any thoughts on these. Thanks.
Best
Qiao
On Fri, Jun 29, 2018 at 2:11 PM Randriamasy, Sabine (Nokia -

--
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

Danny Alex Lachos Perez

2018-07-08 17:24:25 UTC

Permalink

Hello Sabine and WG

I reviewed Introduction, S1, S2, S3, and S4 of the Unified Property
draft. My comments are in the attached file (marked with [DANNY]).

Ss

Danny Lachos

On Fri, Jun 29, 2018 at 3:11 PM Randriamasy, Sabine (Nokia -

Jensen Zhang

2018-07-09 07:23:30 UTC

Permalink

Hi Danny,

Thanks for your review. I quickly go over your comments. Many of your
comments are about the format issue. Authors will fix them soon.

Thanks,
Jensen

Post by Danny Alex Lachos Perez
Hello Sabine and WG
I reviewed Introduction, S1, S2, S3, and S4 of the Unified Property
draft. My comments are in the attached file (marked with [DANNY]).
Ss
Danny Lachos
On Fri, Jun 29, 2018 at 3:11 PM Randriamasy, Sabine (Nokia -

_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

Danny Alex Lachos Perez

2018-07-09 19:05:46 UTC

Permalink

Hi Jensen and WG

I finished my review on Sec 5-9.

My comments are in the attached file marked with [DANNY].

Ss

Danny Lachos

Post by Jensen Zhang
Hi Danny,
Thanks for your review. I quickly go over your comments. Many of your
comments are about the format issue. Authors will fix them soon.
Thanks,
Jensen
On Mon, Jul 9, 2018 at 1:24 AM Danny Alex Lachos Perez <

_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

Y. Richard Yang

2018-07-10 23:17:44 UTC

Permalink

Dear WG,

In the process to revise UP to address the comments and make the protocol
as clean as possible, the authors identify one technical issue which we
need WG opinions.

Specifically, it is related to response (Sec. 5.6) to a filtered property
map.

The related new text:
" The response MUST indicate an error, using ALTO protocol error handling,
as defined in Section 8.5 of [RFC7285], if the request is invalid.

Specifically, a Filtered Property Map request can be invalid as
follows:

o An entity address in "entities" in the request is invalid if:

* The domain of this entity is not defined in the "entity-domain-
types" capability of this resource in the IRD;

* The entity address is an invalid address in the entity domain.

A valid entity address is never an error, even if this Filtered
Property Map resource does not define any properties for it.

If an entity address in "entities" in the request is invalid, the
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
in Section 8.5.2 of [RFC7285], and the "value" field of the error
message SHOULD indicate this entity address.

o A property name in "properties" in the request is invalid if this
property name is not defined in the "property-types" capability of
this resource in the IRD.

It is not an error that the Filtered Property Map resource does
not define a requested property's value for a particular entity.
In this case, the ALTO server MUST omit that property from the
response for that endpoint.

If a property name in "properties" in the request is invalid, the
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
in Section 8.5.2 of [RFC7285]. The "value" field of the error
message SHOULD indicate the property name.

The response to a valid request is the same as for the property map
(see Section 4.6), except that it only includes the entities and
properties requested by the client.

It is important that the Filtered Property Map response MUST include
all inherited property values for the specified entities. A Full
Property Map may skip a property P for an entity A if P can be
derived using inheritance from another entitiy B. A Filtered
Property Map request may include only A but not B. In such a case,
the property B MUST be included in the response for A.

[QUESTION to WG: Need to make a decision.] It is possible that the
entities in
the response are different from the entities in the request.
Consider a request for property P of entity A (e.g.,
ipv4:192.0.2.0/31). Assume that P has value v1 for
A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32. Then, the
response will include entities A1 and A2, instead of the request
entity A.

An alternative design is to not enforce this decomposition. The authors feel
that the current revision is better but is open to WG guidance.

Thanks!
Richard

Post by i***@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF.
Title : Unified Properties for the ALTO Protocol
Authors : Wendy Roome
Shiwei Dawn Chen
Sabine Randriamasy
Y. Richard Yang
Jingxuan Jensen Zhang
Filename : draft-ietf-alto-unified-props-new-04.txt
Pages : 30
Date : 2018-06-29
This document extends the Application-Layer Traffic Optimization
(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
properties" to domains of other entities, and by presenting those
properties as maps, similar to the network and cost maps in ALTO.
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-04
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-04
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-04
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

Jensen Zhang

2018-07-11 05:52:20 UTC

Permalink

Hi Richard and WG,

My opinion is to make such a decomposition optional. Because the
decomposition is not always possible, and the decomposition solution may
not be unique. It's hard to enforce it.

So I suggest we can add the following paragraphs to explain it:

===
An ALTO client should be aware that the entities in the response MAY be
different from ones it requests. If entities in the requested domain can be
inherited, the ALTO server MAY decompose a requested entity address into
several entities which could inherit it. One example is the Internet
Address domains: Considering a request for property P of entity A (e.g.,
ipv4:192.0.2.0/31), if P has value v1 for A1=ipv4:192.0.2.0/32 and v2 for
A2=ipv4:192.0.2.1/32, then the ALTO server could return the response
including entities A1 and A2, instead of the requested entity A. The ALTO
server could also return v1 for A1 and v2 for A, and the ALTO client can
also deduce v2 for A2 from the inheritance.

An operator should be aware that if the ALTO server supports the entities
decomposition, there will be potential security considerations. Section 8
(points to the Security Considerations section) discusses the details and
potential solutions.
===

There are two security considerations I can find:

1. If an ALTO client requests a large IP prefix like 0.0.0.0/0, the
decomposition may be very large (equal to the full map), which may consume
a lot of computation resource in the server side.
2. The decomposition may expose the confidential information to the ALTO
client, which may be unexpected by the ALTO server.

Waiting for comments from others.

Best,
Jensen

Post by Y. Richard Yang
Dear WG,
In the process to revise UP to address the comments and make the protocol
as clean as possible, the authors identify one technical issue which we
need WG opinions.
Specifically, it is related to response (Sec. 5.6) to a filtered property
map.
" The response MUST indicate an error, using ALTO protocol error handling,
as defined in Section 8.5 of [RFC7285], if the request is invalid.
Specifically, a Filtered Property Map request can be invalid as
* The domain of this entity is not defined in the "entity-domain-
types" capability of this resource in the IRD;
* The entity address is an invalid address in the entity domain.
A valid entity address is never an error, even if this Filtered
Property Map resource does not define any properties for it.
If an entity address in "entities" in the request is invalid, the
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
in Section 8.5.2 of [RFC7285], and the "value" field of the error
message SHOULD indicate this entity address.
o A property name in "properties" in the request is invalid if this
property name is not defined in the "property-types" capability of
this resource in the IRD.
It is not an error that the Filtered Property Map resource does
not define a requested property's value for a particular entity..
In this case, the ALTO server MUST omit that property from the
response for that endpoint.
If a property name in "properties" in the request is invalid, the
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined
in Section 8.5.2 of [RFC7285]. The "value" field of the error
message SHOULD indicate the property name.
The response to a valid request is the same as for the property map
(see Section 4.6), except that it only includes the entities and
properties requested by the client.
It is important that the Filtered Property Map response MUST include
all inherited property values for the specified entities. A Full
Property Map may skip a property P for an entity A if P can be
derived using inheritance from another entitiy B. A Filtered
Property Map request may include only A but not B. In such a case,
the property B MUST be included in the response for A.
[QUESTION to WG: Need to make a decision.] It is possible that the
entities in
the response are different from the entities in the request.
Consider a request for property P of entity A (e.g.,
ipv4:192.0.2.0/31). Assume that P has value v1 for
A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32. Then, the
response will include entities A1 and A2, instead of the request
entity A.
An alternative design is to not enforce this decomposition. The authors feel
that the current revision is better but is open to WG guidance.
Thanks!
Richard

--
--
=====================================
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto

Y. Richard Yang

2018-07-11 17:54:22 UTC

Permalink

Dear WG,

After extensive discussions, the authors will go with enforcing
decomposition.

Consider a simple use case:
A network map:
defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0
pid1: ipv4:192.0.2.0/25
pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28

Assume that the client queries pid for ipv4:192.0.2.0/26. Without
decomposition, the client will get pid1, through inheritance. Now, the
client can use the result, for example, when lookup pid for 192.0.2.0/28,
locally. The result is pid1 locally but a query to the server is pid2.
Hence, for correctness, the system must notify the client that there are
refinement, which is decomposition.

We are taking a pass of the design and will post by end of this week.

Any comments are greatly appreciated!

Richard

Post by Jensen Zhang
Hi Richard and WG,
My opinion is to make such a decomposition optional. Because the
decomposition is not always possible, and the decomposition solution may
not be unique. It's hard to enforce it.
===
An ALTO client should be aware that the entities in the response MAY be
different from ones it requests. If entities in the requested domain can be
inherited, the ALTO server MAY decompose a requested entity address into
several entities which could inherit it. One example is the Internet
Address domains: Considering a request for property P of entity A (e.g.,
ipv4:192.0.2.0/31), if P has value v1 for A1=ipv4:192.0.2.0/32 and v2 for
A2=ipv4:192.0.2.1/32, then the ALTO server could return the response
including entities A1 and A2, instead of the requested entity A. The ALTO
server could also return v1 for A1 and v2 for A, and the ALTO client can
also deduce v2 for A2 from the inheritance.
An operator should be aware that if the ALTO server supports the entities
decomposition, there will be potential security considerations. Section 8
(points to the Security Considerations section) discusses the details and
potential solutions.
===
1. If an ALTO client requests a large IP prefix like 0.0.0.0/0, the
decomposition may be very large (equal to the full map), which may consume
a lot of computation resource in the server side.
2. The decomposition may expose the confidential information to the ALTO
client, which may be unexpected by the ALTO server.
Waiting for comments from others.
Best,
Jensen