Hi Bill, In "Re: [RRG] Why delaying initial packets matters - complex web pages & real-time P2P" you wrote:
> It seems to me that one assumption which has run heavily through > this thread is that man-n-encap would entirely replace the > existing system where the EID and LOC are the same. It strikes me > that not only is this unlikely, it would be undesirable as well. > > I won't spend a lot of time on why outright replacing BGP is > unlikely. Suffice it to say that anything the size of the > Internet has a great deal of inertia and no map-n-encap scheme > discussed so far has enough punch behind it. I intend Ivip's address space to be so attractive to end-users (who want or need multihoming, TE and portability) that it will be very widely adopted - ideally becoming the usual form of address space for end-users. I think we need the new map-encap space to be attractive to end-users large and small, established and new: http://psg.com/lists/rrg/2008/msg00275.html None of these map-encap schemes replace BGP. They rely on the BGP system for directly handling the "RLOC" address space which is used by all ISPs and by end-user networks which for one reason or another are not using the map-encap scheme. All traffic between ISP networks still relies on the BGP system. The map-encap scheme provides a way of dividing the address space down into smaller chunks (micronets AKA EID prefixes), each individually handled by any ETR (Ivip) or one or more ETRs (LISP and APT) in the world. Each such division does not directly burden the BGP control plane, other than to the extent to which Mapped Address Blocks (MABs) are advertised in BGP, as they are in Ivip and LISP with "Proxy Tunnel Routers". The idea is that each MAB provides many micronets for many end-users, so this burden on the BGP control system will be small compared to the burden of serving that number of end end-users with conventional "RLOC" space which is managed by BGP alone. > I will spend a couple paragraphs on why a hybrid system is a > desirable outcome. I am not sure what you mean by "hybrid", but I think you mean some end-users are better off with the current BGP-managed approach to PI space while others are better off, or will be encouraged/forced to use map-encap space. This is very different from what I am proposing with "hybrid push-pull" (APT and Ivip) and from the NERD concept of "hybrid" in which ITRs are full database for some subset of the EID space and rely on a global query server system to be a caching ITR for the rest of the EID space. > There are relatively few scenarios in which a client machine > derives a benefit from a static IP address assignment. Mobility, > at least with respect to long-lived connections. The occasional > firewall admin where inbound access to a resource has been > restricted by source IP address. Not a whole lot else. OK - in part because widely used client applications are adapted to operating behind NAT, where the public IP address may change from time to time, as with the user's DSL/cable modem getting a new address. But I think it would be best to have a map-encap scheme which didn't require distinctions to be made between different methods of using the address space, other than the dichotomy between space used by ISPs for ETRs and other functions (including for PA space) and for all other organisations and individuals ("end-users"). > Given a choice between a mild slowdown and the temporary > assignment of an IP address from a highly aggregated pool, most > clients would elect to use the temporary assignment. There are more choices than between ALT (mild slowdown) and pushing the "client" subset of end-users into dynamic addresses from RLOC space. I am sure there are many end-users, large and small, who want stable, portable, multihomable address space to run both servers and client hosts on. So trying to decide which end-users are "server" end-users and which are "clients" would be difficult or impossible. For instance, there is likely to be a huge demand for mobility with persistent connections due to the device/network retaining the same IP address no matter which network it uses for its care-of address - with both IPv4 and IPv6, with generally optimal path lengths. Cellphones and mobile PCs (probably the same thing in the future) are the most obvious use for this. Ivip is intended to provide this form of mobility. > Servers are a whole other can of worms. There are spam filters > which block and permit by IP address. There's lots of crappy > software which doesn't respect DNS TTLs. Renumbering servers is a > difficult and fault-ridden process. Given a choice between an > extra delay equivalent to a DNS lookup on every request and > having to renumber, more than a few server administrators would > choose the extra delay... Especially for email servers and other > devices that move data in bulk where the delay simply doesn't > matter. Yes, I think for email servers the initial packet delay is not a problem. For web servers, game servers etc. having a bunch of these, especially for a bunch of customers, would be extremely disruptive and expensive for the end user - the hosting or self-managed server company - and their customer end-users. However, given the choice of keeping or attaining conventional space (BGP-managed "RLOC" space) and changing over to a map-encap type of address space which involved almost any perceivable degradation (reliability, initial packet delay etc.) I think most existing and new "server hosting" companies would avoid the new system like the plague. Competitors with the original, authentic, good-ol-days RLOC space would be pointing out the superior responsiveness of their servers compared to the slower nature of the new-fangled plastic map-encap space. > The conclusion, it seems to me, is that the desirable outcome is > a hybrid system in which a fellow in Operations can consider both > PI space and Fast space, and then choose the one best suited to > his particular application. The RRG needs to decide what sort of map-encap scheme to recommend to the IESG for engineering development. I assume we will be aiming for consensus that one scheme alone should be developed. I think the aim is to have a map-encap scheme which will be as widely adopted by end-users as possible. This includes end-users of all sizes, existing and new. Ideally, virtually all end-users would use the space, leaving only the ISP's spaces (and the MABs) directly managed by BGP. I don't think any of the current schemes make conventional PI space intrinsically less attractive. However it is becoming increasingly hard to obtain due to the IPv4 address shortage and concern about the burden it places on the DFZ routing table. I assume that by "Fast space" you mean the map-encap type of space. I don't think it will be "faster" than conventional RLOC space, in terms of packet delivery - but it would probably be faster and certainly cheaper and easier to alter its management for multihoming, TE and portability. The choice may be between: LISP-NERD Full push - looks hard to sustain full database push to every ITR on the planet in the long term. LISP-ALT Full pull - looks complex and unreliable, with long paths and delays for queries == initial traffic packets. (The ALT network could be tweaked with more meshiness to reduce typical, but not worst-case, long paths due to the current focus on address aggregation over geographically short paths.) LISP-ALT with caching. Typically improved mapping response times but is initial packet delivery any faster? Mix of NERD and ALT - but why bother with ALT if you can push the full database to even a handful of ITRs. Put a query server at those sites and then the ALT network is not needed. TRRP http://bill.herrin.us/network/trrp.html Pull via a DNS-like global distributed query server network. Instead of ALT's circuitous path problem, TRRP has more direct paths to the query servers - but a similar delay problem arises due to the likely need for multiple recursive queries to find the authoritative query server. APT Hybrid push-pull. Full database ITRs and query servers are integrated into a Default Mapper. All participating ISPs have a few of these, with a slow push scheme (separate BGP-like flooding system). No support for non-upgraded networks (Ivip's anycast ITRs in the core == LISP's Proxy Tunnel Routers) - so it is not incrementally deployable. Ivip Fast push (I will write an ID on this ASAP) to full database query servers and ITRs located anywhere - so it is highly flexible. Caching ITRs and optional caching ITR functions in sending hosts (not behind NAT) access the local query server(s) and get responses faster, less expensively and more reliably than with a global query server network (TRRP or ALT). Optional caching query servers can be used as well, which query the full database query servers directly, or through other caching query servers. Query servers respond with mapping information and a cache time, and send notifications to the querier (ITR or caching query server) if the mapping changes in that time. Incrementally deployable, fast mapping (also an ITR can let an initial packet go - it will be forwarded to a full database ITR) and capable of supporting a new form of mobility. None of these are "faster" than current PI space for handling packets, but those which rely on a global query server network will be significantly slower with some initial packets. > In other words, whether you favor LISP or IvIP or TRRP, your > system should be designed as a supplement to BGP, not a > replacement. A supplement which serves to enable PI space. End-users with current PI prefixes could convert them into individual MABs with Ivip (or use the space with any other scheme). Then, if they had been advertising the space in multiple longer prefixes, the space could be a single MAB advertisement under BGP, reducing the size of the DFZ routing table. Then they could split it up into as many micronets as they like, which they can't do at present, due to the 256 IPv4 address granularity limits of the BGP system. I have been using "PI" to refer to conventionally BGP-managed PI space. The new map-encap scheme provides Provider Independent space too, so if you include map-encap-managed space as part of "PI", then I think all the schemes accord with your last two sentences. - 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
