Subject: [alto] Progress on the path vector draft and call for comments

From: Kai GAO <[email-masked]>
Date: Wed, 19 Jun 2019 20:19:14 +0800

Hi ALTO working group,

After some internal discussions, we are reaching some agreements on the
path vector draft. Below are some key design points and your comments and
feedback are highly welcomed.

1. A new cost type for path vector

We feel more comfortable with the cost type used in -v05, where the mode is
"array" and the metric is "ane".

It conveys the idea that the results are JSON arrays and the values should
be interpreted as identifiers of abstract network elements.

2. A mechanism to query properties of abstract network elements

Since we move the property of an abstract network element out of the cost
type, a new mechanism is required so that 1) a server can announce what
properties can be contained in the response, and 2) a client can specify
its desired properties.

Unfortunately, this is one point where we don't have consensus. One simple
solution is to add a new capability (e.g., "ane-properties") to the IRD
entry, and a client should also specify the intended properties in the
"ane-properties" field.

A second option is to reuse the designs of unified property map. Precisely,
a path vector service should announce at least one entity domain "ane" and
associated properties, as defined in the unified property map draft.

3. Encoding two messages

Each path vector response consists of an (endpoint) cost map and a unified
property map. Eventually, we decide to use the multipart/related media type
and specify whether it contains a cost map or an endpoint cost map in the
"type" parameter in the IRD.

This serves two purposes: 1) it guarantees the returned path vector and the
properties are consistent, and 2) it only takes one communication cycle and
the server doesn't have to keep the state.

We are going to present more details about the current design in the draft
discussion meeting next week (June 26) and hopefully finalize the design
before IETF 105 submission deadline (July 8). You are more than welcome to
join the discussion!

Many thanks!

Best,
Kai

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 20 Jun 2019 15:21:22 -0400

Thanks a lot for the summary by Kai. Several of us will meet tomorrow to
discuss the design at 11:00 am US ET tomorrow (Friday). Everyone is
welcome. We will use zoom: https://yale.zoom.us/my/yryang

Richard

On Wed, Jun 19, 2019 at 8:19 AM Kai GAO <[email-masked]> wrote:

> We feel more comfortable with the cost type used in -v05, where the mode
> is "array" and the metric is "ane".
>
> A second option is to reuse the designs of unified property map.
> Precisely, a path vector service should announce at least one entity domain
> "ane" and associated properties, as defined in the unified property map
> draft.
>
> 3. Encoding two messages
>
> This serves two purposes: 1) it guarantees the returned path vector and
> the properties are consistent, and 2) it only takes one communication cycle
> and the server doesn't have to keep the state.
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 20 Jun 2019 15:27:42 -0400

> "ane" and associated properties, as defined in the unified property map

Agree. There are a few design options which we need to agree on. A line of
reasoning is the following:
- An abstract network element is fundamentally a dynamic entity and hence
does not exist without the context of an abstraction query: (1) the
properties (e.g., available bandwidth) based on which it is created, and
(2) the properties, in addition to the creation properties, to return. So
this is a discussion on (2), right?

Richard

---

From: Kai GAO <[email-masked]>
Date: Fri, 21 Jun 2019 09:24:31 +0800

On Fri, Jun 21, 2019 at 3:27 AM Y. Richard Yang <[email-masked]> wrote:

>> Unfortunately, this is one point where we don't have consensus. One
>> simple solution is to add a new capability (e.g., "ane-properties") to the
>> IRD entry, and a client should also specify the intended properties in the
>> "ane-properties" field.
>>

Not exactly. Right now the path vector draft is mixing (1) and (2), at
least for ane properties. But yes, additional properties may also be
appended, such as endpoint properties mentioned by Sabine. I will include
that in the discussion.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 21 Jun 2019 17:07:31 -0400

On Thu, Jun 20, 2019 at 9:24 PM Kai GAO <[email-masked]> wrote:

>>> Since we move the property of an abstract network element out of the
>>> cost type, a new mechanism is required so that 1) a server can announce
>>> what properties can be contained in the response, and 2) a client can
>>> specify its desired properties.
>>>
>> Agree. There are a few design options which we need to agree on. A line
>> of reasoning is the following:

Thanks, Kai! One key power of ALTO is the ability to create network
abstractions and hence I feel strongly on (1). It is not fully clear to me
whether the path vector abstraction should be clear in separating type (1)
properties and type (2) properties. Let me post a couple of use cases to
better understand the settings during the discussion on the 26th.

Richard