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

[Jari Arkko <jari.arkko@piuha.net>]

Scott,

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

I don't recall if I said that host-based approach _never_ need mapping.
It seems possible to construct mechanisms that can live without one.
Shim6 and multipath TCP, for instance. However, even in these cases
having a mapping system would enable the hosts to do more. For instance,
in Shim6 you have to rely on application failover to another locator
during initial contact (which may be slow) and certain unidirectional
failure cases are unresolvable.

So yes, I agree that host-based approaches may also employ a mapping
function.

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

Also true. I didn't want to imply that push/pull is a binary choice.
There was only so much tree structure that I could draw in the given
amount of space and time I had for doing the graphs. But the push/pull
choice is really a continuum. As we discussed previously, even systems
that I would classify is pure push-based from a mapping perspective
would probably still employ some failure detection mechanisms and
negotiation with the peer network to deal with the choice of ITRs and
ETRs. (Because handling their dynamic failures at the mapping system
level would probably make the system non-scalable.)

Jari

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