On Fri, Jun 21, 2019 at 3:27 AM Y. Richard Yang <[email protected]> wrote:
> > On Wed, Jun 19, 2019 at 8:19 AM Kai GAO <[email protected]> wrote: > >> Hi ALTO working group, >> >> 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. >> > > 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? > 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. > > Richard > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
