Re: [alto] Proposed Agenda for Interims #2-5

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Qiufang,

Thanks for pointing this out.

I think what you propose makes sense. Probably details should be clarified in 
terms of how PIDs defined for the measurement agents could correlate with 
conventional PIDs, i.e., those representing IP address pools. Some ideas come 
to my mind that probably we could discuss.

But yes, I see this interesting to contemplate to understand what kind of 
extensions could be derived from this scenario, certainly interesting for 
network operations.

Thanks for commenting and good to see this reported in the compilation sheet.

Best regards

Luis


De: maqiufang (A) 
Enviado el: miércoles, 26 de abril de 2023 11:12
Para: LUIS MIGUEL CONTRERAS MURILLO 
; Jensen Zhang 
; kai...@scu.edu.cn
CC: IETF ALTO ; xie...@chinatelecom.cn; wang...@chinatelecom.cn
Asunto: RE: [alto] Proposed Agenda for Interims #2-5

Hi, Luis and all

Thanks for this effort. Jensen and Kai, I think your proposals make sense to 
me, maybe could be reflected on the shared spreadsheet?

I’ve Just added one more potential data source to the spreadsheet: LMAP 
(Large-Scale Measurement of Broadband Performance, RFC7594) network measurement 
results. That said, ALTO server can simply work as the LMAP collector and 
accept the report from the measurement agent which performs the measurement 
tasks as instructed by the LMAP controller.

PS. There is a draft 
(https://www.ietf.org/archive/id/draft-xie-alto-lmap-00.txt) related to that, 
the authors plan to revive it very soon.

Best Regards,
Qiufang

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Jensen Zhang
Sent: Wednesday, April 26, 2023 8:29 AM
To: kai...@scu.edu.cn
Cc: IETF ALTO mailto:alto@ietf.org>>; Qin Wu 
mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5

Hi Luis and all,

Thanks for this useful collection of data sources. Besides the data sources 
listed in this collection, I am wondering if the following kinds of data 
sources can also be considered:

1. Prefix information, e.g., internet routing registry (IRR). It provides route 
and provider related information attached to IP prefixes. It may be helpful for 
network/property map generation, or locating the network domain in multidomain 
settings.

2. Data plane information, e.g., routing and forwarding tables read from BGP 
looking glass server or other OAM tools. Although I see the "IETF TE Network 
topology" source can already provide routing information, it may focus on the 
control plane, e.g., routing policy, not the data plane.

3. Telemetry information, e.g., traceroute. It can get both routing and 
performance information. It may have some overlap with the performance metrics.

Looking forward to seeing more discussions on this topic.

Best,
Jensen

On Tue, Apr 25, 2023 at 10:55 PM mailto:kai...@scu.edu.cn>> 
wrote:

Hi Luis and all,



Thanks for the effort. The information is really useful and comprehensive. I 
think it lays a very good foundation to discuss and proceed with potential ALTO 
extensions.



With the rationale that, in my opinion, sets the expectations for each data 
source, I am wondering whether it is beneficial to discuss gaps and constraints 
as well.



For example, I used to work on providing ALTO maps using SDN, or more 
precisely, using Open Daylight. Open Daylight has very good (among the best 
AFAIK) YANG support and the topology models were already support a few years 
back. One problem, however, was that using the topology information alone 
cannot generate high-precision network map or cost map: you still need to know 
where the hosts are attached and what is the routing. Thus, it has to be 
combined with other data sources, for example, host tracker in the SDN case or 
BGP/BGP-LS in provider networks, or be limited to specific networks, for 
example, those using link state routing protocols.



I am not saying that the document should summarize the gaps and/or constraints 
of all the data sources. Rather, I feel that the topic might be a useful input 
to the interim meeting and to future ALTO extensions.



Best,

Kai


-Original Messages
From:"LUIS MIGUEL CONTRERAS MURILLO" 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent Time:2023-04-18 06:23:51 (Tuesday)
To: "mohamed.boucad...@orange.com" 
mailto:mohamed.boucad...@orange.com>>, "IETF 
ALTO" mailto:alto@ietf.org>>
Cc: "Qin Wu" mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5
Hi Med, Qin, WG,

In order to provide inputs for:


* interim #3: Deployment Catalysts

• Proposals to fix the integration complexity and integration with data 
sources

Jordi and I have been working on collecting some references that we consider as 
potential data sources of relevance for the WG and possible integration with 
ALTO. We have collected those inputs here: 
https://docs.google.com/spreadsheets/d/1P4GrhQz_t17jIWg-3b1ycldhBWEEgIAAUZe2vjeO_1U/edit#gid=0

Please, feel 

Re: [alto] Proposed Agenda for Interims #2-5

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Jensen,

Thanks for your comment.

Please, see my answer in line.

Thank you,

Luis

De: Jensen Zhang 
Enviado el: miércoles, 26 de abril de 2023 2:29
Para: kai...@scu.edu.cn
CC: LUIS MIGUEL CONTRERAS MURILLO ; 
IETF ALTO ; Qin Wu 
Asunto: Re: [alto] Proposed Agenda for Interims #2-5

Hi Luis and all,

Thanks for this useful collection of data sources. Besides the data sources 
listed in this collection, I am wondering if the following kinds of data 
sources can also be considered:

1. Prefix information, e.g., internet routing registry (IRR). It provides route 
and provider related information attached to IP prefixes. It may be helpful for 
network/property map generation, or locating the network domain in multidomain 
settings.

[[Luis>]] This can be a useful information to add if different policies apply 
to different administrative domains. I think it could be used for map filtering 
purposes (as described in section 4.1.2 of RFC 7285). For instance thinking on 
the pilot we are doing in Telefonica for integrating ALTO with the Telefonica 
CDN, this property could be used for deciding from which streamer send the 
content to external prefixes of subscribers sitting in ISPs different from 
Telefonica.


2. Data plane information, e.g., routing and forwarding tables read from BGP 
looking glass server or other OAM tools. Although I see the "IETF TE Network 
topology" source can already provide routing information, it may focus on the 
control plane, e.g., routing policy, not the data plane.

[[Luis>]] Not 100% clear to me this point (i.e., your reference to data plane). 
So my answer could not be exactly addressing your question. In my view, 
relaying on tools like BGP looking glass can certainly provide information 
about reachability of prefixes, especially in multi-domain settings where there 
is no possibility of retrieving such information e.g. for another ALTO server. 
So it can help to infer some notion of cost map for a given point in time in 
relation with some IP prefixes. The best would be probably to pair with the 
corresponding ALTO server for that domain for getting the information directly, 
but if this is not possible, BGP looking glass could be certainly an 
alternative for indirectly obtaining such information.

3. Telemetry information, e.g., traceroute. It can get both routing and 
performance information. It may have some overlap with the performance metrics.

[[Luis>]] As before, it would be preferible to pair with corresponding ALTO 
servers for this. If not possible, that could be a way of inferring 
performance, which is somehow similar to what most of the applications make 
today for taking their own service decisions (I mean, inferring behaviors from 
performance metrics observed by their own).


Looking forward to seeing more discussions on this topic.

Best,
Jensen

On Tue, Apr 25, 2023 at 10:55 PM mailto:kai...@scu.edu.cn>> 
wrote:

Hi Luis and all,



Thanks for the effort. The information is really useful and comprehensive. I 
think it lays a very good foundation to discuss and proceed with potential ALTO 
extensions.



With the rationale that, in my opinion, sets the expectations for each data 
source, I am wondering whether it is beneficial to discuss gaps and constraints 
as well.



For example, I used to work on providing ALTO maps using SDN, or more 
precisely, using Open Daylight. Open Daylight has very good (among the best 
AFAIK) YANG support and the topology models were already support a few years 
back. One problem, however, was that using the topology information alone 
cannot generate high-precision network map or cost map: you still need to know 
where the hosts are attached and what is the routing. Thus, it has to be 
combined with other data sources, for example, host tracker in the SDN case or 
BGP/BGP-LS in provider networks, or be limited to specific networks, for 
example, those using link state routing protocols.



I am not saying that the document should summarize the gaps and/or constraints 
of all the data sources. Rather, I feel that the topic might be a useful input 
to the interim meeting and to future ALTO extensions.



Best,

Kai



-Original Messages
From:"LUIS MIGUEL CONTRERAS MURILLO" 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent Time:2023-04-18 06:23:51 (Tuesday)
To: "mohamed.boucad...@orange.com" 
mailto:mohamed.boucad...@orange.com>>, "IETF 
ALTO" mailto:alto@ietf.org>>
Cc: "Qin Wu" mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5
Hi Med, Qin, WG,

In order to provide inputs for:


* interim #3: Deployment Catalysts

• Proposals to fix the integration complexity and integration with data 
sources

Jordi and I have been working on collecting some references that we consider as 
potential data sources of relevance for the WG and possible integration with 
ALTO. We have collected those inputs here: 

Re: [alto] Proposed Agenda for Interims #2-5

[LUIS MIGUEL CONTRERAS MURILLO]

Hi Kai,

You are touching relevant points.

First, regarding the idea of retrieving the topology from the controller. In 
the simpler case, since the controller will already have a topology processed 
from the information retrieved from the network, it can make sense to get it 
from the controller. So, ALTO can benefit from that, thus avoiding to process 
twice the same information. In the more complex situation, to could be the case 
that the SDN controller collects and aggregates information from different 
domains (even under the same administrative responsibility) then simplifying 
again the aggregation and processing of the overall topological information. Or 
even it could be the case where the SDN controllers builds a general view of a 
network leveraging partial views even collected through different protocols 
(e.g., BGP-LS, LLDP, etc). In summary, the benefit could come from simplifying 
the ALTO server processes, just retrieving what has been already aggregated and 
processed.

However it is important what you say. Not all the information could be on the 
topology provided by the SDN controller. For instance, the subnets (IP 
prefixes) representing e.g. residential broadband users which are attached to 
border routers are not present in IETF Network Topology. These subnets should 
be obtained by means of BGP sessions with the route reflectors in the network.

So, even though we can simplify the process of the ALTO server by retrieving 
the internals of the network from the controller (which is useful for building 
the cost map) we yet need to maintain BGP sessions with the RR for 
understanding the IP pools in each PIC (i.e. to build the network map).

Finally going to your question about if it is useful to discuss gaps and 
constraints, my answer id definitely YES.

Thanks so much for your comment,

Luis

De: kai...@scu.edu.cn 
Enviado el: martes, 25 de abril de 2023 16:55
Para: LUIS MIGUEL CONTRERAS MURILLO 
CC: mohamed.boucad...@orange.com; IETF ALTO ; Qin Wu 

Asunto: Re: Re: [alto] Proposed Agenda for Interims #2-5


Hi Luis and all,



Thanks for the effort. The information is really useful and comprehensive. I 
think it lays a very good foundation to discuss and proceed with potential ALTO 
extensions.



With the rationale that, in my opinion, sets the expectations for each data 
source, I am wondering whether it is beneficial to discuss gaps and constraints 
as well.



For example, I used to work on providing ALTO maps using SDN, or more 
precisely, using Open Daylight. Open Daylight has very good (among the best 
AFAIK) YANG support and the topology models were already support a few years 
back. One problem, however, was that using the topology information alone 
cannot generate high-precision network map or cost map: you still need to know 
where the hosts are attached and what is the routing. Thus, it has to be 
combined with other data sources, for example, host tracker in the SDN case or 
BGP/BGP-LS in provider networks, or be limited to specific networks, for 
example, those using link state routing protocols.



I am not saying that the document should summarize the gaps and/or constraints 
of all the data sources. Rather, I feel that the topic might be a useful input 
to the interim meeting and to future ALTO extensions.



Best,

Kai



-Original Messages
From:"LUIS MIGUEL CONTRERAS MURILLO" 
mailto:luismiguel.contrerasmuri...@telefonica.com>>
Sent Time:2023-04-18 06:23:51 (Tuesday)
To: "mohamed.boucad...@orange.com" 
mailto:mohamed.boucad...@orange.com>>, "IETF 
ALTO" mailto:alto@ietf.org>>
Cc: "Qin Wu" mailto:bill...@huawei.com>>
Subject: Re: [alto] Proposed Agenda for Interims #2-5
Hi Med, Qin, WG,

In order to provide inputs for:


* interim #3: Deployment Catalysts

• Proposals to fix the integration complexity and integration with data 
sources

Jordi and I have been working on collecting some references that we consider as 
potential data sources of relevance for the WG and possible integration with 
ALTO. We have collected those inputs here: 
https://docs.google.com/spreadsheets/d/1P4GrhQz_t17jIWg-3b1ycldhBWEEgIAAUZe2vjeO_1U/edit#gid=0

Please, feel free to access and check, all of you should be able to add/drop 
comments as well (let me know in case you need some permission for that). In 
the table we cover potential data sources, the rationale for considering them, 
existing reference work, as well as impacts on current ALTO. We hope this could 
be a basis for discussion for interim #3, but also to trigger discussions on 
the mailing list so we as WG can go to the interim with a more clear notion of 
the data sources and their implications.

Thanks

Best regards

Luis


De: alto mailto:alto-boun...@ietf.org>> En nombre de 
mohamed.boucad...@orange.com
Enviado el: martes, 4 de abril de 2023 8:58
Para: IETF ALTO mailto:alto@ietf.org>>
CC: Qin Wu mailto:bill...@huawei.com>>

Re: [alto] Reminder ALTO interim meeting today at 10am EST (not 9am)

[LUIS MIGUEL CONTRERAS MURILLO]

Thanks Med

(adding also in cc ALTO mailing list).

I have gone through the suggested changes producing a -01 version, yet open for 
comments and discussion. I attach the txt file for your convenience (the diff 
with the published one is easily generated with IETF authors tools).

I have also created a github space for the draft, here: 
https://github.com/luismcontreras/alto-bgp-communities

Best regards

Luis

De: mohamed.boucad...@orange.com 
Enviado el: miércoles, 12 de abril de 2023 16:49
Para: Qin Wu ; Jordi Ros Giralt ; Y. 
Richard Yang ; Jensen Zhang ; 
kai...@scu.edu.cn; Lachlan Keller ; LUIS MIGUEL 
CONTRERAS MURILLO ; Randriamasy, 
Sabine (Nokia - FR/Paris-Saclay) ; 
maqiufang (A) ; ayoub.mess...@fujitsu.com; Motoyoshi 
Sekiya (Fujitsu) ; Chongfeng Xie 
; Cheng Zhou 
Asunto: RE: Reminder ALTO interim meeting today at 10am EST (not 9am)

Hi all,

FWIW, some additional comments on the BGP communities proposal can be seen at 
https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-contreras-alto-bgp-communities-00-rev%20Med.doc

Cheers,
Med

De : Qin Wu mailto:bill...@huawei.com>>
Envoyé : mardi 11 avril 2023 17:21
À : Jordi Ros Giralt mailto:j...@qti.qualcomm.com>>; Y. 
Richard Yang mailto:y...@cs.yale.edu>>; Jensen Zhang 
mailto:jingxuan.n.zh...@gmail.com>>; 
kai...@scu.edu.cn; Lachlan Keller 
mailto:lachlan.kel...@yale.edu>>; LUIS MIGUEL 
CONTRERAS MURILLO 
mailto:luismiguel.contrerasmuri...@telefonica.com>>;
 Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 maqiufang (A) mailto:maqiufa...@huawei.com>>; 
ayoub.mess...@fujitsu.com; Motoyoshi Sekiya 
(Fujitsu) mailto:sekiya.motoy...@fujitsu.com>>; 
Chongfeng Xie mailto:xie...@chinatelecom.cn>>; Cheng 
Zhou mailto:zhoucheng...@chinamobile.com>>
Cc : BOUCADAIR Mohamed INNOV/NET 
mailto:mohamed.boucad...@orange.com>>
Objet : RE: Reminder ALTO interim meeting today at 10am EST (not 9am)

Thank all for participanting the discussion of ALTO interim meeting.
For ALTO OAM and New transport, please keeping on engaging with directorate 
reviewers who raised major issues and make sure all these major issues are 
addressed and related discussion transparent to the ALTO list.

For the next interim meeting plan, we will discuss Deployment Catalyst. 
Unfortunately we run out of time due to accident at the beginning of the 
interim meeting.
I believe the following drafts will be good input to the discussion. I made 
some of comments on these drafts,
Hope these remarks and comments help you understand the direction we suggested.

YANG Data Model for BGP-LS protocol
https://datatracker.ietf.org/doc/rfc7752/
https://datatracker.ietf.org/doc/rfc9085/
https://datatracker.ietf.org/doc/rfc9351/
https://datatracker.ietf.org/doc/rfc8571/
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-sr-policy/
https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ls-te-path-00.txt
Comment: Need to figure how this work is related to or decoupled from ALTO OAM

Extending ALTO by using BGP Communities
Comments:
How many BGP communities do we need to support?
e.g., Route Target Community, Route Origin Community
How BGP Communities can be encoded?
How BGP Communities are different from PID?

ALTO for Querying LMAP Results
https://www.ietf.org/archive/id/draft-xie-alto-lmap-00.txt

How Network Topology data collected using NETCONF/YANG can be translated into 
ALTO Network Map, Cost Map, Endpoint Map?
https://www.ietf.org/archive/id/draft-hzx-alto-network-topo-00.txt

-Qin/Med
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jordi Ros Giralt
发送时间: 2023年4月11日 19:31
收件人: alto@ietf.org
主题: [alto] Reminder ALTO interim meeting today at 10am EST (not 9am)

Hello ALTOers,

Just a reminder that we will be meeting today Tuesday at 10am EST for the ALTO 
interim #3 meeting. The focus of this meeting is on "WGLC follow-up of 
OAM/Transport I-Ds":

- Remote instructions: 
https://meetings.conf.meetecho.com/interim/?short=a6c2968d-b9f9-4ea7-b856-c1ee2e64e0c7
- Agenda 
https://datatracker.ietf.org/meeting/interim-2023-alto-02/materials/agenda-interim-2023-alto-02-alto-01-00
- Session materials: 
https://datatracker.ietf.org/meeting/interim-2023-alto-02/session/alto

Note that at 9am EST we have our usual ALTO weekly meeting. However, today's 
important meeting is the interim, held at 10am EST. So let me suggest that we 
skip the 9am call so we can all focus on the 10am call. I will join the 9am 
call in case anyone needs to be reminded about the 10am interim meeting.

Below you will also find the agendas for the forthcoming interim meetings as 
proposed by the chairs:


* interim #2: WGLC follow-up of OAM/Transport I-Ds

* interim #3: Deployment Catalysts

• Reuse existing network resources to identify ALTO resources (e.g., 
BGP communities)

• Proposals to fix the integration complexity and integration with data 
sources

* interim #4: OAM/Transport