[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] arguments for map and encap
- To: Routing Research Group <rrg@psg.com>
- Subject: [RRG] arguments for map and encap
- From: Michael Meisel <meisel@cs.ucla.edu>
- Date: Mon, 05 May 2008 18:06:31 -0700
- User-agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
In their earlier post
(http://www.ops.ietf.org/lists/rrg/2008/msg01159.html), the RRG
co-chairs requested that we first come to a consensus on the
"highest-level branches of the decision tree". Towards that goal, Dan
Jen and I want to open a discussion on this issue with some arguments
for choosing the map & encap branch.
First, some background. We know the fundamental reason that the current
routing system doesn't scale: there is a conflict between network
customers and their transit-network providers. It is in the interest of
network users to have provider-independent (PI) addresses, while it is
in the interest of network service providers to maintain IP address
aggregatability.
So what the RRG is tasked to decide is: what changes should be made to
resolve this conflict?
We believe that the answer is to take a path that (1) best resolves the
conflict for the long term and also (2) provides a feasible economic
incentive to make the changes.
1. Selecting the best long term solution.
The Internet as it stands is a great success. We want to first make
changes that are in the best long term interest. Faced with equally good
long term changes, we should also select the one with the highest degree
of backwards compatibility.
2. Ensuring that parties required to make changes have incentive to do so.
For any solution that does not align cost with benefit, it may be
possible to deploy it in a few places, but the solution will not be
widely adopted unless the economics are on the right side.
This means we cannot expect everyone to change operations. It is
reasonable to ask each ISP to make a big change, but only if they can
see some appreciable benefit. Conversely, it is not reasonable to ask
all home users to change in order to better accommodate ISPs. The
scaling problem is perhaps felt most profoundly at the ISPs, so fixing
the problem by making changes at all ISPs seem more reasonable. Forcing
changes upon all network customers would need to be matched by a
compelling gain for those customers.
Arguments for Map & Encap
For a long term solution, we believe some decoupling of the network
customers and transit networks is necessary. The conflict over PI
addresses is a clear example of the need to decouple. In the long term,
it also opens up a number of new possibilities at both sides for scaling
and routing changes in the core and techniques to exploit mapping
service for new features at the edges.
As compared to other types of schemes, map & encap requires changes only
to the nodes at the borders (where encap/decap occurs), along perhaps
with a small support infrastructure. No changes are required at end
hosts who benefit only indirectly from the change -- in fact, map &
encap schemes can be made invisible to end users (and edge networks in
general, if desirable).
Service providers, both large and small, are the parties that stand to
benefit from a resolution to the conflict. Thus, they should be the ones
who bear the burden of deployment. Thus, map & encap seems to be the
solution that best aligns cost with benefit, as well as the best
long-term direction going forward.
-Michael and Dan
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg