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

[Scott Brim <swb@employees.org>]

Got it.  Thanks.  As usual the problem was just that the diagrams
sacrifice a lot of substance in order to represent things simply.

A facet-based approach would be great but I don't know how to do that.

Scott

On 8/7/08 9:32 AM, Jari Arkko allegedly wrote:
> 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