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

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 <godrickk@gmail.com> wrote:

> 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
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>

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