Re: [alto] Meeting minutes for Dec 8, 2020

[Jensen Zhang <[e-mail]>]

Hi Qin,

Thanks for your comments. Please see my response inline.

Jensen


On Sat, Dec 12, 2020 at 10:16 PM Qin Wu <[e-mail]> 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:[e-mail]] *代表 *Jensen Zhang
> *发送时间:* 2020年12月10日 0:08
> *收件人:* LUIS MIGUEL CONTRERAS MURILLO <
> [e-mail]>
> *抄送:* [e-mail]; [e-mail];
> [e-mail]
> *主题:* 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 <
> [e-mail]> 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 <[e-mail]> *En nombre de *[e-mail]
> *Enviado el:* miércoles, 9 de diciembre de 2020 13:27
> *Para:* [e-mail]; [e-mail]
> *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
>
> --
> You received this message because you are subscribed to the Google Groups
> "alto-weekly-meeting" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [e-mail].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/alto-weekly-meeting/DB9PR06MB72429646C78C788A81B279DC9ECC0%40DB9PR06MB7242.eurprd06.prod.outlook.com
> <https://groups.google.com/d/msgid/alto-weekly-meeting/DB9PR06MB72429646C78C788A81B279DC9ECC0%40DB9PR06MB7242.eurprd06.prod.outlook.com?utm_medium=email&utm_source=footer>
> .
>
>