List of Challenges - CAIDA/bgp-hackathon GitHub Wiki

This page lists drafts of potential challenges. This list evolved based on new ideas and feedback from the participants and the community.

Some projects have incomplete descriptions, which serve as starting points. Anybody can provide content/criticism to improve them or propose a new challenge.

Feedback/content can be provided in different ways:

  • in the hackathon application form
  • writing to [email protected]
  • contacting one of the organizers directly

Participants will have the chance to make their final team and challenge selection on the 1st morning of the hackathon event. However, below you will find preliminary associations of participants with challenges based on expressed preferences and/or their expertise.

STABILITY-1

Motivation: Investigating the correlation between control and data plane (in) stability.

Background: The control plane and data plane provide two (sometimes different) views of network reachability and stabilty from a given Vantage Point (VP). It is known that instability in the control plane (frequent route changes or withdrawals towards a given prefix) can result in performance degradation in the data plane. However, there may be control plane instabilities that do not cause any degradation in data-plane performance; conversely, there may be data plane performance degradations that are not caused by control-plane instabilities. The goal of this project is to investigate the correlation between control and data plane instability using real-time BGP update data and reactive measurements from Ark an Atlas VPs.

Tasks:

  1. use BGPstream and BGPmon to detect BGP instability in real-time, and active probing from RIPE and Atlas VPs to detect unreachability episodes or instability in the data plane.
  2. use Ark and ATLAS vantage points to launch active measurements in real-time (traceroutes and pings) towards prefixes detected to be unstable, while the instability still persists.
  3. investigate correlations between instability in data and control plane as observed from different data and control plane VPs.

Proposed by: Amogh Dhamdhere
Interested Participants: TBD
Contacts: amogh[at]caida.org

#####Team 1:

  1. Nathan Owens
  2. Andrew Mulhern
  3. Mark Iversen
  4. Sunny Fugate
  5. -open-

MPLANE-1

Motivation: mPlane is a European FP7 IP project whose aim is the definition of a protocol for the automatic interaction among active/passive probes, repositories for measurement collection and intelligent reasoners for iterative analysis. With its integration into mPlane, BGPStream will be able to export its measurement data to other repositories and reasoners participating mPlane. Most of all, it would be the first source of BGP data available in the mPlame framework.

Background: Each component participating mPlane is provided with an interface, namely, the mPlane proxy. It consists of a simple piece of Python3 code which leverages the reference implementation of the mPlane protocol to expose the capabilities of the component. These capabilities can be, e.g., running and/or collecting measurements in the case of a probe, performing analytics tasks in the case of an repository, launching specific iterative tasks in the case of a reasoner. In other words, by building an mPlane proxy for BGPStream we would allow it to expose its capabilities to other mPlane repositories, clients and reasoners spread around the Internet.

Goals: The goal of the mPlane team participating the BGP Hackathon will be building an mPlane proxy for BGPStream to let it return its measurement results to other mPlane entities. For instance, it will be possible to visualize time series provided by BGPStream in a of Graphite repository in Politecnico di Torino premises, or to allow mPlane reasoners interact with it.

Tasks:

  • Study the BGPStream functionalities.
  • Design and develop the mPlane proxy for BGPStream.
  • Test BGPStream's proxy capabilities for measurement exporting.
  • Visualize the queried results.

Proposed by: Ali Safari Khatouni, Stefano Traverso
Interested Participants: Danilo Giordano
Contacts: ali.safari[at]polito.it, stefano.traverso[at]polito.it

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

RPKI-42

Motivation: Longitudinal recording of RPKI based origin validation deployment.

Background: The Resource Public Key Infrastructure (RPKI) is a security framework dedicated to securing the Internet routing infrastructure. It uses cryptographic certificates to prove the ownership of Internet number resources (i.e. AS numbers and IP prefixes). Part of the RPKI are Route Origin Authorization (ROA) objects, which authorizes an autonomous system to originate one or more prefixes. BGP speaking routers can use ROAs in their routing decisions, for example rejecting invalid announcements.

Goals: Start a platform for longitudinal study of propagation and deployment of RPKI based origin validation on the Internet.

Tasks:

  • Static configuration of anchor and test.
  • Dynamic configuration of anchor and test using the previously built config file
  • Using BGPStream to output routing decisions for anchor and test.
  • Analysis of BGPStreams output to infer origin validation policy.
  • Building a config file to control injection of announcements and capturing of routes using BGPStream.

Follow up tasks:

  • Dynamic configuration of RPKI data. //Longterm, unclear

Background Literature:

Domain experts that can offer help: Randy Bush, Ethan Katz-Bassett, Brandon Schlinker, Chiara Orsini, Matthias Wählisch
Interested Participants: Randy Bush (1), Andreas Reuter (1), Emile Aben (1), Andrew Weiner (3)

#####Team 1:

  1. Andreas Reuter
  2. Randy Bush
  3. Calvin Ardi
  4. Ankit Gupta
  5. -open-

IXP-1

Motivation: At IXPs route servers are a vital instance to support the exchange of routes amongst its members. In contrast to bilateral peering links between two ASes, the usage of a route server still has major drawbacks. One limitation is that peers do not receive information about other peers going up or down. They only see BGP updates, or in worst case BGP withdraws. Taking this into account, an additional entity should signal peers going up or down through BMP. IXP members may integrate BMP into their management systems to, e.g., prefer more stable peers.

Currently, BIRD is the dominant route server implementation and lacks a BMP implementation (addressed by challenge BGPD-1). Introducing a distributed architecture for the route server and BMP multiplexer is beneficially for two reasons:

  • Resilience: As large IXPs have up to 1000 peers, the burden of handling such a large number of BMP sessions would add additional load to route servers.
  • Network reachability: For security purposes route servers located within IXP peering LANs are not publicly accessible. In contrast, the BMP multiplexer shall be publicly accessible.

Implementation details: The BMP multiplexer should be a stand-alone application. It should be configurable which BMP message are redistributed, e.g., limited to only peer up/down notifications. The BMP multiplexer should be route server independent with respect to the huge number of route server implementations such as Quagga, Bird, or GoBGP. The BMP multiplexer should scale up to 1000+ concurrent BMP sessions.

  • Comment from Tim Evens: Rather than write custom code, it may make more sense for the IXP to host an OpenBMP collector (and therefore Kafka instance) that anybody (e.g., peers) can connect to and stream the raw or parsed information (e.g., there is a topic containing parsed peer up/down info). There is also some code (https://github.com/OpenBMP/openbmp-forwarder) to forward a BMP stream from a collector (effectively using Kafka as a buffer). This challenge could extend the forwarder to support multiple “clients”, and add filtering for the raw BMP stream (so that “clients” only receive peer messages, not the updates.

Tasks:

  • Study BMP protocol
  • Study OpenBMP / other BMP implementations
  • Design a scalable BMP multiplexer. Try to reuse as much as possible from OpenBMP / other BMP implementations
  • Begin implementation of the BMP multiplexer
  • Test implementation using OpenBMP and self-developed scalability tools

Proposed by: Daniel Kopp, Christoph Dietzel
Domain experts that can offer help: Saif Hasan
Interested Participants: Daniel Kopp, Christoph Dietzel

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

ANYCAST-1

Investigate anycast routing. Various interesting issues:

  • Understanding routing impact of adding/removing instances
  • CDNs do a lot of things to make their anycast work well --prepending, communities, selective advertising, regional anycast addresses. How should you decide how to configure your anycast?

Use PEERING to Influence how remote ASes reach your AS. Do informed AS path prepending, rather than tweak and pray :-). Use online feedback to selectively filter announcements to peers, etc.

Use BGPStream (e.g., pybgpstream or bgpreader) to observe changes. Option to coordinate with the challenge on live BGPlay to feed BGPlay, or with challenge [V2] or use other viz. Data plane measurements could generate time series that can be visualized in Charthouse.

  • Comment from Nicholas Wolff: It would also be interesting to investigate anycast from both perspectives of trying to influence the local network(ibgp) (such as on-network content caches/dns) and across peers/transit(ebgp)(for serving data out to the internet at large).For anycast to be properly investigated it needs correlated to services that are being anycast. (i.e. dns behaves differently then http).

  • Comment from Gavriil Chaviaras and Petros Gigis: Anycast is a critical aspect of the internet addressing methodology, therefore various changes in the announced AS paths impact the delay times of those involved. In this experiment, we will use the PEERING testbed to simulate a service using anycast in real-world, real-time conditions. The goal is to comprehend the routing impact of adding/removing instances from the announced paths using BGPStream, in order to reach a decision on the configuration parameters of the service's anycast

  • Comment from Wouter de Vries: Would also be nice to combine this with RIPE Atlas, to do large-scale measurements each time a new PEERING location is added.

  • Comment from Italo Cunha: I guess this is covered under "Understanding routing impact of adding/removing instances", but an interesting analysis would be to evaluate how many points you need to announce from to achieve a performance target, or predicting the impact of anycasting from extra locations.

Domain experts that can offer help: Ethan Katz-Bassett, Chiara Orsini, Fontas Dimitropoulos, Alexander Azimov
Interested Participants: Wouter de Vries (1), Ricardo Schmidt (1), Danilo Cicalese (1), Gavriil Chaviaras (1), Petros Gigis (1), Azzam Alsudais (1), Nick Wolff (1), Roya Ensafi (1), Dmitry Kohmanyuk (1), Nathan Owens (1), Andrew Mulhern (1), Mark Iversen (1)

#####Team 1:

  1. Ricardo Schmidt
  2. Wouter de Vries
  3. Azzam Alsudais
  4. Roya Ensafi
  5. Nick Wolff

FAILOVER-1

Motivation: ASes often connect to multiple providers for better resiliency and performance purposes, which is known as multi-homing. However, BGP backup connections are sometimes tested only when a real outage happens. This is problematic because without testing, potential misconfigurations cannot be promptly identified. As a result, when a BGP outage happens, the failover mechanism could also fail to work.

Goal: The goal of this project is to develop a methodology for testing BGP failover mechanisms on the real Internet. For this purpose, the project will collect and analyze real-time feedback from RouteViews and RIPE RIS about how the rest of the Internet is affected when the fail-over happens, i.e., (a) how fast does the Internet converge? (b) does the outage result in persistently unreachable networks? (c) what is the impact on the control plane vs. the data plane? Charthouse and BGPlay can be used to visualize how well or bad the failover mechanisms operate. In addition, a possible extension is to test the impact of failures in upstream (rather than directly connected) providers. This can be done by virtually “failing” an upstream AS using BGP path poisoning. In this case too, the effect of the virtual outage of an upstream provider can be measured and analyzed. Related work on LIFEGUARD and POIROOT is necessary background.

Tasks: This project will setup a virtual multi-homed AS using PEERING and then it will test the fail-over mechanisms of the virtual AS. It will use real-time feedback from RouteViews and RIPE RIS to see how the failure is perceived by the rest of the Internet. In addition, data-plane measurements, e.g. using Ark and RIPE Atlas, will be used to measure the effect of the outage on the data plane.

  • Comment from Thomas Holterbach @ ETHZ: This challenge is close to my current work, which consists in identifying and locating a failure between two ASes thanks to the BGP information (and in particular the BGP withdrawals) and quickly fast reroute the impacted traffic towards the backup route. LIFEGUARD and POIROOT are papers that I have studied. In addition, I am also familiar with the RIPE Atlas platform and tools as well as the BGP collectors provided by RIPE RIS and Route-Views. While my current work focuses on the BGP convergence time due to the FIB update time, I am also interested to know how the data plane is impacted when an AS changes its forwarding decisions. In this project, I could take care of the data plane measurements, for instance how to design a measurements campaign that is able to detect the impact on the data-plane when an AS changes its forwarding decisions (measurement platforms such as RIPE Atlas usually come with several limitations, such as the measurements frequency, and we would need to think about a method to accurately measure the impact on the data plane).

Comment from Italo Cunha: Another interesting question is which providers should one pick to minimize the impact of failures. This could be evaluated for different types of failures (e.g., at tier-1s, tier-2s, or direct providers) and also for different impact metrics such as number of disconnected networks or performance degradation.

Comment from Christoph Dietzel: Additionally to the upstream measurements I would like to answer such questions with respect to IXP outages.

Comment from Tianbo Gu: We can also add some other goals here. (a) BGP "failing" events can happen in Tier-1, T-ier2 or Tier-3 ISP. These failing event may trigger differenct influence on both control and data plane. We can measure such things when fail-over happens. (b) Analyze the failover process, and investigate if we have any methods to speed up the converge.

Proposed by: Fontas Dimitropoulos
Domain experts that can offer help: Ethan Katz-Bassett, Chiara Orsini, Fontas Dimitropoulos, Alexander Azimov
Interested Participants: Christoph Dietzel (1), Maite Gonzalez Mendoza (1), Caterina Munoz (1), Tianbo Gu (1), Bruno Machado (1), Azzam Alsudais (2), Thomas Holterbach (1), Alejandro Acosta (2)

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

BGPMON-1

Develop an OpenBMP connector to BGPMon’s cassandra database. BGPmon is comprised by a daemon client programs communicating over GRPc. The daemon is responsible for accepting messages with BGP data from various sources like MRT files, live BPGds (gobgp) sending their incoming messages to their RIBs and BMP daemons. Using our bgp parsing golang libraries we need to:

  • implement the configuration of a BMP streaming server communication between the gRPC daemon and client.
  • create the server BMP Session implementation of the interface with the respective Connect/Read/Writes
  • develop appropriate BMP schema annotations for the db backend in cql

Domain experts that can offer help: Spiros Thanasoulas, Christos Papadopoulos
Interested Participants: Andrew Mulhern (2)

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

BGPD-1

Add BMP support to BIRD and/or Quagga

Proposed by: John Kemp

Motivation: the IETF BMP protocol (https://tools.ietf.org/html/draft-ietf-grow-bmp-16) is now well defined, and is used in all Juniper routers, as well as the Cisco XE/XR routers, and Cisco XRv. This provides an out-of-band, well-defined data collection mechanism. The OpenBMP project provides tools for receiving and redistributing BMP collected data. However, while the BIRD (http://bird.network.cz/) and Quagga (http://www.nongnu.org/quagga/) software routers have methods for saving data in MRT, they do not yet support BMP. A BMP-sender capability would provide real-time (rather than file-based) output, and would integrate with the OpenBMP collection architecture.

Goal: Identify and implement the changes required for Quagga and/or BIRD to provide at least partial BMP protocol support.

Tasks:

  • Study the BMP protocol (https://tools.ietf.org/html/draft-ietf-grow-bmp-16)
  • Identify and prioritize the changes required to the Quagga and/or BIRD codebases to add BMP support.
  • Begin implementation of changes
  • Test implementation using existing (e.g., OpenBMP) tools

  • Comment from Brandon Schlinker: I think that it's unlikely that a team will be able to modify Quagga or BIRD fast enough in the two day period to make a good contribution towards this (just too much code to go through). However, I think they could potentially build a system that "listens in" on the BGP traffic with something like libpcap, tracks the state of various BGP peers, and then sends state and update messages via BMP. This would allow the project to be more self contained. Perhaps the largest challenge would be getting a full table to send via BMP (I think this is sometimes needed?), but perhaps this could be dumped from the routing engine (via vtysh or birdc for Quagga and BIRD respectively) and converted into BMP.

  • Comment from Tim Evens: It would be great to see BMP implemented in Quagga as well as BIRD. I believe more folks are using Quagga, so that might be more preferred. OpenBMP is pretty straight forward and only really needs the collector and Kafka. With that you can fully validate/test. The docker container installs for both of those make it super easy (minutes) to get it up and running (https://github.com/OpenBMP/docker) I can also upload two simple scripts I use for quickly parsing/validating a BMP binary/dump as well as recording and replaying the data. Another possibility/project that I think would be even more interesting and usable than updating Quagga/BIRD is to write a BMP client (router side) that uses only libpcap (or sockraw/similar) to monitor BGP TCP packets on a localhost that then conveys that information via BMP. An easy implementation can leverage a similar implementation that Cisco XE/XR are doing with update mirroring via RM messages. This would actually be easier than updating Quagga/BIRD because you wouldn't have to fight with their code base, nor would you be stuck with one language. You can, in theory at least, monitor the bi-directional TCP connections of BGP peering to generate a 100% compliant BMP feed. There's already a customer [of Cisco] that has this use-case requirement because of pmacct and bgp peering to it. There are some gotchas to having this style of a bmp client implementation... E.g. the pcap-bmp-app needs to maintain state just as if it was doing peering. Therefore, it needs to monitor/track keepalives along with the TCP session to determine if it's up or not. It also should not forward anything in BMP unless it has seen the full BGP state, specifically the open messages sent/received. The app should expose via cli/shell (local to the box at least) details about which BGP peers are seen, their state, and forwarding counters for BMP. The implementation does not have to maintain per afi/safi nlri state (tracking of withdraws/unreach) because it could easily use the same mirroring method mentioned earlier. This would be a great interim/bridge gap utility app for any software based peering server/router.

Domain experts that can offer help: John Kemp, Alistair King, Spiros Thanasoulas, Brandon Schlinker
Interested Participants: Abhishek Dwaraki (1), Priyanka Kedalagudde (1), Yi-Ching Chiu (1), Yasuhiro Ohara (1), Azzam Alsudais (3)

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

BGPD-2

Add MPLS support for BIRD / Quagga / gobgp MPLS is now supported in Linux kernel 4.1+. BIRD, Quagga, and gobgp do not currently support updating the kernel’s table based on VPN v4/v6 announcements that they receive from peers (thus, they cannot manipulate the data plane).

Domain experts that can offer help: John Kemp, Spiros Thanasoulas, Brandon Schlinker
Interested Participants: TBD

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

BGPD-3

Replay BGP updates from BGPStream / MRT / other formats into BGP daemons

  • Comment from Brandon Schlinker: we'd like to be able to play BGP updates into Quagga, BIRD, and other routing engines. In addition, I think this is a good case for using ExaBGP, although I'll admit that I'm a little concerned about Python's ability to keep up with playback of updates at an IXP route server or something similar. One option may be to run multiple ExaBGP instances, each handling playback from a small set of peers, thus allowing parallelization.

Domain experts that can offer help: John Kemp, Spiros Thanasoulas, Brandon Schlinker, Alistair King
Interested Participants: Alejandro Acosta (1)

#####Team 1:

  1. Alejandro Acosta
  2. Luca Sani
  3. -open-
  4. -open-
  5. -open-

ASRANK-1

Make ASRank updated automatically continuously (e.g., per day).

Proposed by: Matthew Luckie

Background: CAIDA’s AS-rank system is a public-facing website that reports inferences using topology data, including relationships between ASes and a ranking of networks by AS customer cone. The inferences are made using CAIDA’s AS-relationship inference algorithm using public BGP data. However, the website is updated only sporadically as the back-end is not automated. Further, there are many useful operator-focused extensions that could be made to AS-rank utilizing the same sources of data.

Motivation: The AS-rank system is not as useful as it could be, because the data quickly becomes stale. Further, the potential of AS-rank as part of an operator’s toolkit is not yet met.

Goals: Automate the AS-rank system from raw data retrieval, to AS relationship inferences, to cleaning and sanitizing data, to building useful features, such as the prefix customer cone (i.e. what prefixes you can expect to receive over a peering session from an AS.

Tasks:

  • update the AS-rank system to be automatically populated with fresh data, at least once a month but could be once per day.
  • add a “prefix customer cone” feature that allows an operator to obtain a list of address space that they could expect from a neighbor over a peering session.
  • create a queryable interface to the raw data.

  • Comment from Maite González Mendoza: It could be interesting to visualize the data that is shown in the CAIDA AS-rank, and sort them maybe by registered country or by geolocation

  • Comment from Italo Cunha: I wonder whether it makes sense to make data sets that go into computing ASRANK available in a streaming interface (like BGPstream).

  • Comment from Francisco Montoto: Looks like a REST API for querying the data could add value to the data consumers

Domain experts that can offer help: Matthew Luckie, Brad Huffaker, Amogh Dhamdhere, Alexander Azimov
Interested Participants: Alexander Isavnin (1), Roderick Fanou (1), Victor Sanchez (1), Maite Gonzalez Mendoza (2), Caterina Munoz (2), Yi-Ching Chiu (2), Dmitry Kohmanyuk (2), Nathan Owens (2), Yasuhiro Ohara (2), Andrew Mulhern (3)

#####Team 1:

  1. Caterina Munoz
  2. Roderick Fanou
  3. Victor Sanchez
  4. -open-
  5. -open-
  6. Non competing Expert: Matthew Luckie
  7. Non competing Expert: Amogh Dhamdhere

LINKRANK-1

Develop your own Link-Rank algorithm

Background: ASPATHs can be viewed as lists of nodes in a graph: each AS is a node in the graph, whereas ASPATH adjacencies represent links between nodes. Each link can be associated with a weight that is representative of how many AS paths traverse such link. One method for calculating a link “rank” could be weighted standard deviation over a chosen time period of the previous weight, however it would be important to have a metric/weight which is independent of the number of collectors up at a given time.

Motivation: Route-leaks and route-hijacks are often detected utilizing ASPATH change detection. When one of these events happens, new links may appear (e.g. backup links that are now visible because of a different outcome of the BGP decision process), or the preferred routes may start using links that were rather unused before. A Link-Rank algorithm can be used to do baseline leak/hijack detection.

Goals: develop your own per-AS Link-Rank algorithm. Use this algorithm on a test-case to process data of a known route-leak time period. Experiment with different time periods to determine best performance.

Tasks:

  • define a link weight that takes into account visibility changes
  • run this algorithm on a test case (e.g. Malaysia Telekom leak)

  • Comment from Gavriil Chaviaras and Petros Gigis: Possible Tasks: -Graph representation using a graph framework (e.g. Gephi, GraphStream, JgraphT, NetworkX). -Develop the ASLINK weight algorithm using standard deviation over a chosen time period. -Acquire data from Malaysia Telekom leak for test case environment initialization.

  • Quentin Jacquemart: I have been thinking about this for quite a while but never managed to come up with a metric that would be satisfactory. I would be interested in discussing with other participants in a way of defining a metric that is stable and can be used to detect route deviations and or hijacks.

  • Comment from Brendon Jones: Curious about the difference in appearance between backup links coming up due to failover and hijacked links.

  • Comment from Pierre-Antoine Vervier: Provide maybe some pointers on link ranking to start with (e.g., [1,2]) [1] C. Kruegel, D. Mutz, W. Robertson, and F. Valeur. Topology-Based Detection of Anomalous BGP Messages. In RAID, pages 17--35, 2003. [2] J. Qiu and L. Gao. Detecting Bogus BGP Route Information: Going Beyond Prefix Hijacking. In SecureComm, pages 381--390. IEEE, 2007.

  • Comment from Italo Cunha: Might be worth considering traffic attraction in the challenge.

Domain experts that can offer help: Chiara Orsini, Fontas Dimitropoulos, Ethan Katz-Bassett, Emile Aben, Alexander Azimov
Interested Participants: Daniel Kopp (1), Vasco Asturiano (1), Pierre-Antoine Vervier (1), Rachee Singh (1), Mingwei Zhang (1), Alexander Isavnin (2), Abhishek Dwaraki (2), Priyanka Kedalagudde (2), Roderick Fanou (2), Victor Sanchez (2), Yasuhiro Ohara (3)

#####Team 1:

  1. Yasuhiro Ohara
  2. Daniel Kopp
  3. Priyanka Kedalagudde
  4. Tianbo Gu
  5. Abhishek Dwaraki
  6. Alexander Isavnin

DATAPLANE-1

Correlating data plane and control plane path changes

Motivation: Data plane path measurements such as traceroutes provide fine-grained (IP-level) paths, but they cannot be refreshed frequently, especially for very diverse platforms like RIPE Atlas, so they go stale before they can be refreshed. Control plane measurements stay fresh--you see every update--but they are at AS granularity. Can we combine to get the best of both worlds?

Background: It is already known that a BGP path change along a path suggests that overlapping traceroutes may be stale.

  • Most BGP paths see periods of high churn in between long stable periods.
    • Most BGP announcements are short-lived.
    • Most S,D pairs have a dominant path most of the time.

Goal: Can we extend the usefulness of our traceroutes by:

  • Caching what the (relevant) BGP state was when a particular traceroute was issued
  • Marking the traceroute as stale when the BGP state changes
  • Restoring the traceroute as valid when the BGP state restores
  • Updated databases on IP and AS metadata:
    • IP-to-AS mapping
    • IXP prefixes and IXP AS numbers
    • Lists of sibling ASes

Project goal is to use BGPStream and existing sets of traceroutes to validate this idea

  • Comment from Thomas Holterbach: As a possible task, I could try to quantify the correlation between control-plane updates and data-plane changes. For instance, if the AS path has changed for a prefix P on X% of the BGP collectors, then there is Y% of chance that the traceroute results towards this prefix change as well. A correlation index between a BGP controller and a traceroute measurement could also be defined, based on the intersection between the AS path seen by the collector and the AS path of the traceroute for a particular prefix. If such a correlation is indeed possible, there may be several applications. In addition to the marking valid/stale mentioned in the description of the project, perhaps RIPE Atlas could implement a new way to perform traceroutes, something like "perform a traceroute towards a destination every day or when a change in the control-plane for the targeted prefix has been detected".

  • Comment from Brendon Jones: Could also see it being useful to present all traceroutes recorded with the same BGP state, so if a traceroute hasn't been performed recently then you get a set of possible paths (e.g. through load balancers) rather than the most recent one that matched the BGP state.

  • Comment from Wouter de Vries: Nice idea, although we will not be able to find all changes to the route using the control plane (for example, because of changes inside an AS). It would be cool to see how much of the changes that happen we can "predict" using the control plane data and how much we can not. My suggestion would be that we look at all the data plane data, and see for which changes we can find a corresponding BGP update. That way we will have a clear idea of how effective this would be in determining whether a traceroute is still valid.

  • Comment from Italo Cunha: This challenge applies directly to one project I collaborate on with Ethan Katz-Bassett where we need to maintain an up-to-date atlas of Internet paths. Tracking staleness by correlating changes (passively) observed on BGP and changes on the data plane will help us save (active) traceroute measurements when maintaining the atlas up-to-date.

  • Comment from Christoph Dietzel: Somehow related we look into combining flow information with the route server IXP view for potential future investigations at DE-CIX.

  • Comment from Adriano Faggiani: automate extraction of IXP info from peeringDB, AS path inference from traceroute

  • Rahul Hiran: I have already tried to accomplish such a task in my research paper "PrefiSec: A Distributed Alliance Framework for Collaborative BGP Monitoring and Prefix-based Security".

Domain experts that can offer help: Ethan Katz-Bassett, Italo Cunha, Matthew Luckie, Young Hyun, Emile Aben, Alexander Azimov
Interested Participants: Reza Motamedi (1), Wouter de Vries (2), Christoph Dietzel (2), M. Jonker (1), Andrew Weiner (1), Pierre-Antoine Vervier (2), Rachee Singh (2), Thomas Holterbach (2), Mark Iversen (2), Adriano Faggiani (1), Roderick Fanou (3), Victor Sanchez (3)

#####Team 1:

  1. Thomas Holterbach
  2. Rachee Singh
  3. Yi-Ching Chiu
  4. Christoph Dietzel
  5. Reza Motamedi

BGPSTREAM-1

Match filters for the BGPStream framework.

Motivation: Live data is generally a complete data stream from a set of collectors and/or peers. Researchers and analysts are however often interested in selecting specific messages based on a set of matching criteria, for example, by prefix, or origin ASN.

Background: The current BGPStream filter mechanism is limited to only time, project, collector, and record-type. Users will naturally want to do filtering at a higher level, for example, by prefix, or origin ASN.

Goal: Propose and/or begin to develop a filtering component that will integrate with the existing BGPStream library and allow users to easily filter data based on various attributes.

Tasks:

  • Study the BGPStream source code
  • Design a filtering component that will integrate with the existing BGPStream library. It should should support both “client-side” filtering (i.e. filtering of records within the BGPStream library), as well as handing off filters for “provider-side” filtering (i.e. filtering of records by the provider). Include in this library the ability to match on the most common BGP message attributes:
    • Match Prefix
    • Match Originating ASN
    • Match Update Type: Update/Withdrawal
    • Match ASPath Regexp
    • Match More specific Prefix
    • Match Less specific Prefix
    • Match Community Regexp
    • Match Extended Community Regexp
  • Begin implementation of the filter component.

  • Caterina Munoz: I have some experience on streaming and real time filtering, so I would like to work as a developer in this project.

  • Francisco Montoto: SQL-Stream processors might be a nice add to the stream pipeline, so users can easily query the data using a known language

Domain experts that can offer help: Alistair King, Chiara Orsini
Interested Participants: Caterina Munoz (3)

#####Team 1:

  1. Shane Alcock
  2. -open-
  3. -open-
  4. -open-
  5. -open-

TRANSIT-1

Application-specific Transit over BGP

Motivation: ISPs may provide different Service Level Agreements (SLAs) to their customers, associated with latency, bandwidth, and other properties. Customer networks could use different providers (with different SLAs) for different application traffic. For example, they could send mission critical traffic of tele-presence services over a transit AS with a low latency SLA; or they could send bulk backup traffic to a cloud provider over an AS with SLAs optimised for bandwidth rather than latency. This type of application-specific transit can presently happen only at the level of large IP address prefixes, but not at the level of individual flows, which would be the desired granularity.

Goal: The goal of this project is to prototype an application-specific transit service over BGP. The key idea is to use a NAT between the customer AS and its providers, which will remap different classes of flows to different IP prefix blocks, which will be announced to the providers. Different blocks will be announced to different providers and therefore can be subject to different SLAs. Furthermore, the NAT enables applications in the customer network to reside in any prefix block, regardless of the BGP announcements. This way even different flows from the same system (behind a single IP address) could be served by different transit providers under different SLAs.

Tasks: This service will be prototyped on top of the PEERING testbed.

  • Comment from Brandon Schlinker: I'm a little concerned that this project is too similar to existing work in this area, although that doesn't mean that it would not be a good project. The following paper covers a similar system: Peng Sun, Laurent Vanbever, and Jennifer Rexford, "Scalable programmable inbound traffic engineering," short paper, in Symposium on SDN Research, June 2015.

  • Comment from Abhishek Dwaraki: This could definitely prove to be more interesting on an SDN network that can do BGP peering.

Proposed by: Fontas Dimitropoulos, Pavlos Sermpezis
Domain experts that can offer help: Ethan Katz-Bassett, Brandon Schlinker, Alistair King, Fontas Dimitropoulos
Interested Participants: Reza Motamedi (2), Abhishek Dwaraki (3), Tianbo Gu (2), Priyanka Kedalagudde (3)

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

HIJACKS-1

Reaction to hijacks by announcing longer prefix and measure reaction both on data and control plane

Background: a fast and effective countermeasure against a prefix hijack consists in announcing the same space de-aggregated (e.g. a /23 as two separate /24s)

Goal: understand how effective and fast is the de-aggregation of the prefix space as a reaction to a possible hijack attack.

Tasks:

  • detect the hijack of a prefix
  • split the prefix into sub-prefixes
  • announce the new sub-prefixes
  • monitor the convergence times in bgp
  • monitor with a continuous traceroute the path towards the announced prefixes

  • Comment from Gavriil Chaviaras and Petros Gigis: Possible Tasks: Creation of a web tool which will allow user to monitor IPv4 and IPv6 prefixes and warn him if a prefix is hijacked. Tool based on trace routes and continuous monitoring of BGP updates from sources like the routeviews project and the BGP stream. Examine the proposed strategy to deal with the hijack attempt (split the prefix into sub-prefixes and announce new sub-prefixes) and monitor the convergence times in BGP.

  • Comment from Wouter de Vries: Again, this is a challenge that can make use of the data plane measurement frameworks that are available (Ark, RIPE Atlas). This solution would probably not work well in the case that a hijacker is already announcing the smallest possible prefix (/24). One idea that came to mind when facing a /24 hijack, is that it might be possible, depending on operational filters I imagine, to start announcing that /24 from a lot of other locations. For example using PEERING (basically, re-hijacking/anycasting it). And then rerouting the incoming data back to the original host(s).

  • Comment from Italo Cunha: It would be interesting to consider the number of more specific prefixes that need to be announced. Announcing more prefixes may require human intervention (e.g., prefix limits at IXPs) or overload routers. It could also be interesting to evaluate how far very specific prefixes (e.g., /25s or /26s) propagate in the Internet. (Are there defenses against /24 hijacks?)

  • Comment from Cristoph Dietzel: Additionally to the proposed task I would like to look into historic data to see if this technique was effectively used already. And trying to quantify it.

  • Comment from Mattijs Jonker: Perhaps it is also worthwhile to consider the performance implications of de-aggregation, such as the effect on the IP routing table size.

  • Comment from Andrew Weiner: I believe there is significant overlap between this challenge and RPKI-1.

  • Comment from Quentin Jacquemart: I think the scope of HIJACK-1 challenge is limited by the observations detailed in Randy Bush's Internet Optometry paper.

  • Comment from Roya Ensafi: One of my current research projects has been on measuring the effects of countries's network interference policies on transit traffic. I would like to be able to quickly measure BGP hijacks and measure how fast the de-aggregation of the prefix space as a reaction to a possible hijack attack is. The answers to these questions can help with quantifying how vulnerable the transit traffic is when crossing different countries.

  • Comment from Nicolas Vivet: Once BGP hijacks are detected in real time (see HIJACKS-2), it might be possible to filter events on interesting prefixes and/or ASNs and announce, as a result, more specific prefixes, for example, using ExaBGP. However, this solution is potentially limited if the hijacker already announces one or more /24. It might also be possible to make use of probes from RIPE Atlas to measure where the traffic is going by issuing traceroutes to the hijacked prefix. These feature could be developed during the hackathon.

Domain experts that can offer help: Ethan Katz-Bassett, Brandon Schlinker, Chiara Orsini, Alberto Dainotti, Alexander Azimov
Interested Participants: Nicolas Vivet (1), Mingwei Zhang (2), Danilo Cicalese (2), M. Jonker (2), Andrew Weiner (2), Bruno Machado (2), Roya Ensafi (2), Gavriil Chaviaras (2), Petros Gigis (2), Wouter de Vries (3), Christoph Dietzel (3), Yi-Ching Chiu (3), Alejandro Acosta (1)

#####Team 1:

  1. Gigis Petros
  2. Gavriil Chaviaras
  3. Andrew Weiner
  4. Mingwei Zhang
  5. -open-

HIJACKS-2

Automated detection of BGP anomalies (e.g., hijacking events)

  • Comment from Ruwaifa Anwar: Extending BGPstream to detect hijacks and interception in real time. For prototyping, we can induce bgp hijacks using Peering platform and try detecting it using BGPstream extensions and traceroutes

  • Comment from Quentin Jacquemart: HIJACK-2 is very abstract and undefined and needs to be narrowed down.

  • Comment from Adriano Faggiani: Interested in route flap detection, categorizing BGP hijacks

  • Comment from Valerio Luconi: Interested in using active measurements to help classify BGP anomalies.

  • Comment from Kaname Nishizuka: Finding a way to detect hijacking events with the (faked) same origin and to distinguish between malicious hijacking and anti-DDoS bgp announcement.

  • Comment from Nicolas Vivet: Detecting BGP hijacks requires to be able to analyse BGP updates from a large number of BGP peers. I believe that it is possible to do this detection in near real time using inputs from RIPE RIS and BGPstream in order to take further actions (alerting, announcing more specific prefixes, ...). On the other hand, not all conflicting BGP announces are BGP hijacks because some are legitimate (e.g. prolexic can announce the prefix of its consumer without this event being an hijack). This can be dealt with using external data such as route objects and RPKI (but not only) to classify the events. As part of the hackathon, I plan to develop an open source tool which is able to detect BGP conflicts from BGPstream and classify it as an hijack using RIPEstat. Additionally, these feature could be developed by other team members: -plugins to trigger actions such as discussed in HIJACKS-1 (make more specific announcements, launch traceroutes). -interface to visualize current BGP hijacks -Twitter/email connector to send alerts when an hijack is happening

Domain experts that can offer help: Alberto Dainotti, Chiara Orsini, Alistair King, Ethan Katz-Bassett, Spiros Thanasoulas, Christos Papadopoulos, Alexander Azimov
Interested Participants: Ruwaifa Anwar (1), Calvin Ardi (1), kaname nishizuka (1), Adriano Faggiani (2), Daniel Kopp (2), Vasco Asturiano (2), Emile Aben (2), Nicolas Vivet (2), Alexander Isavnin (3), Danilo Cicalese (3), Pierre-Antoine Vervier (3), Mark Iversen (3)

#####Team 1:

  1. Ruwaifa Anwar
  2. Danilo Cicalese
  3. Nicolas Vivet
  4. Kaname Nishizuka
  5. Danilo Giordano
  6. Charles Brock
  7. Bruno Machado

OUTAGES-1

Automated detection of BGP outages.

using BGPmon: Correlate BGP data stored in the BGPmon keyspaces with our sources of data in the DB (ping sweeps? traceroutes? more?) to detect the outage. to accomplish:

  • propose an initial schema for the other dataset
  • implement a client program to the db cluster that populates the keyspace
  • either through plain CQL or via using spark write a correlating detector function.we can run that periodically or via signaling the daemon.

Domain experts that can offer help: Spiros Thanasoulas, Christos Papadopoulos, Alexander Azimov
Interested Participants: Calvin Ardi (2), Roya Ensafi (3), Daniel Kopp (3)

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

OPENCONFIG-1

OpenConfig support for Quagga / BIRD / gobgp

Proposed by: Anees Shaikh (Google/OpenConfig working group)

Motivation: Despite being a fundamental standard protocol of the global Internet, BGP still requires platform-dependent configuration and management. This means users who wish to leverage multiple implementations must develop a significant amount of proprietary integration to speak the dialect of each BGP speaker’s management language.

Background: The OpenConfig operator working group is an industry collaboration among network operators to define vendor-neutral data models for configuration and operational state for networking based on operator usage (see www.openconfig.net). Native support for OpenConfig BGP and routing policy models is now being developed on major commercial platforms including Juniper JUNOS, Cisco IOS-XR, and Arista EOS.

Goal: Develop a management interface for open source BGP speakers that supports the OpenConfig data models

  • review the YANG data models for BGP and policy from OpenConfig
  • develop a mapping of supported features (data elements) from the OpenConfig model to the OSS BGP interface (including those features that are not present)
  • Implement a programmatic API that accepts OpenConfig-based configuration data (e.g., in XML, JSON, etc.) and translates it into corresponding native commands for the software speaker. The protocol for accepting configuration commands could be NETCONF/RESTCONF, gRPC, or another suitable transport.
  • Comment from Rob Shakir: I am one of the primary authors of the BGP YANG models that are mentioned in this proposal - and have implemented open source mappings from YANG models to Python classes, including serialising and deserialising input documents. I'm happy to help out with coding this in other languages as part of this challenge. I think it would help to relatively tightly scope which config is best to dynamically change in this way (I'd suggest neighbors and peer groups being added), and choose one of the daemons to work on, prior to the dates - such that some knowledge of the internal config structure can be built.

Domain experts that can offer help: Anees Shaikh, Ethan Katz-Bassett, Chiara Orsini, Alistair King
Interested Participants: Rob Shakir (1)

Accomplished: Completed a prototype to extract data from Quagga BGPd and present in OpenConfig structure and format. Tested with several actual network BGP configurations. Future steps: extend to be able to set configuration values using OpenConfig.

#####Team 1:

  1. Theo Zourzouvillys
  2. Rob Shakir
  3. Mattijs Jonker
  4. -open-
  5. -open-
  6. Non competing Expert: Anees Shaikh
  7. Non competing Expert: Josh George

OPENCONFIG-2

OpenConfig-based normalization of configuration and monitoring for research/measurement testbeds (PEERING, BGPStream, BGPMon, RouteViews, RIPE RIS)

Proposed by: Anees Shaikh (Google/OpenConfig working group)

Motivation: Experimenters using BGP measurement infrastructure or data sources must configure these testbeds using a variety of platform-specific commands, and similarly handle data (e.g., RIB data, BGP protocol statistics) delivered in different formats. These per-testbed integrations result in additional effort unrelated to the core experiment goals.

Background: The OpenConfig BGP and RIB data models define a common, vendor-neutral interface for configuring and monitoring BGP, including protocol and policy. These models can be used to normalize the management and data access interfaces to a variety of BGP measurement testbeds to simplify users’ ability to leverage multiple testbeds or data sources.

Goal: Provide an OpenConfig-based interface to multiple measurement testbeds for configuring BGP behavior (e.g., in PEERING) and to deliver BGP RIB data (e.g., across BGPMon, RouteViews, BGPStream).

  • Review the YANG data models for BGP protocol, RIB, and routing policy from OpenConfig
  • Develop a proxy or library that maps OpenConfig-based configuration and monitoring data to and from BGP measurement data sources or measurement testbeds.

  • Comment from Rob Shakir: As per the previous challenge, I am one of the primary authors of the BGP YANG models mentioned in the proposal, and reviewed the RIB model relatively extensively. It would also be possible to build something based on the pyangbind open source I maintain to complete this challenge. Again, I think that scoping what parts of the RIB information are to be collected would be useful here.

  • Comment from Italo Cunha: It seems to me this challenge is more about design; if so, I could contribute in the discussion of adding support for configuring PEERING, and hosted experiments, using OpenConfig.

Domain experts that can offer help: Anees Shaikh, Ethan Katz-Bassett, Chiara Orsini, Alistair King
Interested Participants: Shane Alcock (1), Rob Shakir (2)

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

OPENCONFIG-3

A framework for operational route verification

Proposed by: Anees Shaikh (Google/OpenConfig working group)

Motivation: A primary concern for any Internet-scale network operator is how to ensure that routes originated and received behave as expected (e.g., propagation, filtering) and have properties that comply with those intended. Currently this requires ad-hoc analyses and infrastructure to collect traces and perform various checks. A common framework for expressing predicates on routes that would automatically perform checks on specified routes would simplify the problem of route verification.

Background: BGP data sources provide a diverse view of routes across the Internet. These testbeds can be collectively leveraged to look for specific routes in designated locations to ensure that desired behavior and properties are observed.

Goal:

  • Develop a simple language to express validation predicates on routes, such as specific attribute values, presence of specific community strings, or simply observation that a route appears in a specified RIB. The language should provide a way to indicate where (e.g., geographic region, a particular router, etc.) predicates should be checked for compliance
  • Implement a system that checks route predicates based on RIB or UPDATE information from the specified locations -, providing a notification when violations are observed

Platform dependencies: could be useful to use LUA interpreter (for the validation language) embedded into a bgpcorsaro plugin, or simply a pybgpstream script.

  • Comment from Rob Shakir: Whilst there is less dependence on the YANG models here - I'd expect that a useful interim format that an operator may want to express their requirements against would be the OpenConfig RIB model.

  • Comment from Mattijs Jonker: I am not sure if this approach is overkill since I have not done this type of work in recent years, but I think ANTLR can be used for the language part of the proposed framework. If we specify the simple language to express validation predicates on routes, ANTLR could generate a lexer, parser, context analyzer and part of the route predicate checker. We can then check predicates in our own code (e.g., C, Python or Java).

  • Comment from Tianbo Gu: Goal: we could develop a general interface to open source BGP speaking routers. Then developer can dynamically transmit the BGP updates, BGP policy info to the BGP speaking routers, and get routing computation results from the routers.

Domain experts that can offer help: Anees Shaikh, Ethan Katz-Bassett, Chiara Orsini, Alistair King
Interested Participants: M. Jonker (3), Rachee Singh (3), Tianbo Gu (3), Rob Shakir (3)

Mattijs got familiar with PyBGPStream and worked on mapping BGP RIBS to OpenConfig's Yang model for RIBS (openconfig-rib-bgp). Future steps: Develop a simple language to express validation predicates etc. as explained in the Goals section.

#####Team 1:

  1. Mattijs Jonker
  2. -open-
  3. -open-
  4. -open-
  5. -open-

VIZ-1

Visualization of traceroutes/AS graphs with configurable filters and aggregations

It would be useful to be able to display variables related to performance.

  • Comment from Brendon Jones: Interested to see what approaches we can take to displaying large graphs (while keeping information!) without them becoming too overwhelming.

  • Comment from Maite González Mendoza: It might be good to show metrics on the edges and nodes of the graph, like betweenness or other metrics. I would suggest that the development of this visualization were using D3 or visJS libraries.

  • Comment from Francesco Benedetto: It could be fun doing something related to streaming, using for example the streams provided by Ripe Atlas trough websocket joined with BGPStream and visualize real time (or near) phenomena using streamed graph drawing algorithms.

Proposed by: Ethan Katz-Bassett and CAIDA Domain experts that can offer help: Brad Huffaker, Young Hyun, Matthew Luckie, Ethan Katz-Bassett, Saif Hasan Interested Participants: Massimo Candela (1), Francesco Benedetto (1), Shane Alcock (2), Reza Motamedi (3), Maite Gonzalez Mendoza (3), Vasco Asturiano (3), Dmitry Kohmanyuk (3)

#####Team 1:

  1. -open-
  2. -open-
  3. -open-
  4. -open-
  5. -open-

VIZ-2

Live BGPlay service with input provided by BGPStream.
Proposed by: Massimo Candela Candela

Motivation: Operators and researchers are interested in visualizing changes in the AS topology when doing post-event analysis. Currently RIPE Stat makes available a BGPlay [https://stat.ripe.net/widget/bgplay] instance for visualizing historical BGP data, but they do not yet support visualizing live data, nor will they support RouteViews data.

Background: The BGPlay client has been recently upgraded to support live visualization of BGP data, and a proof-of-concept integration with BGPStream has been developed [a link will soon be available].

Goal: Develop a working prototype of a service that provides live data to BGPlay using BGPStream.

Tasks:

  • Implementing a BGPView consumer that maintains a copy of the most recent “RIB” in a redis (or similar) database. This database must support efficient queries by prefix and it should also support queries by origin ASN. (a proof-of-concept consumer that dumps to ASCII a hard-coded subset of the “RIB” will be available)
  • Implement WebSocket server that supports the BGPlay protocol and can retrieve relevant RIB entries (based on the prefixes/ASNs selected by the user) from redis as well as streaming updates directly from BGPStream. (a proof-of-concept version of this server that supports a hard-coded set of pfxes will be available) Note: It would be nice if this server did not need to have one BGPStream instance for each client since prefix-level filtering is done client-side. I.e. read the full stream once, and route updates to the appropriate clients.

Domain experts that can offer help: Massimo Candela, Alistair King
Interested Participants: Massimo Candela (2), Randy Bush (2), Francesco Benedetto (2), Nick Wolff (2), Shane Alcock (3), Mingwei Zhang ( 3.

#####Team 1:

  1. Massimo Candela
  2. Maite Gonzalez
  3. Saif Hasan
  4. Francesco Benedetto

VIZ-3

Interactive Internet Map

Proposed by: Vasco Asturiano

Goal: Build a graph of the Internet topology with interactive map-like navigation functionality.

Using AS adjacencies, represent a global graph of the Internet topology, analogous to AS Core, but combined with generic mapping interactive capabilities, enabling navigation and drill-down functionality by means of zooming/panning, searching and filtering. Searching for a particular AS can drop you right into a network neighbourhood allowing a seamless transaction between the macro and micro view. Potential more advanced features can include f.e. highlighting shortest paths between any two arbitrary nodes and enabling a temporal dimension by animating topology changes over time.

Obvious challenges here include the sheer volume of BGP data to handle, of which clustering and filtering should play important roles to allow a performant system.

Tasks:

The system should consist of a REST API and a user-facing web application leveraging browser interactive capabilities using D3, etc.

  • Process and convert BGP dump/snapshot data into an AS adjacency node-link data structure (or reuse existing data from AS-Core?)
  • Collect AS-Rank and Geolocation (longitude) meta information for the involved ASes
  • Define and implement the API composition, including functionality for node aggregation and filtering
  • Develop visualization interface featuring a polar projection layout and interactive navigation controls

Domain experts that can offer help: Saif Hasan

#####Team 1:

  1. Vasco Asturiano
  2. Pierre-Antoine Vervier
  3. -open-
  4. -open-
  5. -open-
  6. Non competing Expert: Bradley Huffaker

PEERING-1

Motivation: The PEERING BGP testbed enables a new style of routing research: the testbed peers with real networks at locations around the world to exchange routes and traffic, and researchers can grab a slice of the testbed to run experiments. Instead of passive observation of existing routes (which eliminates "what if" experiments) or modeling the network (which limits the realism because we cannot accurately capture all aspects of the Internet), experiments participate in the BGP ecosystem.

While PEERING has been useful in a range of research projects, over time, it has hit two major hurdles: (a) Deploying an experiment requires configuration and handholding from PEERING operators, creating a barrier to entry. (b) As the testbed expands to more locations and more peers, the existing approach to operating it has produced substantial operational burden, leading to site downtime and other problems.

In this project, we will redesign the PEERING infrastructure to scale better to support more researchers, richer experiments, and more sites. This work will include new approaches to:

  • The router software at sites
  • The "client" software that experiments run to connect to PEERING
  • The centralized component of PEERING that allocates resources to experiments, tracks experiments, and monitors sites

Tasks:

Proposed by: Brandon Schlinker
Contacts: [email protected]

#####Team 1:

  1. Non competing Expert: Brandon Schlinker
  2. Non competing Expert: Italo Cunha

PEBBLEWATCH-1 (sideproject)

Motivation Create a monitoring widget for the pebble watch to allow it to display possible prefix hijacks, AS-path detours or BGP link states.

Background The pebble watch is running a variant of the FreeRTOS kernel named PebbleOS. It can communicate with smartphones or nearby computers over bluetooth, and display information provided by them, or fetched directly from the web (?)

Tasks

  1. Investigate the possibility of either using pebble.js or a custom app on a smartphone to fetch live data either from the BGPMon web interface or from other sources.
  2. For the bgpmon source case, if needed create a custom web API for the watch that only provides back the relevant info that it can display

Proposed by: Randy Bush
Interested Participants: Spiros Thanasoulas, Daniel Rammer
Contacts: [email protected]