Subject: Re: [alto] Meeting info for Nov 17, 2020

From: Qin Wu <[email-masked]>
Date: Mon, 16 Nov 2020 14:14:30 +0000

Regarding the topic 3, I think investigating the configuration, management, and
operation of ALTO systems is interesting, I am wondering how network topology model in RFC8345
and TE topology model in RFC8795 can be translated into network map, property map, cost map?

Or use pub/sub mechanism to subscribe specific data source and publish the event notification to the ALTO server automatically,
Or translated TEDB and LSPDB directly into Network map or Cost map?

Luis’s draft provide a good use case for this, i.e., automatically derived ALTO information from southbound interface.
https://tools.ietf.org/html/draft-contreras-alto-service-edge-02
which also specify additional ALTO protocol extension for computing capability exposure and selection.

-Qin
发件人: alto [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2020年11月16日 21:18
收件人: [email-masked]; [email-masked]
主题: [alto] Meeting info for Nov 17, 2020

Dear all,

We will have the last meeting before the IETF 109 ALTO session at 9:00 am US EST (3 pm CET, 10 pm Beijing Time).

The purpose is to go over and finalize the recharter items. Given that some topics were not presented in the last meeting, I suggest we follow the order below:

1. General extensions

2. New transport

3. Operation automation

4. First hop

5. Multi-domain

Bridge: https://yale.zoom.us/my/yryang

Best,

Kai

---

From: Jensen Zhang <[email-masked]>
Date: Tue, 17 Nov 2020 21:58:35 +0800

Hi Qin,

Glad to see your feedback.

> and TE topology model in RFC8795 can be translated into network map,

Actually, how to automatically translate data collected by southbound into
ALTO information resources (network map, cost map) is not a fully new topic.
RFC7971 has already discussed the related considerations. The newer
southbound interfaces (like what you mentioned, the I2RS topology model and
TE topology model) indeed make it easier. But to generate specific ALTO
information resources, a single data source is usually not enough. I don't
think either the I2RS topology or the TE topology can be directly
translated into the cost map. The generation of property map can be more
complex. It depends on the use case. e.g., like the use case of  the
property map proposed in the path vector document, the property map can be
generated dynamically based on the client query.

>
>
> Or use pub/sub mechanism to subscribe specific data source and publish the
> event notification to the ALTO server automatically,
>

Whether using pub/sub to pull the specific data source may depend on the
type of data source. For LSPDB, usually, we can pull the complete database.
But for some measurement information, like INT, deciding which states to be
measured will be very important.

>
>
> Luis’s draft provide a good use case for this, i.e., automatically derived
> ALTO information from southbound interface.
>

I agree. Luis's draft is a good use case. This topic is more like an
extension to RFC7971. Because of the evolution of both the
application-aware network and ALTO, we need to reconsider the best
practices and potential protocol extension for operations.

To better clarify the scope of this item, we post a proposal to the mailing
list [1]. Looking forward to seeing your further feedback.

[1] https://mailarchive.ietf.org/arch/msg/alto/1Zixzjz62Sh6MSvv6gzKIRl4254/

Thanks,
Jensen

>
>
> -Qin
>
> *发件人:* alto [mailto:[email-masked]] *代表 [email-masked]
> *发送时间:* 2020年11月16日 21:18
> *收件人:* [email-masked]; [email-masked]
> *主题:* [alto] Meeting info for Nov 17, 2020
>
>
>
> Dear all,
>
>
>
> The purpose is to go over and finalize the recharter items. Given that
> some topics were not presented in the last meeting, I suggest we follow the
> order below:
>
>
>
> 1. General extensions
>
> 2. New transport
>
> 3. Operation automation
>
> 4. First hop
>
> 5. Multi-domain
>
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>