From nobody Tue Jul 27 06:28:18 2021 Return-Path: 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 ; 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 ; 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 ; 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" To: "'Qin Wu'" , "'LUIS MIGUEL CONTRERAS MURILLO'" Cc: References: In-Reply-To: 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: 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 13:28:18 -0000 Hi, Luis and Qin, Thank you very much for the comments.=20 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. =20 As for integrating data from different data source via BGP, = BGP-LS=EF=BC=8CI 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. =20 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=20 -----Original Mail----- =E5=8F=91=E4=BB=B6=E4=BA=BA: Qin Wu [mailto:bill.wu@huawei.com]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B47=E6=9C=8823=E6=97=A5 = 21:17 =E6=94=B6=E4=BB=B6=E4=BA=BA: LUIS MIGUEL CONTRERAS MURILLO; Cheng Zhou =E6=8A=84=E9=80=81: alto@ietf.org =E4=B8=BB=E9=A2=98: 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 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: alto [mailto:alto-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 LUIS MIGUEL CONTRERAS MURILLO =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B47=E6=9C=8821=E6=97=A5 = 22:50 =E6=94=B6=E4=BB=B6=E4=BA=BA: Cheng Zhou =E6=8A=84=E9=80=81: alto@ietf.org =E4=B8=BB=E9=A2=98: 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 En nombre de Cheng Zhou Enviado el: = mi=C3=A9rcoles, 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----- =E5=8F=91=E4=BB=B6=E4=BA=BA: I-D-Announce = [mailto:i-d-announce-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 internet-drafts@ietf.org =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B46=E6=9C=8825=E6=97=A5 = 11:40 =E6=94=B6=E4=BB=B6=E4=BA=BA: i-d-announce@ietf.org =E4=B8=BB=E9=A2=98: 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=C3=B3n 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=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede = estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n. 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=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o = _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto