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

Qin Wu <bill.wu@huawei.com> Sat, 12 December 2020 14:16 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605543A111E for <alto@ietfa.amsl.com>; Sat, 12 Dec 2020 06:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24EfSuxk7xP6 for <alto@ietfa.amsl.com>; Sat, 12 Dec 2020 06:16:54 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25E13A110A for <alto@ietf.org>; Sat, 12 Dec 2020 06:16:53 -0800 (PST)
Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4CtV5B5ldLz67Ngr; Sat, 12 Dec 2020 22:14:06 +0800 (CST)
Received: from fraeml701-chm.china.huawei.com (10.206.15.50) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Sat, 12 Dec 2020 15:16:49 +0100
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.2106.2 via Frontend Transport; Sat, 12 Dec 2020 15:16:49 +0100
Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.43]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Sat, 12 Dec 2020 22:16:45 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Jensen Zhang <jingxuan.n.zhang@gmail.com>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
CC: "kaigao@scu.edu.cn" <kaigao@scu.edu.cn>, "alto@ietf.org" <alto@ietf.org>
Thread-Topic: [alto] Meeting minutes for Dec 8, 2020
Thread-Index: AdbQkLYaxQFKj071RbScCr7YmsDQIw==
Date: Sat, 12 Dec 2020 14:16:44 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAADC0FB10@dggeml531-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.101.103]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAADC0FB10dggeml531mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/CyRNAdOiGOHPxIMfKza1JDmOakc>
Subject: Re: [alto] Meeting minutes for Dec 8, 2020
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Dec 2020 14:16:58 -0000

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-bounces@ietf.org] 代表 Jensen Zhang
发送时间: 2020年12月10日 0:08
收件人: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
抄送: alto-weekly-meeting@googlegroups.com; kaigao@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.contrerasmurillo@telefonica.com<mailto:luismiguel.contrerasmurillo@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 <alto-bounces@ietf.org<mailto:alto-bounces@ietf.org>> En nombre de kaigao@scu.edu.cn<mailto:kaigao@scu.edu.cn>
Enviado el: miércoles, 9 de diciembre de 2020 13:27
Para: alto@ietf.org<mailto:alto@ietf.org>; alto-weekly-meeting@googlegroups.com<mailto:alto-weekly-meeting@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
--
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 alto-weekly-meeting+unsubscribe@googlegroups.com<mailto:alto-weekly-meeting+unsubscribe@googlegroups.com>.
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>footer>.