HLP: A Next Generation Interdomain 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
  doesnt deserve its own acronym.

5
Old Ideas

• BGPs 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 HLPs value by
  improving over BGPs 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 todays 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
  dont 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 HLPs
  performance degrades as exceptions increase,
  HLPs performance must degrade over time.

13
Validation

• Assumption of constant propagation delay.
• Propagation delay may be correlated to the ASs
  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 dont 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.
  Isnt 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 ? 2u, 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 ASs. 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 2mean, 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 DiffServHLP.
  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 its 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.