Hi Bill, You wrote:
>> I am calling for strong consensus on rejecting all strategies but A. > > I respectfully disagree. I believe there are useful solutions to be > had in strategies A, B, D and E. Here's why: > > Although strategy B may have more up-front deployment issues than > strategy A, we'll tend to get a better result in the long term by > tackling the problem at its root as strategy B does. Even if there were no difficulties deploying Strategy B host changes, I would argue against B for the reasons listed here: http://www.irtf.org/pipermail/rrg/2008-November/000271.html > Strategy A comes at the problem from the side, creating a slew of > nasty subproblems, like with PMTUD. I don't agree with your view that a network based solution (Strategy A) is unnatural, "from the side" or whatever or that the root cause of the routing scaling problem is a lack of functionality in the hosts. I believe your current problem statement is biased towards the notion that the solution lies in adding responsibilities to hosts (Strategy B). I suggest extra text to make a more comprehensive problem statement without such biases: http://www.irtf.org/pipermail/rrg/2008-December/000525.html I don't agree with the view that providing multihoming, TE and portability by adding functionality to the network (DFZ, ISP routers and end-user CE routers) is unnatural or undesirable. There are considerable problems with Path MTU Discovery in any map-encap scheme: LISP, APT, TRRP and the map-encap modes of Ivip. Six-One Router doesn't have PMTUD problems - though I think this is not a good solution, since it is only for IPv6 and since it only provides benefits if both networks are upgraded. If we can do modest firmware upgrades to DFZ routers, then Ivip doesn't need to go through its transitional map-encap phase, and could be deployed from the outset using forwarding, via modified IPv4 and IPv6 headers: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw http://www.firstpr.com.au/ip/ivip/ivip6/ So it is not true to say that all Strategy A proposals have PMTUD problems. Also, I think the PMTUD problems are solvable: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ If, for some reason, we can't initially deploy an Ivip-like solution with forwarding, then map-encap must be used at first. Unless someone can point out fundamental problems with my IP4 and IPv6 forwarding proposals, I will continue to believe that the long-term best solution is a network based one (Strategy A), using forwarding, rather than encapsulation. So I think that the only use for encapsulation is to get a routing scaling solution going before we could upgrade all the DFZ routers. Since I am reasonably confident that the functions to be upgraded are all in firmware (or will be in DFZ routers at the time we plan to introduce the solution, say 2013 or so) I am reasonably confident that with a bit of work at Cisco and Juniper (are there any other manufacturers of DFZ routers?) the routers could all be upgraded by the time we implement the solution. Depending on the placement of ITRs and ETRs, some or many internal routers need to be upgraded too - but this is only for ISPs which adopt the solution. > I have no opinion as to whether strategy A or > strategy B is a better solution overall, or even a better starting > point. I do believe both efforts would benefit from seeing both > through engineering and then letting the market choose. OK. I still think it is fundamentally wrong to have hosts involved in multihoming, especially mobile hosts with slow, expensive, unreliable links - when at least one of the network-based Strategy A proposals can solve the problem, without requiring any new host functionality or management traffic burden, and while providing substantial immediate benefits for early adoptors. Brian wrote: http://www.irtf.org/pipermail/rrg/2008-December/000577.html that the Strategy B host-based solutions are orthogonal to Strategy A network based solutions. I agree with this in some ways, and that the strategy B proposals are unsuitable for IPv4. However, if a Strategy A solution is the solution, then we don't need any other. Brian wrote that Strategy B is "very close to the plan of record for IPv6". Maybe so, but I think it is not close enough for our purposes. In particular, the Strategy B proposals (which so far are not well documented) provide session survivability in a multihoming service restoration setting, while basic IPv6 does not. SHIM6 provides multihoming session survivability, but it does not provide it in the the network centric manner which most end-user networks want and need. Nor does it provide portability of address space - there would be major disruptions, costs etc. whenever selecting a new ISP, not least regarding where IP addresses appear in ACLs and other places inside and outside the end-user network. I have no objection if some people want to develop new host functions, protocols, APIs and suitably updated applications for such hosts. They would presumably remain backwards compatible with existing hosts. My point is that the RRG will not find a better solution to the routing scaling problem within the Strategy B set of possibilities, than in the Strategy A set, for reasons including: 1 - Strategy B doesn't work for IPv4. (There's not enough space to give every end-user network a slice of space from each of its ISPs' space.) 2 - Strategy B only delivers substantial benefits (robust multihoming for all or almost all communications) after all, or almost all hosts have upgraded stacks, APIs and applications. Ignoring the prohibitive difficulties in deploying these changes, this still has the major problem that be adopting Strategy B as a routing scaling solution, we force every host, including mobile hosts with slow, expensive, unreliable, last hop links to: Carry extra stack and probably application code complexity to do all the work for multihoming, TE and whatever so-far not invented approach gives the same ease of changing ISPs as portable address space. Carry extra management traffic which is required to perform these functions (thereby increasing costs and/or reducing the capacity available for user traffic). Make all user communications dependent on the successful and rapid conveyance of this management traffic. Strategy B involves: 1 - Forced migration of most end-user networks (and therefore almost all hosts and Internet services) to IPv6 - before the IPv4 routing scaling problem becomes unacceptable. 2 - Forcing extra complexity, burdens and reduced performance into all hosts. These may be a minor concern for a PC with a fast Internet connection, assuming the management traffic is to local destinations. However, the management traffic is likely to be to the correspondent hosts. It involves a major cost burden and/or performance degradation on any host with limited computational resources and/or with a slow, costly and unreliable last-hop link. If we had no other alternatives, I guess we would pursue Strategy B. However, we have Strategy A alternatives, for both IPv4 and IPv6, which have none of the problems just mentioned, including (Ivip with forwarding) no PMTUD or packet overhead problems. So I think it is OK for someone to pursue Strategy B if they wish. Its just that Strategy B is not the way forward for solving the routing scaling problem. I suggest we eliminate it from further consideration. > As discussed months ago, parallel processing of the RIB combined with > techniques to compress the FIB as contemplated by strategy D would > extend the useful upper bound of routes in the BGP RIB by at least one > and possibly two orders of magnitude. Though this does not extend > multihoming as far as some of us would like, it does usefully extend > it with far less difficult deployment issues than either Strategy A or > Strategy B. There is no mention in Strategy D or any other strategy for "parallel processing of the RIB". I think trying to split up the RIB into multiple CPU systems, each with its own RAM (since RAM bandwidth is the problem, more than raw CPU power, now we have 4 and 8 core CPU chips) is a nightmare. Programming multiple computers to share a complex set of tasks like this is costly, error-prone and will drive up the cost of all DFZ routers, which is one of the things we need to avoid, if at all possible. I thought most people agreed that FIBs are not the limiting factor in DFZ routers today, or in the foreseeable future. The costs and CPU and RAM limitations of the BGP implementations are a serious problem, especially for routers with many neighbours. Also, there are fundamental difficulties with the stability of the whole BGP control plane. For instance, with more and more prefixes, a single outage causes changes in best path for more and more prefixes, resulting in a greater flurry of messages, delays in processing these, problems with stability of the entire network etc. Are you suggesting we not reject Strategy D, or that we create a new strategy involving FIB improvements and multiple CPU&RAM handling of the RIB for all DFZ routers (or at least those with many neighbours), while retaining BGP as it stands, with perhaps some incremental improvements? > Although strategy E is loaded with political minefields, the technical > portion of its implementation is both trivial and fully backwards > compatible. Strategy E resolves the most serious routing scalability > problem, that of keeping the Internet core stable. While it would be > nice to solve the other multihoming problems, the only critical one is > core stability. I question the wisdom of throwing this approach away > prior to demonstrating market acceptance of an alternative. Strategy E does not solve the routing scaling problem. It does not provide for more end-user networks having multihoming, TE or portability except due to the marginal effects of such users paying ISPs collectively to install bigger routers to handle marginally more prefixes in the DFZ. I suggest we reject it as a solution. If we fail to find a solution, or if the solution which the IETF adopts, develops and promotes is not widely enough accepted, or fails technically, then Strategy E is one of the possible outcomes. However, it is not a solution. > Would anyone object to me assuming that those in favor of rejecting > all but strategy A also favor proposals to reject each of the others > individually? I support rejection of B, C, D, E and F, individually or collectively. - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
