[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] arguments for map and encap
Hi Michael, Dan,
Thanks for contributing.
|First, some background. We know the fundamental reason that
|routing system doesn't scale: there is a conflict between network
|customers and their transit-network providers. It is in the
|network users to have provider-independent (PI) addresses, while it is
|in the interest of network service providers to maintain IP address
I think that this is not a precise statement of the problem. There are many
reasons, both technical and non-technical why end-sites want to have PI
addresses. Further, it's clearly the service providers who are damaging
aggregatability through actions such as traffic engineering by prefix
deaggragation. Thus, I think it's much more productive to focus on the
technical issues that need to be addressed.
Today, the technical driver that injects routes into the global table is the
use of explicit, globally-advertised prefixes for multi-homing. Most of the
other drivers (e.g., not wanting to renumber, traffic engineering without
re-aggregation) are economically based, and not technical requirements of
the architecture. Thus, we should be focused on dealing with the
The crux of the multi-homing issue is that explicit prefixes are necessary
because transport protocols are tied to the initially selected address and
if that address is topologically significant, the transport is vulnerable to
|We believe that the answer is to take a path that (1) best
|conflict for the long term and also (2) provides a feasible economic
|incentive to make the changes.
You are of course welcome to your opinion, but that's not the only
perspective. In particular, the RG is not constrained in this way. While
it makes sense to remain relevant, economic incentives are not the only way
to ensure that particular architectures are deployed. Did the Web get
deployed initially because of the economics? Subnetting? NAT? CIDR? BGP?
In short, there are a variety of forcing functions that can cause
deployment, and our real requirement IMHO, is to ensure that there is some
effective forcing function but it need not be economic. Sometimes just
solving a common problem is sufficient.
|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
|it also opens up a number of new possibilities at both sides
|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
|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.
I'll just point out that to make a more convincing and balanced argument,
it's necessary to address both the positives and negatives of an approach.
Would you care to expound a bit?
to unsubscribe send a message to email@example.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