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

[Dan Jen <jenster@cs.ucla.edu>]

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