Hi Steve, You wrote:
>> ILNP and any other proposal which involves host >> stack changes, and worse-still application changes, >> is a complete non-starter for the practical problem >> of solving the routing scaling problem. > > Routing scales just fine; the problem is addressing. And it is not just a > practical problem, it is architectural. I think it is largely agreed that the BGP routing system scales acceptably up to a few hundred thousand BGP advertised prefixes, provided they don't change all that often. To say the problem is with addressing is to say that the problem is that end-user's don't want to renumber their networks and hosts every time they change to another ISP or when one ISP goes down and they need to use another, as part of their day-to-day multihoming solution. ILNP is an attempt to change the way hosts use address space so the hosts don't make much demands on the routing system. That is fine, but there is no way we can convince a sufficiently large proportion of end-user networks to do this - so I think it is completely impractical as a solution to the routing scaling problem. >> ILNP may be of theoretical interest, as a >> clean-slate proposal. However, I am only interested >> in discussing practical solutions. > > I thought the Internet was the "smart host, dumb network". It was, and I think it is something we should try to preserve as much as possible. If we designed the Net from scratch, SHIM5, ILNP or whatever would be practical and desirable in many ways. However, we are not able to introduce a new Internet and have everyone move to it, with new stacks, applications and a new kind of connection from their ISP. We have a billion or more users, virtually every one of them 100% dependent on IPv4 space, stacks and applications. We need to keep the service going continually, while enticing them to use something new which will solve the scaling problem - even when most of these end-users neither know nor care about the scaling problem. > If things are so ossified that we cannot envision host changes in the > future, then we really are screwed. Only if "screwed" is defined as any retreat from the "smart host, dumb network" approach. I don't think it is such a bad thing to have ITRs and ETRs and a mapping system. In many ways, it is a kludge, but it is also a suitably centralised method of handling a network-centric problem - the fact that whole end-user networks need to move to different ISPs without renumbering their networks, and the fact that the same thing essentially needs to happen at a moment's notice for multihoming. > Just guessing, but it is quite likely that 80% of the hosts that will be > operating 5 years from now don't exist yet. The software 90% of them will > be running surely doesn't exist yet. What is practical and what isn't > depends on your timeframe of interest. Yes, but we have to maintain service 100% of the time, incrementally introducing something which will solve the problem. We can't force this, so the new thing needs to be voluntarily adopted by the great majority of end-user networks. For this to be the case, there needs to be immediate benefits over costs. That doesn't work for ILNP or SHIM6 because it only provides benefits once almost every network has adopted it. Ivip, LISP with PTRs and probably APT do work, since they provide portability, TE and multihoming support for packets sent from non-upgraded networks. TRRP has some approach to achieve this too. - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
