Luigi, Thanks for your comments. Here is a reply.
> > 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. Actually, a transit network can receive scalability benefits immediately after deploying the new map&encap solution. APT is one solution where this is true. An exerpt: " APT islands configure their border routers as "tunnel routers" (TRs) so that their customers' data packets will be encapsulated and decapsulated as they enter and exit the AS. An APT island can then remove all customer edge prefixes from their BGP routing tables. " See www.cs.ucla.edu/~meisel/draft-apt-incremental-00.txt for full details. > > 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. > Yes, I agree we should be careful. > > A Map & Encap based solution can 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 I was not convinced. If you made any progress > and you have a pointer, I am interested. > Can you tell us specifically why you were not convinced? We would love your feedback. > > We give three examples below to show how the mapping > > layer can be used to address major problems in the Internet. > > We did some work on this subject: > http://inl.info.ucl.ac.be/publications/evaluating-benefits-locatoridentifier > Great, thanks. We'll reference your data in future work. We are also working on quantifying some of the benefits of map&encap. > > This last point makes it feasible for providers to aggregate > > PA addresses. The aggregated prefixes will no longer track the > > status of individual subprefixes, suppressing edge connectivity > > dynamics from propagating to the core. 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. > Really? This paragraph claims that PA prefixes are aggregatable by network providers in the core, and once these edge prefixes are aggregated, reachability status of these edges no longer result in updates to the global routing table, leaving reachability tracking to the transport layer. I don't see where we claim the contrary. Can you show us? > > Multipath routing at the transport layer does not directly > > solve the scalability problem. It simply allows for routing > > scalability to be improved via ELIMINATION of non- > > aggregatable prefixes. This 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 achieving the goal of ELIMINATING > > non-aggregatable prefixes from the transit core, or 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 core network. Since IDs can be PI addresses, this > leads to ELIMINATION of non-aggregatable prefixes. > > So, can you clarify the difference? > Ahh, we should probably reword this a bit. Our point is that under the map&encap approach, we remove the PI prefixes from the core, but they still exist, as they are used by the edge sites. Since they still exist, we call it separation rather than elimination. This is in contrast to the transport scheme, where edge sites actually stop using PI prefixes in exchange for PA prefixes from their providers. Thus the PI prefix is eliminated from use. Sorry about the confusion. We'll try to clear that up in our next revision. Dan Jen -- 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
