[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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