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

["Y. Richard Yang" <[e-mail]>]

On Thu, Jun 20, 2019 at 9:24 PM Kai GAO <[e-mail]> wrote:

>
>
>>> 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.
>

Thanks, Kai! One key power of ALTO is the ability to create network
abstractions and hence I feel strongly on (1). It is not fully clear to me
whether the path vector abstraction should be clear in separating type (1)
properties and type (2) properties. Let me post a couple of use cases to
better understand the settings during the discussion on the 26th.

Richard