Hi Bill, You wrote, in part:
>> OK. Renumbering a bunch of web servers also means having to alter >> the records in a bunch of nameservers - not all of which would be >> controlled by the hosting company. > > Yes, this is among the many reasons why provider independent space is > such a desirable thing. We all agree on the need for more end-users to be able to keep their addresses, meaning fully portable PI space, but by a different mechanism than the current BGP approach. > My point was in a different direction: content publishers already > tolerate delays on the same scale as the difference we're talking > about between push and pull. They tolerate these delays today solely > for the sake of their developers' convenience. There is simply no data > to support the conclusion that they wouldn't tolerate the same > character and scale of delay for the sake of their system > administrator's convenience. If the entire Net changed to add some small delay, then this would not be a barrier to adoption of the new map-encap scheme. However, as I and others have written, if the new address space performs worse, in a way which really matters to end-users or which could be construed by marketing people as such, then it will be very hard to get widespread adoption of the map-encap scheme. Yet I think we need this very widespread adoption for end-users large and small if the system is to be effective at solving either the routing scalability problem or the closely related problem of improving IPv4 address utilization. > The notion that a pull-based map system will necessarily be too slow > ain't nothin' but a theory and the theory is both unsupported by any > data and apparently contradicted by some of the data that is > available. The ALT scheme is not just a global query server system (tending to be slow, long-path and less reliable than using local query servers), but is worse still due to the aggressive address aggregation causing path lengths often far longer than the geographic direct path. See the thread "ALT's strong aggregation often leads to *very* long paths". Nobody disagreed, but there was talk of more meshy cross-linking to give a better chance of a geographically short path. K. Sriram's diagram: http://www.antd.nist.gov/~ksriram/strong_aggregation.png is also instructive. TRRP has a similar delay problem, which would occur frequently enough to be significant. The ITR has to sequentially query and get responses from several DNS-like servers in order to find the authoritative server with the mapping information. Unless you anycast those intermediate servers (which does not scale well) then there will be significant delays in quite a few circumstances. This seems to be far worse with IPv6, where each level in the DNS-like hierarchy is a smaller number of bits, and there are more bits in the EID address than with IPv4. To some extent you could solve this by sending back a response, giving authoritative nameservers for several levels of subdomain - which enables the ITR to jump a few levels along its path of enquiry without sending another query and response. But the inherent problems of global query server systems still remain in TRRP, even if you could optimise it significantly. Only anycasting most or all of the TRRP DNS-like nameservers so all the queries were answered by a somewhat local (same country or continent) server would significantly remove the delays inherent in TRRP Even if we think the delays are insignificant, they can still prevent the map-encap scheme being adopted, as Marshall Eubanks wrote: http://psg.com/lists/rrg/2008/msg00381.html >> > If you're placing a /18 on the 'net, we >> > can easily accommodate you with the hardware that's already >> > deployed, let alone with hardware currently shipping. >> >> I think you are saying that larger end-users might as well use the >> conventional techniques we use today - a BGP advertised prefix. > > Yes. The worldwide cost of one advertised prefix works out to > something in the neighborhood of US $8000/year and falling. The system > is only broken for prefixes whose value is less than that. >From the point of view of large end-users with cash to burn, the system isn't broken. However, as the cost falls and more end-users gear up to get this kind of space, the system becomes more broken from the point of view of the companies who run DFZ routers, due to the bloat in the number of DFZ routes - which is the primary problem we are here to fix. I argue that the new map-encap space must be equally attractive to large and small end-users, including those with current BGP-managed PI space: Large companies with PI, small with map-encap space? http://psg.com/lists/rrg/2008/msg00275.html No-one has yet debated this. >> If map-encap space had deficiencies, such as frequent delays in >> initial packets, then the big end-users (who have a choice whether >> to adopt it or not) would avoid it like the plague. Only the >> smaller end-users, who can't afford or justify one or more /24s of >> conventional BGP-managed PI space, would be choosing map-encap space >> - because they have no other option. > > This is a bad thing? As an (er hem) larger gentleman, I can tell you > without reservation that one-size-fits-all never does. Ah yes, but many folks are establishing their nook in the Net with the intention of growing enormously. We need them to adopt map-encap space - which means they need to be confident it will still the best arrangement when they are bigger. >> Large companies with PI, small with map-encap space? > > I would put it differently. Just 'cause I can't afford a Porsche > doesn't mean I care to ride the bus. Bare BGP prefixes for those who > cough up the cash. Map-encap for those who value it less but still > want something that isn't as ghetto as slices of PA space. This might work to some extent, but not if the price of BGP-managed PI space comes down. I think it strongly desirable that the new architecture provide a form of address space which is really attractive to all end-users. I think this is a feasible goal. - Robin -- 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
