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? Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
