Re: [alto] Meeting minutes for Dec 8, 2020
Hi Qin, Thanks for your comments. Please see my response inline. Jensen On Sat, Dec 12, 2020 at 10:16 PM Qin Wu wrote: > Hi, Jensen: > > I think pub sub mechanism is more value for the interface between ALTO > server and network, maybe not limited to be used in the interface between > ALTO client and ALTO server. > [Jensen] Exactly. I think many southbound protocols are using the pub-sub mechanism now. But I don't have a strong opinion about whether we need to define a unified southbound interface between the ALTO server and network. > For your proposed solution 2, you might reuse the general protocol > extension proposed by Sabine. Your proposal focus on Pub sub mechanism and > data model. > [Jensen] I did not see how Sabine's proposal can support my CDN use case. But I agree that my protocol extension proposal might be merged into the recharter item "general protocol extension". However, we need to clarify the scope of this recharter item. Even though we name it "general", the scope of it cannot be unlimited. We can discuss the details during the meeting today. > Also I am wondering what do you see the key difference between SSE and pub > sub and why SSE is not sufficient. > [Jensen] As a transport mechanism, I think SSE can be an implementation of pub-sub. To implement pub-sub, I think SSE is functional. Of course, HTTP/2 can provide fancier features to make it more efficient. But as an ALTO extension (i.e., RFC8895), I think the current update/control stream service is limited. e.g., It cannot handle the input change very well. > > > -Qin > > *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Jensen Zhang > *发送时间:* 2020年12月10日 0:08 > *收件人:* LUIS MIGUEL CONTRERAS MURILLO < > luismiguel.contrerasmuri...@telefonica.com> > *抄送:* alto-weekly-meet...@googlegroups.com; kai...@scu.edu.cn; > alto@ietf.org > *主题:* Re: [alto] Meeting minutes for Dec 8, 2020 > > > > Hi all, > > > > I just post the slides that I presented in the meeting yesterday. For > people who are interested but was not able to attend the meeting yesterday, > please feel free to check the slides and give me any feedbacks. > > > > @Luis, thanks for your update about the deployment progress. About how to > get up-to-date information, I feel the current SSE service has some > limitations. Based on our internal discussion several months ago, I would > like to propose some extensions to fit the Telefonica CDN requirements > better. You can check the slides and give some further comments. > > > > @Sabine, you mentioned the potential overlap between my extension proposal > on operation automation and the general extensions yesterday. I don't have > any strong opinions on this so far. It seems that any protocol extension > can have an overlapping issue with the general extensions recharter item. > What would be the scope of the general extensions item? Can you try to > clarify this? > > > > Thanks, > > Jensen > > > > > > On Wed, Dec 9, 2020 at 11:15 PM LUIS MIGUEL CONTRERAS MURILLO < > luismiguel.contrerasmuri...@telefonica.com> wrote: > > 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. > > > > 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. > > > > 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 *En nombre de *kai...@scu.edu.cn > *Enviado el:* miércoles, 9 de diciembre de 2020 13:27 > *Para:* alto@ietf.org; 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
Re: [alto] Meeting minutes for Dec 8, 2020
Hi, Jensen: I think pub sub mechanism is more value for the interface between ALTO server and network, maybe not limited to be used in the interface between ALTO client and ALTO server. For your proposed solution 2, you might reuse the general protocol extension proposed by Sabine. Your proposal focus on Pub sub mechanism and data model. Also I am wondering what do you see the key difference between SSE and pub sub and why SSE is not sufficient. -Qin 发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jensen Zhang 发送时间: 2020年12月10日 0:08 收件人: LUIS MIGUEL CONTRERAS MURILLO 抄送: alto-weekly-meet...@googlegroups.com; kai...@scu.edu.cn; alto@ietf.org 主题: Re: [alto] Meeting minutes for Dec 8, 2020 Hi all, I just post the slides that I presented in the meeting yesterday. For people who are interested but was not able to attend the meeting yesterday, please feel free to check the slides and give me any feedbacks. @Luis, thanks for your update about the deployment progress. About how to get up-to-date information, I feel the current SSE service has some limitations. Based on our internal discussion several months ago, I would like to propose some extensions to fit the Telefonica CDN requirements better. You can check the slides and give some further comments. @Sabine, you mentioned the potential overlap between my extension proposal on operation automation and the general extensions yesterday. I don't have any strong opinions on this so far. It seems that any protocol extension can have an overlapping issue with the general extensions recharter item. What would be the scope of the general extensions item? Can you try to clarify this? Thanks, Jensen On Wed, Dec 9, 2020 at 11:15 PM LUIS MIGUEL CONTRERAS MURILLO mailto:luismiguel.contrerasmuri...@telefonica.com>> wrote: 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. 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. 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 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
Re: [alto] Meeting minutes for Dec 8, 2020
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 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. Give
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. 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. 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 En nombre de kai...@scu.edu.cn Enviado el: miércoles, 9 de diciembre de 2020 13:27 Para: alto@ietf.org; 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
[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 proce