[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] arguments for map and encap



catching up this thread ...

On May 6, 2008, at 7:40 AM, <hannu.flinck@nsn.com> <hannu.flinck@nsn.com> wrote:

Hello Michael and Dan

We good and thoughtful mail from you. I agree with the logic you present
here. However, there  maybe some details that you are overlooking.

- multihoming is not only for service providers, but required by end
users/network customers. Multihoming is not only about PI addressing,
but also of the possibility to route through alternative provider and to
have a backup route. If this is the case, the beneficiary is the end
user who should bear the cost for what she/he wishes for.

there might be a slight misunderstanding here: Michael's original msg meant to say that *user site* multihoming is among main drives of BGP routing table growth (alternative paths and backup paths are all benefits from having PI prefixes). a scalable routing system is to solve a problems facing service providers today, thus they would be willing to deploy the solutions.

- it is not all service providers who experience the routing scalability
problem. The problem seems to be more of tier 1 and tier 2 providers,
rather than the access providers. At least those access providers I have
talked about this, do not confess having such a problem. Of course we
could assume that the ISPs are going to be consolidated to bigger ones
and at this point we need to have the technology in place. But I do not
find this believable.

I agree with TOny's reply here, the concerned parties are whoever carrying the full table.

Lixia

-----Original Message-----
From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf
Of ext Michael Meisel
Sent: Tuesday, May 06, 2008 04:07
To: Routing Research Group
Subject: [RRG] arguments for map and encap

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


--
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


--
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