Hi, On 2019-08-15 17:38, Christopher Morrow wrote:
This looks like fun! (a few questions for the RIPE folk, I think though below)
What is the expected load of streaming clients on the RIPE service? (I wonder because I was/am messing about with something similar, though less node and js... not that that's relevant here).
One of the (IMO) most useful features is that you can filter what you want to receive. In fact this makes the service useful :-) So unless you want to tune in to a significant portion of BGP chatter, the load should not be substantial.
I hadn't seen the ripe folk pipe up anywhere with what their SLO/etc is for the ris-live service? (except their quip about: "used to run in a tmux session I had to occassioanlly ssh into <foo> and restart when <foo> rebooted" I believe the end of that quip in Iceland was: "and now its' running as a real service")
It's in between those. We now have a conscious setup which should also be able to scale up, but bits and pieces (like full monitoring of the service) are still being developed.
Also, one of the strengths to the 'monitoring as a service' folks is their number of collection points and breadth of ASN to which they interconnect those points/ RISLive, I think, reports out from ~37 or so RIPE probes, how do we (the internet) get more deployed (or better interconnection to the current sets)? and maybe even more imoprtantly... what's the right spread/location/interconnectivity map for these probes?
RIS Live provides data from RIS, which has a bunch of collectors around the world (see https://www.ripe.net/analyse/internet-measurements/routing-information-servi...) with many hundreds of peering sessions. But it is by no means complete in terms of coverage. If and how the community (NANOG or RIPE or else) should work on optimal data collection is indeed a useful discussion to have. Cheers, Robert
thanks! for showing what's possible with tooling being developed by like minded individuals :)
-chris