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

[Kai GAO <[e-mail]>]

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

>
> On Wed, Jun 19, 2019 at 8:19 AM Kai GAO <[e-mail]> 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
>
>