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...@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-boun...@ietf.org] 代表 LUIS MIGUEL CONTRERAS MURILLO
发送时间: 2021年7月21日 22:50
收件人: Cheng Zhou
抄送: 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 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
