Re: [alto] I-D Action: draft-hzx-alto-network-topo-00.txt

Cheng Zhou <zhouchengyjy@chinamobile.com> Tue, 27 July 2021 13:28 UTC

Return-Path: <zhouchengyjy@chinamobile.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 730EA3A088A for <alto@ietfa.amsl.com>; Tue, 27 Jul 2021 06:28:17 -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, 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 hCc3ny4ID71B for <alto@ietfa.amsl.com>; Tue, 27 Jul 2021 06:28:12 -0700 (PDT)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 29F853A088F for <alto@ietf.org>; Tue, 27 Jul 2021 06:28:00 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee1610009bc4f9-99c9e; Tue, 27 Jul 2021 21:27:27 +0800 (CST)
X-RM-TRANSID: 2ee1610009bc4f9-99c9e
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmccPC (unknown[222.129.39.199]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee7610009bce0e-8a13a; Tue, 27 Jul 2021 21:27:27 +0800 (CST)
X-RM-TRANSID: 2ee7610009bce0e-8a13a
From: "Cheng Zhou" <zhouchengyjy@chinamobile.com>
To: "'Qin Wu'" <bill.wu@huawei.com>, "'LUIS MIGUEL CONTRERAS MURILLO'" <luismiguel.contrerasmurillo@telefonica.com>
Cc: <alto@ietf.org>
References: <e75de9be55b54106a1005316fd5bc005@huawei.com>
In-Reply-To: <e75de9be55b54106a1005316fd5bc005@huawei.com>
Date: Tue, 27 Jul 2021 21:27:46 +0800
Message-ID: <01c301d782eb$30b7b430$92271c90$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: zh-cn
Thread-Index: Add/w70fdWdfimLXTJOCoykfzlldygC718OA
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/XE5qZWSo1Y2WTNEfYjmrZsciAD8>
Subject: Re: [alto] I-D Action: draft-hzx-alto-network-topo-00.txt
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: Tue, 27 Jul 2021 13:28:18 -0000

Hi, Luis and Qin,

Thank you very much for the comments. 
You are correct, the devices from which we collect topology data include both network device and controller. The data we collect from the device, may be limited to single device visibility to the network topology. The data we collect from the controller have a good network visibility to the network topology data. Controller focuses on collected data aggregated from each network device. Maybe we can hide such complexity to the upper layer application. That is to say, we only collect network topology from the controller or NMS.
 
As for integrating data from different data source via BGP, BGP-LS,I think this is an important part which help build a foundation for ALTO map information query. My thinking is whatever protocol you choose to collect data, it will be great to have a common data model or template to represent the data. Then the cost for conversion from each data format to ALTO map data format will be greatly reduced.
 
Regarding overlay topology building, yes, I think ALTO should provide abstraction or aggregation for network topology data collected from the underlying network, therefore such abstract topology is more likely to be seen as overlay topology which help provide a good network visibility, network diagnosis, even for service function placement.

Thanks and Regards,
Cheng Zhou 

-----Original Mail-----
发件人: Qin Wu [mailto:bill.wu@huawei.com] 
发送时间: 2021年7月23日 21:17
收件人: LUIS MIGUEL CONTRERAS MURILLO; Cheng Zhou
抄送: alto@ietf.org
主题: RE: [alto] I-D Action: draft-hzx-alto-network-topo-00.txt

Hi, Cheng and Luis:
I agree with Luis, we should not limit the data collected only from the device, the network topology data can also be collected from SDN controller or NMS, I assume the devices are referred to both network device but also controller or NMS.
Secondly, the data can be collected from various different data sources, the challenge is we need to integrate BGP collected data, BGP-LS collected data together with NETCONF collected data, or how to integrate TEDB with LSPDB? I can image the network topology data model can be a good basis, and then we can correlate other data source data including VPN performance metric information into the network topology data.
Without solving these integration, I see this is a big obstacle for ALTO deployment

-Qin
-----邮件原件-----
发件人: alto [mailto:alto-bounces@ietf.org] 代表 LUIS MIGUEL CONTRERAS MURILLO
发送时间: 2021年7月21日 22:50
收件人: Cheng Zhou <zhouchengyjy@chinamobile.com>
抄送: alto@ietf.org
主题: Re: [alto] I-D Action: draft-hzx-alto-network-topo-00.txt

Hi Cheng Zhou,

Thanks for sharing. I see interesting aspects on the draft. Let me share my thoughts.

- part of the draft is about how ALTO can get topological information. Today we can retrieve such information through BGP and BGP-LS, and with that build both network and cost map. Your proposal of using NETCONF would be a complementary (or alternative) way of doing so, which is fine. What I'm wondering is the following. We can assume that in a network like that, i.e. leveraging or supporting NETCONF, we will have a controller. So, why do not assume that the ALTO collects the information from a controller rather than from the devices? Not sure if there could be an issue with many components retrieving info from the devices simultaneously, so the controller could unify that process.

- In line with the previous comment, relaying on NETCONF could not be sufficient for having all the information. Could be the case that some vendors do not support the specific model, or even that part of the network does not support NETCONF at all. This issue is not present with BGP, and most probably not present with BGP-LS, so probably it could be needed to yet relay on BGP and BGP-LS for ensuring full collection of the info. Thus some kind of reconciliation between the different databases would be needed. Do you have any insight on this?

- it is interesting the approach of retrieving topologies other than the physical one (I mean, VPN topology). This opens an interesting aspect to explore which I'm particularly interested in. For instance, putting together such overlay view with the performance metrics being proposed in ALTO could be certainly interesting. Other situations can be also of interest. I will think about that and come back with some ideas.

Best regards

Luis

-----Mensaje original-----
De: alto <alto-bounces@ietf.org> En nombre de Cheng Zhou Enviado el: miércoles, 21 de julio de 2021 5:51
Para: alto@ietf.org
Asunto: Re: [alto] I-D Action: draft-hzx-alto-network-topo-00.txt

Hi, All:

As we know, the CDN makes use of an ALTO server to choose a better CDN surrogate. However CDN may not be able to passively listen to routing protocol, nor may have access to other network topology data (e.g., inventory databases).
Based on our analysis, CDN is built on top of underlying network which runs these routing protocols and the network topology can be gathered via BGP-LS or NETCONF YANG. I2RS working group have published various network topology models such as L3 topology model, L2 topology model. We are wondering whether we can use NETCONF protocol to collect these network topology data and translate into ALTO map data.
Here is the relevant draft we proposed in ALTO working group:
https://datatracker.ietf.org/doc/html/draft-hzx-alto-network-topo-00.txt
Please let us know if you have any comments or suggestions.

Thanks and Regards,
Cheng Zhou

-----Original Mail-----
发件人: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] 代表
internet-drafts@ietf.org
发送时间: 2021年6月25日 11:40
收件人: i-d-announce@ietf.org
主题: I-D Action: draft-hzx-alto-network-topo-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : Network Topology data retrieval using ALTO
protocol
        Authors         : Hanshu Hong
                          Cheng Zhou
                          Chongfeng Xie
                          Qiufang Ma
        Filename        : draft-hzx-alto-network-topo-00.txt
        Pages           : 12
        Date            : 2021-06-24

Abstract:
   RFC8345 introduces an abstract YANG data model to represent network
   topologies.  This document uses ALTO protocol to provide access to
   network Topology data such as L3 topology data , data center network
   topology data, flexible enough to enable querying of specific and
   possibly aggregated data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hzx-alto-network-topo/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-hzx-alto-network-topo-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

________________________________

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