Hi Lixia,
some comments on your draft:
Le 22-juil.-08 à 18:56, Lixia Zhang a écrit :
To contribute to the convergence effort, we made a first (drafty)
draft on the roles and differences of map&encap vs transport
multipath solutions. a link to the draft is
http://www.cs.ucla.edu/~lixia/draft-efit-mapping-multipath-00.txt
We are looking forward to your comments!
Lixia
haste makes waste: I just noticed that the subject line of my
ealrier posting was wrong--there is only one *new* draft, not a
few :-)
(I looked the keyboard, f and n are pretty far apart, not sure how
the typo was made)
in any case: a revised version has been posted (further clarified
reasoning and discussions)
on behalf of the authors (Dan Jen, Michael, Dan Massey, Lan Wang,
Beichuan Zhang)
--
to unsubscribe send a message to [EMAIL PROTECTED] 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
[snip]
1. Introduction
[snip]
In addition, to solve the routing scalability via a transport level
solution, the effect will become significant only when a
significant
portion of edge sites deploy the new solution. However since
Internet is made of millions of autonomous administrative parties,
Jen, et al. Expires January 22, 2009
[Page 4]
Internet-Draft Mapping and Multipath July
2008
where each party acts on its own best interest, transport-based
solutions will be deployed by an edge site only when it recognizes
its own gain for doing so. The routing system has no control over
edge site deployment of new solutions, but has its own technical
and
economical constraints. Thus the routing system cannot solve
its own
scalability problem within a given time frame by counting on a
significant portion of edge sites to deploy the new solution.
From the above paragraph sounds like, differently from transport
level solution,
with the map-and-encap solution the benefits are significant from the
beginning
of the deployment, which in my opinion is not true.
Both map-and-encap and transport solutions need to reach a "critical
mass" before
providing any significant benefit. Of course the point where gains
start can be different for the two approaches.
[snip]
2. Benefits of Separation via Map & Encap
Separating the transit core from the edge networks can provide the
following two major benefits:
1. Protecting the core from edge growth and dynamics: a previous
study [eFIT] shows that removing edge-network prefixes from the
transit-core routing system can reduce the routing table
size and
routing churns by an order of magnitude.
2. Improving routing infrastructure security: although separation
does not eliminate any specific security threat, it can help
raise the barrier against malicious attacks targeted at the
global routing infrastructure.
“Any problem in computer science can be solved
with another layer of indirection. But that usually will create
another problem.”
—David Wheeler
My point is that even if separation can help in alleviating some kind
of attacks,
it could open the door to new kinds of attacks.
We should be careful before stating that security is improved.
First, one can easily trace back
offensive packets despite souce address spoofing by end hosts,
because each encapsulated packet carries its ITR's IP address.
Second, ITRs allow end hosts to send packets through the
transit
core, but can disable any end host from addressing a packet to
any device inside the transit core. Attackers can still use
compromised hosts within an end-site to DDoS the local border
routers, but such attacks only make a local impact and are
Jen, et al. Expires January 22, 2009
[Page 5]
Internet-Draft Mapping and Multipath July
2008
relatively easy to deal with. Attackers may also try to use
compromised hosts from multiple end-sites (e.g., a botnet) to
DDoS the routing infrastructure by flooding packets to some
remote end-sites. However, given the transit core topology is
opaque to end users, attempting to DDoS any specific
component in
the transit core becomes more difficult.
A Map & Encap based solution can also be deployed incrementally
on an
AS-by-AS basis, bringing immediate benefit to first movers.
[[ref to
MARCH'08 APT incremental talk?]]
I remeber the talk and actually I was not convinced. But if you have
made any progress
and you have a pointer, I am interested.
Furthermore, the Map & Encap approach allows new functions to latch
onto the mapping layer, providing architectural flexibility and
extensibility. We give three examples below to show how the
mapping
layer can be used to address major problems in the Internet.
2.1. Accommodate path selection and path diversity
We did some work on this subject:
http://inl.info.ucl.ac.be/publications/evaluating-benefits-
locatoridentifier
[snip]
3. Benefits of Transport Multipath Approach
[snip]
A more fundamental distinction between a transport multipath
solution
and SHIM6 is that the former utilizes multiple paths in parallel,
rather than using one at a time as the case in SHIM6. Besides
potentially improved performance, the simultaneous use of multiple
paths easily tolerates the loss of any single path, hence it
becomes
less important to keep track the status of any individual paths.
The use of multiple path is resilient to single path failure. Yet,
somewhere
you have to keep track of the individual paths. Otherwise you risk
to assume the existence of something that in reality is not available
anymore (path).
Jen, et al. Expires January 22, 2009
[Page 8]
Internet-Draft Mapping and Multipath July
2008
This last point makes it feasible for network providers to
aggregate
PA addresses. The aggregated prefixes will no longer track the
status of individual subprefixes, hence suppress edge connectivity
dynamics from propagating to the core. Instead, transport
protocols
will track the status of individual paths and make adjustment
accordingly.
Here I'm confused. In the previous paragraph you claim the contrary.
[snip]
4. Elimination or Separation
[snip]
However, multipath routing at the transport layer does not directly
solve the scalability problem. It simply allows for routing
scalability to be improved via another method: ELIMINATION of non-
aggregatable prefixes. This method is in contrast to the
SEPARATION
method we propose. Unless and until one can get majority, if not
all, of edge sites to act in harmony in adoping a new transport
multipath solution, hence to achieve the goal of (most) ELIMINATING
non-aggregatable prefixes from the transit core, otherwise it
cannot
be an effective solution.
I really do not understand that.
By SEPARATION I assume you mean loc/ID split. This, allows you
to get rid of IDs in the core network. Since IDs can be PI addresses,
this
leads to ELIMINATION of non-aggregatable prefixes.
So, can you clarify the difference?
[snip]
Cheers
Luigi Iannone
[EMAIL PROTECTED]
