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 protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/alto > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
