HLP: A Next Generation Inter-domain Routing Protocol

1. HLP: A Next Generation Inter-domain Routing Protocol Offense by: Aaron Ballew Whitney Young

2. Why are we here? • Authors take a flimsy stance. • “…a starting point for debates…” • “We are under no illusion that HLP is poised to replace BGP any time soon...” • Just putting a stake in the ground to stimulate debate. • If they are so insecure about the merits of their proposal, they should come back when they have thought it through a little more.

3. Next Generation? • HLP is just applying old ideas as an optimization of BGP. • HLP only attempts modest improvements to current BGP performance. • HLP validation is based on too many assumptions and the emulation is tuned for HLP. • Too much complication for a non-problem that nobody will pay for anyway.

4. Old Ideas • Break up the internet into smaller segments, and use Link-State routing within/BGP between. • Happens within ASs today. IS-IS or OSPF as the interior routing protocol, and BGP for inter-AS routing. • Also very similar to BGP confederations. • HLP just aggregates ASs into a “super-AS.” It doesn’t deserve its own acronym.

5. Old Ideas • BGP’s flat structure supports the autonomy (hence “AUTONOMOUS” systems) that competing ISPs demand. • HLP changes that autonomy by sub-grouping ISPs. Why would they agree to cooperate? Who is the overall architect of this complex hierarchy? What happens when an ISP wants to change their status? None of this is addressed in the paper.

6. Performance • The paper attempts to show HLP’s value by improving over BGP’s performance. • If successful, it still only addresses a one-time improvement. HLP does not address its own performance limitations as the Internet continues growing. Delaying the problem is not a “next-generation” solution to the problem. • They are so stuck in the current Internet that their “next-generation” solution ignores IPv6 and proposes a long transition phase as ISPs adopt HLP. By the time HLP is adopted it may be irrelevant.

7. Performance • They claim the growth of the Internet routing table is a cause for alarm, but do not attempt to make the routing table smaller. • They focus on lower “churn” and more “isolation” without addressing whether these factors actually generate a significant amount of traffic. • The implication is that the large routing table and/or churn/isolation will exceed CPU/Memory/Bandwidth resources. This is not true in today’s BGP. Where is the traffic or computational burden? • Is anybody really complaining that BGP is too chatty?

8. Performance • Isolation • Repeated claim that BGP each prefix event generates many updates. • This is misleading because they do not point out that BGP can send many prefix route changes within a single update, even if it does touch many ASs. • The importance of isolation is being exaggerated.

9. Performance • Churn • They claim that churn is a problem because most “customers” at the lower level of the hierarchy don’t need to see this information. They also say most of the ASs fit this customer model. • They neglect to mention that the majority of “customers” at the bottom of the hierarchy are only receiving default routes anyway. • The ISPs these customers connect to are more likely to fall into an exception category, at which point HLP degrades and falls back onto BGP.

10. Performance • Convergence Time • They accuse BGP of having slow convergence time. • This is a function of timers that can be adjusted. • It is done on purpose to promote more stability. Most link failures are hidden within the interior routing protocol anyway.

11. Validation • Their “emulation” smacks of home-court advantage. Everything is set up for HLP to look good. • HLP assumes a special case, and tunes to that case. Non-conforming cases revert to the BGP model. • If they claim HLP is more robust, why does it rely on BGP for exceptions? BGP handles all of these cases quite well, so BGP is more robust.

12. Validation • Are they so sure that their “common case” is true? They base their analysis on inference results, of which there are many papers working on how to do this more accurately. It is not trivial! • Even if their common case is true, it will not necessarily always be true. • Exception cases are not decreasing. Since HLP’s performance degrades as exceptions increase, HLP’s performance must degrade over time.

13. Validation • Assumption of constant propagation delay. • Propagation delay may be correlated to the AS’s position in the hierarchy (i.e. Tier 1 ISPs being more geographically dispersed). • Assumption of no cycles/loops, but if there are, revert to BGP. • Assumption that all links have equal failure probability.

14. Validation • Assumption of AS as a node/atom • This assumption is questioned in Muhlbauer, et al. • Assumption that AS-path is mainly used for policy management. • It is for loop prevention. HLP just assumes loops don’t happen, but if they do, revert to BGP. • If you do want to use AS-path for policy management, HLP struggles, so authors propose a hack! Why not just use BGP in the first place? • They claim BGP suffers from route-flapping. • Explicitly ignore BGP route-flap dampening.

15. Strange Stuff • They identify false origin information as a problem (AS falsely owning a prefix), but their method is just a controlled version of falsifying the AS that owns a prefix. • They create a “cost” metric, but base it on hops. Isn’t BGP using hops anyway? • They create a cost threshold to suppress routes. • Cost metric still advertised across all the ASs (see Figure 2) • Cost threshold to suppress the routes is practically arbitrary  2*u, where u is the “mean inter-AS link-cost”

16. Strange Stuff • Say they are not routing by prefix, but really only add an extra step in the routing table to map prefix to AS’s. It allows the manipulation of the AS-path. Then, create a cost metric that is just based on the AS-path. • They admit that route-suppression requires great care, because it causes stale routes. • Why do this at all? They have not convinced us that these updates are so disastrous. Just send the update and keep the tables accurate.

17. Strange Stuff • They claim AS-path prepending is crude, as if to minimize the value of it. • Prepend is a common and standard tool in BGP. • It is analogous to other metric-based weighting. • It is no more crude that setting a cost threshold to be 2*mean, or to designing for a special case and then falling back to BGP. • They mention prefix-based policy as a weakness of HLP, but a strength of BGP. They make vague reference to patches that can be implemented to make up for this. • They throw in a paragraph about DiffServ+HLP. This comes out of nowhere and is not explored further in the paper. Even so, there is no reason BGP could not be augmented to support this, rather than swapping everything out with HLP.

18. Implementation • Their proposal not only requires a replacement for eBGP, they make a cursory mention of the need to replace iBGP as well. • This is an enormous undertaking. • HLP alone was complicated, but now you need iHLP too. What else needs to be changed?

19. Implementation • They claim HLP re-uses 90% of BGP code. • If so, why not just admit this a refurbished BGP? • Is the remaining 10% such a small undertaking?

20. Implementation • What is the economic benefit for ISPs to cooperate with each other and migrate to HLP? • HLP even requires a transition phase in the migration. By the time it’s done, BGP and HLP may both be obsolete.

21. Conclusion • HLP is a highly complex approach to a problem of arguable value that nobody will pay to migrate toward, and it does nothing to protect itself from the situation it claims to address.