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.
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
