Hi Qin, Glad to see your feedback.
On Mon, Nov 16, 2020 at 10:14 PM Qin Wu <[email protected]> wrote: > 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? > 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, > > Or translated TEDB and LSPDB directly into Network map or Cost map? > 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. > > https://tools.ietf.org/html/draft-contreras-alto-service-edge-02 > > which also specify additional ALTO protocol extension for computing > capability exposure and selection. > 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 protected]] *代表 *[email protected] > *发送时间:* 2020年11月16日 21:18 > *收件人:* [email protected]; [email protected] > *主题:* [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 > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
