Dear Randy, I'm glad you brought ADDPATH topic up! Up to 2019 I was running the now-defunct-Isolario project with my colleague Luca at IIT-CNR, and we did set up an ADDPATH-capable route collector. First, my 2 cents on your operator consideration on the consent from original data sources. I'm far from being a legal, but I don't think ADDPATH differs much from collecting regular BGP sessions. After all, at the moment a BGP peer connected with RIS shares pieces of tables (sometimes close to a full table)... if it was sharing data with ADDPATH it would share all the pieces of the tables. I believe that the very same consideration/concern could apply on both case. Here a few random considerations on our Isolario experience with ADDPATH. Sorry in advance for the long post! 1. Overall, we had about 25-30 peers in Isolario sharing data in ADDPATH. One major peer was sharing ~80 different full routing tables coming from different ASes and was particularly interesting for us. Most of the peers using ADDPATH were using Bird to share their data, and the configuration was trivial 2. The size of data collected - RIB snapshots in particular - was very large wrt regular collectors. I recall having RIB snapshots compressed in bz2 of ~1GB and 20MB in average of UPDATE files. It gets of uttermost importance to have high-perfomance MRT data readers to parse these data. Sometimes it is simply not possible to keep the number of peers low on each collector (see the 80 full routes from one single peer case). This is why we deployed - and presented at one of the RIPE meetings - bgpscanner with Lorenzo Cogotti back in time. As far as I know, Lorenzo improved bgpscanner furthermore developing Micro BGP suite (https://labs.ripe.net/author/lorenzo_cogotti/micro-bgp-suite-the-swiss-army-...). 3. Data was often redundant, but never fully redundant. That was a reasonable price to pay to have more data. 4. ADDPATH hides to the collector the possibility to see the full routing table of the direct peer. You have all the tables that contribute in building the table, but you don't have the result of the BGP decision process of the peer. Depending on the kind of application and monitoring done, this could be a problem. In Isolario, we asked to set up a regular BGP session + an ADDPATH session from each peer that shared data with ADDPATH. Of course, this is not an ideal solution and there was nothing that could enforce the binding between the two sessions 5. Back in 2018, there were two separate way of interpreting ADDPATH - both compliant to RFCs. The first - implemented by Bird - consisted in keeping a single path ID for each table shared. Hence it was trivial to map the table to one single source and re-create the table from a reader perspective (e.g. 1.0.0.0/24 1 from table 1, 1.0.0.0/24 2 from table 2, 1.0.1.0/24 1 from table 1). The second - implemented by FRR - consisted in using many different path IDs for each table - still keeping the possibility to distinguish whether the same network was belonging to a different table (e.g. 1.0.0.0/24 1 from table 1, 1.0.0.0/24 2 from table 2, 1.0.1.0/24 3 from table 1). See https://github.com/FRRouting/frr/issues/1743. Of course, this latter approach was creating big headaches to us in matching tables, path IDs and "original peer"... hence in Isolario allowed only ADDPATH from Bird-like data sources. 6. If I recall well - and I may be wrong here - the only way to recognize that the BGP session between the BGP peer and one its peers/providers/customers went down was to search for a storm of withdrawn messages I hope this may be helpful to anyone working around this topic! Best Regards, Alessandro Improta Engineering manager p. +393488077654 e. aimprota@catchpoint.com<mailto:aimprota@catchpoint.com> a. Via Oberdan 53, Pietrasanta (LU) [cid:dc32a76e-0073-4695-9722-21fe3edb8e0a] Learn more about Catchpoint → Watch this 2-minute video!<https://www.catchpoint.com/explainer> [linkedin]<https://www.linkedin.com/company/catchpoint-systems-inc> [twitter] <https://twitter.com/Catchpoint> [facebook] <https://www.facebook.com/catchpoint/> [youtube] <https://www.youtube.com/c/Catchpoint/> ________________________________ From: mat-wg <mat-wg-bounces@ripe.net> on behalf of Randy Bush <randy@psg.com> Sent: Monday, January 23, 2023 1:23 PM To: Measurement Analysis and Tools Working Group <mat-wg@ripe.net> Subject: [mat-wg] some thoughts on add-path and bmp at ripe/ris i have some small thoughts on add-path and BMP in RIPE/RIS. this may hinder more than help, unfortunately. as a researcher, of course i would love a wider view into the AS graph and the views of as many ASs as possible. nom nom. but ... add-path, if not done very carefully, and documented in detail for each peer, will produce views i will not understand. it is analogous to not knowing what view a BGP peer gives RIS today. did it give me a full Nth view into peer X? is the path that of a peer, a customer, a provider? and add-path is worse because it prunes in configuration and vendor- dependent and otherwise unpredictable ways. and, as an operator if P is a RIS peer, and they give RIS BMP showing their input from their peers, upstreams, and customers, those peers, upstreams, and customers have not given thir consent to have their internals published! if they want to have RIS publish their internals, they would peer with RIS and choose what view they present. and, of course, the researcher does not know what view, peer, upstream, or customer P's BMP peer is giving them. same problem as above under add-path. randy -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fmat-wg&data=05%7C01%7Caimprota%40catchpoint.com%7C4a3f6f03586545bb0cb808dafd3cb095%7C0c927d7e38e74a3fa4f2e746ec8a0842%7C0%7C0%7C638100734353256868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NRPYomHv8cur3RN0%2B6P2y748SXw6E86fOUdojz%2BTNCM%3D&reserved=0
