on the place: isn't it possible that the solution might be implemented in different places depending on the functionality to be suported? Thus, the loc id split might go all the way to the hosts if they want in-session handover or host multi-homing, but not in other cases? performing this near the ISP edge does not feel like a problem to me - have you seen what they are doing with DPI?! louise
________________________________ From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Thu 22/03/2007 14:24 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Int-area] My remarks at the microphone Let me repeat and expand upon my remarks just now. -- The place -- There are three obvious places to implement the locator/identifier (or locator/locator) mapping: 1. in hosts 2. in site border routers / middleboxes 3. in ISP networks In hosts is extremely problematic for a number of reasons: - costs and benefits aren't aligned with regard to the routing table issue, so not enough incentive for deployment - the number of hosts is enormous, updating them all takes prohibitive amounts of time - middleboxes and the like make any kind of change, especially with IPv4, very hard to deploy - there is no reason to assume that renumbering locators will be significantly easier than renumbering host addresses is today On the other hand, the advantage of working in hosts is that the additional state is least problematic there because hosts already keep state for all their sessions/associations. Site border routers or middleboxes share the economic issue and, to a lesser degree, the renumbering issue. Middleboxes (but not site border routers) also generally store state for active sessions and the number of sessions is still relatively limited at this point, so a chaching mechanism is still workable here. Performing the mapping in ISP networks has the very important benefit that cost and benefit are aligned, but at this point, the number of sessions flowing through any individual box is almost certainly too large to be safely handled using caching, so flooding of at least some state for all possible destinations is probably required. Additionally, it's not too problematic to push something that started in ISP networks to middleboxes, and something in middleboxes to hosts, but the other way around is often not possible or very hard. See the issues with shim6 proxying -- A mapping system -- As I said, BGP and DNS can both be considered to be mapping protocols, and they both have some aspects that are desirable and some aspects that are problematic. The DNS can carry millions of entries in a single zone (with some effort) and probably an unlimited number of entries given a suitable hierarchy. However, it requires on-demand operation, which means dropped packets and/or delays at session start and the risk of caches (see SQL slammer worm experiences). The DNS also has caching so not only do you not get any updates when something changes, if you (as an application) go out and ask again, you get a cached answer. BGP on the other hand floods everything but has serious scaling issues and suffers from the problem that local optimizations introduce global state. Additionally, BGP is a routing protocol so it needs to know about paths and loops, which means that information in BGP must be updated at each hop. What we need in a new mapping system is the scalability and parallelism of the DNS coupled with the immediacy of BGP, but where BGP distributes next hop information, the new mapping system should distribute "last hop" information. Margaret (I think) brought up the point that if a new mapping system contains all the information that's now in BGP, we haven't really gained anything. That's not necessarily true. The problem with BGP is not so much the amount of information, or even the number of updates, but rather, the need for all this information to come together in one place: the RIB of every core router. If the new system is designed to allow the easy splitting up the full state of the entire internet over an arbitrary number of devices, each of those devices can live at the knee in the price/performance curve. An important goal in a new mapping protocol should be the ability to flood updates where needed, i.e., in the case of multihoming where the fact that one ISP is no longer usable is important to know for all correspondents of the multihomed site, and the more deliberate propagation of information that isn't time sensitive, such as the movement of a single homed user of PI space. Additionally, such a protocol can supply hooks for obtaining more detailed information directly from the source. This would be useful in mobility, where a destination is always reachable through the home agent, and a slight delay in optimizing the path towards the current location of the mobile node isn't problematic. In the same way, the flooded mapping state could be highly aggregated and therefore make packets flow rather suboptimally, but as soon as communciation starts, better mappings can be negotiated end-to-end. If we go for a "jack up" solution to the routing scalability problem, existing PI prefixes can be jacked up one by one, facilitating gradual deployment. However, the mapping mechanism could be made forward compatible with more advanced identifier/locator splits so the benefits would be in both the short-medium and long-medium terms. _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
