[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