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 [EMAIL PROTECTED] 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
