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:52 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 552A8C14CE51 for <alto@ietfa.amsl.com>; Wed, 5 Jul 2023 19:52:02 -0700 (PDT)
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 uG-Rea1ggNie for <alto@ietfa.amsl.com>; Wed, 5 Jul 2023 19:51:58 -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 A72FEC14CE4A for <alto@ietf.org>; Wed, 5 Jul 2023 19:51:57 -0700 (PDT)
Received: from lhrpeml500002.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QxLbw1zCCz6J74j; Thu, 6 Jul 2023 10:50:04 +0800 (CST)
Received: from canpemm100005.china.huawei.com (7.192.105.21) by lhrpeml500002.china.huawei.com (7.191.160.78) 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:51:54 +0100
Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm100005.china.huawei.com (7.192.105.21) 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:51:52 +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:51:52 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Y. Richard Yang" <yry@cs.yale.edu>, LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
CC: 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: AdmvsI6CBOHGXPpMQsyYFdx0fNBWeA==
Date: Thu, 06 Jul 2023 02:51:51 +0000
Message-ID: <62e22cc502824e9483912fb67698f7b4@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_62e22cc502824e9483912fb67698f7b4huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/8pm4bfRgoNxEpsM7DiyzM3jx-wo>
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:52:02 -0000

Hi, Richard, Luis:

发件人: alto [mailto:alto-bounces@ietf.org] 代表 Y. Richard Yang
发送时间: 2023年6月27日 21:00
收件人: LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com>
抄送: IETF ALTO <alto@ietf.org>
主题: Re: [alto] Topic B - maintenance of ALTO protocol // RE: June 20, 2023 meeting minutes and discussion working links



On Tue, Jun 27, 2023 at 8:33 AM Y. Richard Yang <yry@cs.yale.edu<mailto:yry@cs.yale.edu>> wrote:
Hi Luis,

Thank you so much for starting this thread on Topic B. I feel that this is a crucial topic for the WG to investigate. Please see below.

On Mon, Jun 26, 2023 at 5:18 PM LUIS MIGUEL CONTRERAS MURILLO <luismiguel.contrerasmurillo@telefonica.com<mailto:luismiguel.contrerasmurillo@telefonica.com>> 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.

I like this subtopic! I have adopted a view that ALTO should be divided into 2 layers: a concept/abstraction layer and a transport layer built on top of the concept layer. I feel that there is great work validating the concept layer, for example, the concepts of distance, ranking, say in the flow director, padis work. For transport later, the WG can be flexible and provide multiple transport mechanisms. BGP communities are an excellent, well defined framework to serve as a transport (of both existing alto concepts/abstractions) and also existing networking abstractions). Good direction.

To be specific, I think it will be a worthwhile effort to look into BGP-ALTO; that is, how to use BGP to encode, transport and update ALTO basic information. It can be considered a BGP vertical slice, with BGP-LS as the lower lower layer. Make sense? I will add some more details to the doc.

Talk to many of you soon.

[Qin Wu] As we know, BGP-LS is used to collect the network topology data, ALTO is used to expose the network topology information, RFC7752 has already provided
ALTO and BGP-LS integration use case in figure 3:
     +--------+
     | Client |<--+
     +--------+   |
                  |    ALTO    +--------+     BGP with    +---------+
     +--------+   |  Protocol  |  ALTO  | Link-State NLRI |   BGP   |
     | Client |<--+------------| Server |<----------------| Speaker |
     +--------+   |            |        |                 |         |
                  |            +--------+                 +---------+
     +--------+   |
     | Client |<--+
     +--------+

Figure 3: ALTO Server Using Network Topology Information

Network topology data carried in BGP-LS is modelled as node, link , prefix
ALTO network information resource is modelled as Network map, Cost map, property map, entity property map,
We need to explore how node, link information combing with next hop information, inter-AS link information carried in BGP-LS
   Is transformed into network map, cost map, property map, etc,
   I feel this is the missing pieces we take for granted, in addition, we need to consider how network topology can be correlated with other network data, e.g.,
Performance data which is related to cost map.


Richard