Luis: 发件人: alto [mailto:alto-boun...@ietf.org] 代表 LUIS MIGUEL CONTRERAS MURILLO 发送时间: 2020年12月9日 23:16 收件人: kai...@scu.edu.cn; alto@ietf.org; alto-weekly-meet...@googlegroups.com 主题: Re: [alto] Meeting minutes for Dec 8, 2020
Hi Kao, all, Yesterday it was bank holiday in Spain, so I couldn’t attend the meeting. My apologies. A couple of comments after reading the minutes of the meeting: 1/ W.r.t. the integration of ALTO and Telefonica CDN we will start integrating ALTO with a mock-up of one of the operations of Telefonica this month. The way in which the CDN will get up-to-date information of network status is not yet 100% defined, but clearly SSE is a potential path to follow. [Qin]: Thank for update, CDN case is a typical case for ALTO protocol. Have you considered pub sub mechanism instead of SSE, which can provide near real time information to you. 2/ Regarding the integration with cellular, I would like to bring your attention to the recent specification from ETSI MEC on integration with 5G networks [1]. Even if the case is not the same, the potential ways of integration could be similar. [Qin]: Good reference, I see this a more concrete use case which allow the MEF system to select appropriate UPF and corresponding data network. Best regards Luis [1] ETSI GR MEC 031, “MEC 5G Integration”, v2.1.1, October 2020. https://www.etsi.org/deliver/etsi_gr/MEC/001_099/031/02.01.01_60/gr_MEC031v020101p.pdf De: alto <alto-boun...@ietf.org<mailto:alto-boun...@ietf.org>> En nombre de kai...@scu.edu.cn<mailto:kai...@scu.edu.cn> Enviado el: miércoles, 9 de diciembre de 2020 13:27 Para: alto@ietf.org<mailto:alto@ietf.org>; alto-weekly-meet...@googlegroups.com<mailto:alto-weekly-meet...@googlegroups.com> Asunto: [alto] Meeting minutes for Dec 8, 2020 Dear all, Please find below the meeting minutes for the weekly meeting on Dec 8. Please let me know if anything important is missing or misinterpreted. Thanks! Best, Kai Open issues: - Jensen will post the link to his slides and bring the discussion to the mailing list on how to handle the overlapping of operation automation and general extension - Get volunteers to interact with other meetings/forums to present the designs of ALTO and get feedback - Collect meeting information for related forums/workshop chances Discussion 1 ------------------ Jensen presented the update on the development of alto server. It exposes some API for ALTO operators to create/read/update/delete ALTO information resources. It also supports multipart messages. An ALTO information resource can access multiple data sources: internal/external/reactive. He also presented the current design of the API using YANG. Discussions: Richard: Is this the backend API for the ALTO server? Jensen: Yes. Qin: This looks like a data model. The backend will be part of the ALTO server. Richard: What is the purpose of this model? One purpose of the model is to give a YANG model for ALTO protocol? Kai: I guess the question is why providing the API using the YANG language instead of following the JSON-based data models which is used by the frontend ALTO API? Richard: The model is API exposed by the ALTO server to the backend. Jensen presented the example to create an ALTO network map based on BGP information. Discussions: Richard: How do you configure the BGP information? Jensen: You specify the algorithm and the parameters of the algorithm. Jensen presented handling dynamicity. There are two types of dyanmicity: network dynamicity and demand dynamicity. He presented the use case of Telefonica CDN where the ALTO client need to detect potential prefix changes and subscribe accordingly. Solution 1 is to extend the SSE extension to allow clients update existing subscriptions. The second extension is to specify conditions/constraints to specify which flows/metrics it is interested in. Discussions: Sabine: There is some overlapping with general extension. Qin: Luis proposed to separate the automation in two parts: southbound and northbound. We need to figure out how to handle the overlapping. Richard: We should invite Lyle and Farni. Meeting item 2 ------------------ Chunshan mentioned that O-ran can provide a wide range of information but are not widely deployed. In 3gpp, only the CP is used but network service chaining headers may be used. How should we move forward given the current 3gpp standards? Discussions: Sabine: Regarding cellular information, if we want to expose them, even if we use acceleration mechanisms (such as IB), the question is still is, we should define the needs for the application? What pace do they need? What delay do they tolerate? We should sort out cases where an application really need cellular information update which require transport-speedup mechanisms. The first step is to find doable use cases (metrics and applications that need them). Richard: Your concern is that 3gpp may not provide a lof of information. Given that Tencent may be a major user of the system, you may put demands on what information should be exposed, will it be provided by 3gpp? Chunshan: 3gpp wants to get information from the clients instead of allowing clients pulling information from the network. A lot of key vendors are reluctant to provide information to outside. Richard: Applications oftentimes have choices. My app can use multiple operation modes. Chunshan: 3gpp can expose but only limited information. Richard: Suggestion: First we initiate the design for O-ran, the more flexible model. Second, we attend 3gpp meetings and have discussions. Chunshan: Maybe we can present the need of information as the view of the IETF to the 3GPP Qin: The current proposal is still an individual proposal. Richard: Is it possible to revise the MoWIE design and to illustrate the benefits of the design? If we have convincing use case, we may be able to convince IETF & 3GPP. Qin: But then we might have to delay our charter proposal. Sabine: Let's start with simple starting points before going to more complex settings. Chunshan mentioned that 30 sec is doable. Even to do this, we do need extensions to support cellular information. Maybe we can start on the mailing list on what information applications need and that is not existing right now. What could both be achievable and useful? Then we can say that we do need extensions. Lyle and other people also proposed some drafts on cellular information. Gang: For the IETF, it may take one or two years to finish the standardization. Spec for O-RAN will be ready early next-year. The interface to get the cellular information will be ready. For 3GPP, it's still the direction that we want to push forward the design to 3GPP. Richard and Qin discussed how to proceed with the recharter. Richard also proposed that the WG can go to other WG/forums to present the work of ALTO and get feedback. Discussions: Richard: We collect the texts by everyone and start to do the revision next week. We also need to make sure we handle the overlapping part properly. Sabine: I can go to nmrg in particular on the topic on intent-based networking and addressing the where attribute in the standardized way. ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
