SIGCOMM 2016 BEST PAPER AWARD-1
Authors:
Ryan Beckett -- Princeton University
Ratul Mahajan -- Microsoft Research
Todd Millstein -- University of California at Los Angeles
Jitendra Phaye -- Microsoft
David Walker -- Princeton University
Presenter : Ryan Beckett
Quite in accordance with the other talks in the session, network configurations are postulated to be hard and error prone. A graph of the breakup of various causes of network issues are presented where it is shown that 60% are the result of human error. Small BGP misconfigurations also result in outages (references to the Pakistan YouTube incident).
Misconfigurations are so prevalent due to the tradeoffs that we make between distributed configs and distributed control plane mechanisms. Ryan presents a quadrant-based demarcation of the various pros and cons that different approaches bring, talking specifically about distributed configurations and distributed control plane mechanisms.
Propane tries to bring out the best of both worlds in terms of the advantages offered by legacy networks and SDNs. Can you write a centralized routing policy for your network, but then compile it down to a distributed implementation that runs BGP? It takes in network topology and outputs a BGP config for every n/w device on that network.
Propane consists of two parts, a high level language that talks about preferences, focusing on fail-over scenarios and also has uniform abstractions for intra and inter domain routing. The second part is a compiler that takes the centralized policy and generates BGP configs with policy compliance.
Ryan then illustrates this using an example of how configuration can be tricky if done manually and when performed using Propane. The high levels goals are outlined with respect to local and global prefixes and aggregations and policies.
Doing the same thing is Propane takes a few lines of definitions (constraints on the routes that traffic can take and prefixes that are being advertised). The Propane compiler takes care of translating this into distributed BGP configurations.
A further example of a simple compilation of eBGP is shown and how FSMs are utilized to translate the network configs into BGP configs.
Evaluation is performed on configs from a large cloud provider and are verified against the same policies in english. Policies include both DCN and backbone ones. DCN policies take 31 lines of Propane code and the backbone one takes 43 lines (quite minimal). Evaluation is performed on an 8 core, 3.6 GHz Xeon processor. It takes about 10s per prefix per equivalence class for the DCN policies (< 9 mins in total) and around 45s per prefix per equivalence class (< 3 mins in total) for the backbone policies.
It is postulated that constructing the product graph takes the most amount of time. Finally, it is summarized that using Propane could substantially reduce the probability of errors in misconfigurations while keeping the code to a minimum.
Q : BGP papers have been coming out for about 17 years now. Does this one solve everything?
A : This solves a lot, but there are still open issues. Some problems just cannot be compiled with Propane and it does not deal with security issues such as prefix/route hijacking.
Q : ARCs and Propane approach the issue from opposing ends of the spectrum. One takes the network topology and builds representations from it, the other takes representations and builds configs. Is there a way to combine both?
A : ARCs cannot use arbitrary local preferences and Propane does not use edge weights. There may be a way to work both together, but will have to be looked into as future work.
Q : I did not see a place where BGP configurators can tweak the settings. Is it allowed?
A : Tweaking is definitely allowed using pass through parameters. But we see Propane being used as part of another system that allows more tweaking and Propane then generates the configs.
Presenter : Ryan Beckett
Quite in accordance with the other talks in the session, network configurations are postulated to be hard and error prone. A graph of the breakup of various causes of network issues are presented where it is shown that 60% are the result of human error. Small BGP misconfigurations also result in outages (references to the Pakistan YouTube incident).
Misconfigurations are so prevalent due to the tradeoffs that we make between distributed configs and distributed control plane mechanisms. Ryan presents a quadrant-based demarcation of the various pros and cons that different approaches bring, talking specifically about distributed configurations and distributed control plane mechanisms.
Propane tries to bring out the best of both worlds in terms of the advantages offered by legacy networks and SDNs. Can you write a centralized routing policy for your network, but then compile it down to a distributed implementation that runs BGP? It takes in network topology and outputs a BGP config for every n/w device on that network.
Propane consists of two parts, a high level language that talks about preferences, focusing on fail-over scenarios and also has uniform abstractions for intra and inter domain routing. The second part is a compiler that takes the centralized policy and generates BGP configs with policy compliance.
Ryan then illustrates this using an example of how configuration can be tricky if done manually and when performed using Propane. The high levels goals are outlined with respect to local and global prefixes and aggregations and policies.
Doing the same thing is Propane takes a few lines of definitions (constraints on the routes that traffic can take and prefixes that are being advertised). The Propane compiler takes care of translating this into distributed BGP configurations.
A further example of a simple compilation of eBGP is shown and how FSMs are utilized to translate the network configs into BGP configs.
Evaluation is performed on configs from a large cloud provider and are verified against the same policies in english. Policies include both DCN and backbone ones. DCN policies take 31 lines of Propane code and the backbone one takes 43 lines (quite minimal). Evaluation is performed on an 8 core, 3.6 GHz Xeon processor. It takes about 10s per prefix per equivalence class for the DCN policies (< 9 mins in total) and around 45s per prefix per equivalence class (< 3 mins in total) for the backbone policies.
It is postulated that constructing the product graph takes the most amount of time. Finally, it is summarized that using Propane could substantially reduce the probability of errors in misconfigurations while keeping the code to a minimum.
Q : BGP papers have been coming out for about 17 years now. Does this one solve everything?
A : This solves a lot, but there are still open issues. Some problems just cannot be compiled with Propane and it does not deal with security issues such as prefix/route hijacking.
Q : ARCs and Propane approach the issue from opposing ends of the spectrum. One takes the network topology and builds representations from it, the other takes representations and builds configs. Is there a way to combine both?
A : ARCs cannot use arbitrary local preferences and Propane does not use edge weights. There may be a way to work both together, but will have to be looked into as future work.
Q : I did not see a place where BGP configurators can tweak the settings. Is it allowed?
A : Tweaking is definitely allowed using pass through parameters. But we see Propane being used as part of another system that allows more tweaking and Propane then generates the configs.
No comments:
Post a Comment