Download HLP: A Next Generation Inter

HLP: A Next Generation Interdomain Routing Protocol
Offense by:
Aaron Ballew
Whitney Young
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.
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.
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 interAS routing.
• Also very similar to BGP confederations.
• HLP just aggregates ASs into a “super-AS.” It
doesn’t deserve its own acronym.
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.
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 “nextgeneration” solution ignores IPv6 and proposes a long
transition phase as ISPs adopt HLP. By the time HLP is
adopted it may be irrelevant.
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?
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.
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.
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.
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.
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.
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.
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.
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”
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.
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.
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?
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?
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.
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.