Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links

Qin Wu <bill.wu@huawei.com> Thu, 06 July 2023 02:17 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 E9B87C1519BC for <alto@ietfa.amsl.com>; Wed, 5 Jul 2023 19:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_DOTEDU=1.999] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X64Jpf1SjF3V for <alto@ietfa.amsl.com>; Wed, 5 Jul 2023 19:17:47 -0700 (PDT)
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 3448BC15153D for <alto@ietf.org>; Wed, 5 Jul 2023 19:17:46 -0700 (PDT)
Received: from lhrpeml100001.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QxKph58Z5z67pnp; Thu, 6 Jul 2023 10:14:20 +0800 (CST)
Received: from canpemm100007.china.huawei.com (7.192.105.181) by lhrpeml100001.china.huawei.com (7.191.160.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Thu, 6 Jul 2023 03:17:43 +0100
Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm100007.china.huawei.com (7.192.105.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Thu, 6 Jul 2023 10:17:41 +0800
Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2507.027; Thu, 6 Jul 2023 10:17:41 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Danny Lachos <dlachos@benocs.com>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>, "Y. Richard Yang" <yry@cs.yale.edu>, IETF ALTO <alto@ietf.org>
Thread-Topic: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
Thread-Index: AdmvrfbNWlMVW1OZRgS5T9DjE+ZjRQ==
Date: Thu, 06 Jul 2023 02:17:40 +0000
Message-ID: <f0ac99965c004d2b82f373b9d417fc49@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.118.68]
Content-Type: multipart/alternative; boundary="_000_f0ac99965c004d2b82f373b9d417fc49huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/Z4sfCIBknlyreNnZBIsWaH1WYO8>
Subject: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 06 Jul 2023 02:17:52 -0000

Hi, Danny:
BGP community can be seen as a tag attached to the BGP routes exchanged between two BGP peers.
It is interesting to see ALTO network map can be generated based on BGP-communities, two questions I want to ask here:

1.       We have many common BGP communities, e.g., local AS community, route target community, route origin community, do you think all these communities can be used to generate network map

2.       For network map, we usually map IP addresses to PIDs, e.g.,

       "network-map" : {
         "PID0" : { "ipv6" : [ "::/0" ] },
         "PID1" : { "ipv4" : [ "0.0.0.0/0" ] },
         "PID2" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/24" ] },
         "PID3" : { "ipv4" : [ "192.0.2.0/25", "192.0.2.128/25" ] }
       }
      So when we introduce communities, do you think such mapping should be modified, replaced? What format will looks like?
      e.g., should establish the mapping between PIDs and community or should we define the network map other than ipv4/ipv6 network map?

-Qin
发件人: alto [mailto:alto-bounces@ietf.org] 代表 Danny Lachos
发送时间: 2023年7月5日 15:59
收件人: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>; Y. Richard Yang <yry@cs.yale.edu>; IETF ALTO <alto@ietf.org>
主题: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links


Hi Luis,
Thanks for starting this thread

See a quick comment below:
1/ extension of ALTO to consider operational simplicity. Here fits the proposal of introducing BGP communities in ALTO. The rationale is that operators use BGP communities quite often as mechanism for applying policies and determining certain behaviors on the IP addresses grouped in the form of communities. This seems quite useful as well at the time of exposing associated information (metrics, topology, etc) as enabled by ALTO. An initial draft can be found here: https://github.com/luismcontreras/alto-bgp-communities
The plan is to generate version -01 for IETF 117.
Regarding the use of BGP information (including BGP communities), I was wondering how to process this data. Should it be considered an aggregation process?
This is because tons of data will eventually be received, and in this case, the BGP routing information could be aggregated into subnet prefixes grouped by their attributes (Communities, BGP nextHop, etc.).
This process will massively compress the BGP data and then this re-structured and aggregated data could be used to generate, for instance, ALTO network maps based on BGP-Communities.

Make sense?
On 26.06.23 23:13, LUIS MIGUEL CONTRERAS MURILLO wrote:
Hi all,

Related to Topic B on maintenance of ALTO, as a way of summary of what has been discussed during the last weeks, we could have two major sub-topics:

1/ extension of ALTO to consider operational simplicity. Here fits the proposal of introducing BGP communities in ALTO. The rationale is that operators use BGP communities quite often as mechanism for applying policies and determining certain behaviors on the IP addresses grouped in the form of communities. This seems quite useful as well at the time of exposing associated information (metrics, topology, etc) as enabled by ALTO. An initial draft can be found here: https://github.com/luismcontreras/alto-bgp-communities
The plan is to generate version -01 for IETF 117.

2/ security aspects of ALTO. This has been discussed in both one of the interim meetings (see https://datatracker.ietf.org/meeting/interim-2023-alto-05/materials/slides-interim-2023-alto-05-sessa-security-aspects-regarding-alto-luis-00) and one ad-hoc discussion meeting (https://mailarchive.ietf.org/arch/msg/alto/HnhO5H5xy4hBGtfm3JI7-K9mq3Y/). The rationale for this activity is to improve the security around the deployment and operation of ALTO in production networks. As commented during the interim, there are a number of security issues documented so far, like:
1.       A high-level discussion of security issues in the ALTO problem statement [RFC5693]
2.       Unwanted information disclosure risks, as well as specific security-related requirements in the ALTO requirements document [RFC6708].
3.       Issues related ALTO server discovery in [RFC7286]
4.       Identified cases for ALTO deployments in [RFC7971]
5.       Security considerations in the remaining RFCs
However, new security concerns emerge from deployments, such as:
1.       Obfuscation of PIDs, and the handling of them in scenarios with multiple ALTO clients
2.       Mechanisms for isolation of the ALTO server from direct client interaction
3.       Secure retrieval of information from external components (e.g., probes, etc)
4.       etc
A potential first step could be to document these new security considerations and then concentrate on those not solved representing relevant threats in ALTO operation.

There could be other relevant topics related to the maintenance of ALTO part from the two commented above.

Any further ideas on this respect?

Of course for those interested on the topics above, please comment.

Thanks in advance

Best regards

Luis

De: alto <alto-bounces@ietf.org><mailto:alto-bounces@ietf.org> En nombre de Y. Richard Yang
Enviado el: miércoles, 21 de junio de 2023 1:47
Para: IETF ALTO <alto@ietf.org><mailto:alto@ietf.org>
Asunto: [alto] June 20, 2023 meeting minutes and discussion working links

Hi all,

As suggested by Ayoub, Jordi and others during the weekly meeting today, starting from today, the note taker will not only update the meeting minutes page (https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md), but also provide a text summary and comments, if appropriate, on the meeting. So below are my quick comments and the full meeting minutes are below; the archive is at the link above.

Regarding comments, the most important item that I, as a note taker, take away is the wonderful discussion about how to organize future work discussions. In particular, the participants divided the potential work into 4 areas, and created 4 github issues. We also created a common Google doc to allow systematic write up. The links to them are below.

In particular, the four areas and their coordinators are:
- A: Integration of data sources and their exposures; coordinator: Jordi, Luis and Kai
- B: Maintenance of ALTO protocol; coordinator: Luis, Richard
- C: Security and trust; coordinators: Ayoub, Junichi, Motoyoshi
- D: New architectural extensions; coordinators: Roland and Sabine

We sure can adjust the coordinators. So so, please let me know, and we can adjust the page. The plan is that the coordinators will closely with the chairs (Qin and Med) to make concrete progress. The coordinators will kick off the discussions.

Richard as note taker on June 20, 2023

==== Meeting Minutes Text ====

IETF, ALTO Meeting: June 20, 2023

Agenda:
1.       Transport and OAM documents
1.       Transport: https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport/issues
2.       OAM: https://github.com/ietf-wg-alto/draft-ietf-alto-oam-yang/issues
3.       ALTO Future Work: https://mailarchive.ietf.org/arch/msg/alto/uIFD6Dhikfu4J4PYcpJTbsiXbnE/ https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md
4.       Preps for IETF 117:
1.       Drafts and presentations that the ALTO group plans to work on
2.       Agenda
5.       New revision of Green Networking Metrics draft in opsawg: https://datatracker.ietf.org/doc/draft-cx-opsawg-green-metrics/

Minutes

*Note taker: Richard
1.  Charter documents: transport and OAM updates
1.       OAM: Jensen and Med had a discussion on the draft and submit the revision to IESG. The document is now waiting for AD review.
2.       Transport: Richard sent a note to Martin Thompson, to provide the justification on introducing server push using PUSH PROMISE. It includes two basic reasonings: lower load, and the feature is optional; Kai updated that Med sent two pull requests and sent the latest version for AD review, and wait for updates.
2.  Updates on future work on ALTO
1.  Overview: Jordi started with an update on the planning: Please follow the ongoing conversation on the WG mailing list initiated by Sabine, engaged by Jordi and Luis; the WG welcomes conversations by all; please socialize the ideas; leadership is important and please take ownership; this WG meets each week, and we do not know any other IETF WG that meets each week, but because we meet each week, we do not use the mailing list, which may appear to be inactive by those not attending the weekly meeting.
2.  Individual topics:
1.       Jordi summarized that from the mailing list, item 3 appears to be the most preferred; please do discussions, propose a charter item and then write documents; The goal is to go to 117 and should be prepared.
2.       Richard commented that one of his focus points will be on data sources, which can be more informational than standard. Luis advised that there can be two types of approaches: bottom-up (individuals propose ideas), and top-down (chairs/AD guidance).
3.       Luis suggests that we should take a look at chair-mentioned items such as BGP communities, and security; mid-term: such as data sources, please go to the mailing list.
3.  Work organization: Meeting notes work plan: Ayoub gave the suggestion that note taker shares the note to the mailing list, some kind of annotated meeting minutes. Roland clarified that the sharing notes can be double sent, or summary/highlights, or up to note taker. Organizing discussions: Luis/Jordi: email as record, GitHub tickets to organize; Jordi creates 4 tickets, and puts links to doc.
4.  Issues, leads, and working documents:
1.  Topic A:
1.       GitHub issue: #48<https://github.com/ietf-wg-alto/wg-materials/issues/48>
2.       Topic coordinator: Jordi, Kai
2.  Topic B:
1.       GitHub: #49<https://github.com/ietf-wg-alto/wg-materials/issues/49>
2.       Topic coordinator: Roland, Sabine
3.  Topic C:
1.       GitHub: #50<https://github.com/ietf-wg-alto/wg-materials/issues/50>
2.       Topic coordinator: Ayoub, Junichi, Motoyoshi
4.  Topic D:
1.       GitHub: #51<https://github.com/ietf-wg-alto/wg-materials/issues/51>
2.       Coordinator: Luis, Jordi
5.  Discussion Google doc:
1.       https://docs.google.com/document/d/1rpziU7NZEE8f84XkJSjMhEIHUA5G7rXkGB5c_7UFxUY/edit?usp=sharing
6.  Goals: Enabling conversations and concrete documents (compute, edge service, etc), need to focus; real good way to make progress is internet-draft (ID) as ground truth, from dynamic to stable, with focus on writing drafts for concrete results).


--
--
 =====================================
| Y. Richard Yang <yry@cs.yale.edu<mailto:yry@cs.yale.edu>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

________________________________

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 confidential and privileged 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
________________________________

Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a privacidad.web@telefonica.com<mailto:privacidad.web@telefonica.com>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>.

We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to privacidad.web@telefonica.com<mailto:privacidad.web@telefonica.com>. You may consult additional information on the processing of your data in our Privacy Policy<https://www.telefonica.com/en/wp-content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-Privacy-Policy.pdf>.

Informamos que o responsável pelo tratamento dos seus dados é a entidade do Grupo Telefónica vinculada ao remetente, a fim de manter o contato professional e administrar a relação estabelecida com o destinatário ou com a entidade à qual esteja vinculado. Você pode entrar em contato com o responsável do tratamento de dados e exercer os seus direitos escrevendo a privacidad.web@telefonica.com<mailto:privacidad.web@telefonica.com>. Você pode consultar informação adicional sobre o tratamento do seus dados na nossa Política de Privacidade<https://www.telefonica.com/es/politica-de-privacidade-de-terceiros/>.



_______________________________________________

alto mailing list

alto@ietf.org<mailto:alto@ietf.org>

https://www.ietf.org/mailman/listinfo/alto

--

Danny Lachos | Senior Network Engineer



BENOCS GmbH, Berlin

+49 305 7700 0417

dlachos@benocs.com<mailto:dlachos@benocs.com>

www.benocs.com<http://www.benocs.com>



Visit us on LinkedIn: https://www.linkedin.com/company/benocs/