Re: [RRG] thoughts on the design space 1: the space

[Scott Brim <swb@employees.org>]

On 7/24/08 1:18 PM, Jari Arkko allegedly wrote:
> Anyway, here's the the basic design space as we saw it:
>
>   http://www.arkko.com/ietf/rrg/designspace_dataplane.jpg
>   http://www.arkko.com/ietf/rrg/designspace_mappingreso.jpg
I disagree that host-based approaches never need mapping.  These two
dimensions -- where the function is done and whether it needs mapping or
not -- are orthogonal.  You can place a mapping function in a host just 
as easily as you can place it in a border router.  This also implies 
that Lixia's "separation/elimination" distinction is more effective 
than "in host / at edge".
There are a number of hybrid possibilities in "push/pull".  See
draft-rrg-taxonomy-00 and the arguments Dave Thaler made on the old
architecture list.  For example, you can push an index but pull
mappings.  You can push mappings differently in space (treating some
locations as special, or pushing them partway) and time (differently at
different times of day).  So just "push/pull" as a distinguisher doesn't 
help enough.

On 7/31/08 10:58 AM, Iljitsch van Beijnum allegedly wrote:
> One issue with these solutions, and presumably with any solutions that 
> exposes the locators to the hosts, is that it doesn't solve the 
> renumbering issue.
> We probably want to avoid exposing locators to the end-user site in any 
> shape or form to make sure that the end-users won't be tempted to put 
> locators in their configurations and thus make it hard to renumber 
> locators, requiring us to come up with an id-loc-loc split in the future.
And when you explose locators within the local network at all, you 
probably require them to be used in network management.  To me this says 
that an 8+8-style approach that zeroes out the "glop" part of an address 
is better than one that replaces a globally routed prefix with a locally 
routed one.

> On 24 jul 2008, at 13:23, Jari Arkko wrote:
>
> > First, I am not at all convinced that we actually HAVE to employ a 
> > cache for the forwarding lookup.
> I think we tend to operate under the unstated assumption that a single 
> router must be able to resolve mappings for the full set of 
> destinations. I don't think that's necessary. If one big box is 
> expensive to build, it makes sense to use multiple smaller ones, that 
> each handle part of the destination name space. As long as we build the 
> mapping system such that it's easy to direct different mappings to the 
> appropriate router or encapsulating device, we should be able to get 
> parallelism benefits when scaling up.
Right, this is a reasonable approach for a site that has too much 
diverse traffic to use cache effectively.  It doesn't mean that other 
sites couldn't use cache.  An effective architecture will allow a 
diversity of approaches at the edge.
Scott


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