Re: [RRG] a new (not few) draft towards convergence

[Luigi Iannone <luigi.iannone@uclouvain.be>]

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

[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

luigi.iannone@uclouvain.be