On Thu, Dec 3, 2009 at 11:27 AM, Robin Whittle <[email protected]> wrote:
> Short version: Some people are uncomfortable about the > constraints perhaps precluding any proposal from > being viable. Can anyone suggest why this > statement of the constraints is incorrect? > > I think at least two proposals meet the constraints. > > Hello Dae, > > Thanks for your message, in which you wrote: > > > I do share your good intention with this list of constraints. > > > > But, again, I have some worry that perhaps this list will be falsely > > used to effectively reject most of proposals. Too many ideal assumption, > > perhaps with this list of constraints. > > OK - which of the constraints listed at: > > http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ > > do you think are not realistic, bearing in mind the recent messages > about 8, 9 and 10 not being absolute? > > This text is meant to reflect reality. It is not my "ideal" list of > constraints - ideally there would be no such constraints. > > I am happy to modify or annotate the list if you can think of > corrections or some circumstances in which a constraint would not apply. > > > If these constraints are real, then proposals which don't meet all > the absolute constraints should be rejected - or put on the > back-burner for some future scenario in which the constraints no > longer apply. > > If all the proposals fail to meet the constraints, then we are in > trouble. We only need one proposal which meets them, but ideally > there should be a few to consider. Meeting these constraints > regarding voluntary adoption doesn't indicate anything about the > other merits of the proposals. > > I believe APT and my own proposal Ivip fully meet these constraints. > > I think LISP-NERD could meet them, but it doesn't scale well. It > would always be better to use local full database query servers, as > does APT and Ivip. > > LISP-CONS, LISP-ALT and TRRP can't fully meet the 9th constraint - > that of not degrading security, robustness or performance. This is > because they use a distributed global query server system which means > that ITRs must often wait significant times - such as a fraction of a > second to a second or two - before they can send the first packets in > a new communication session. This means dropped packets and slower > starts to many sessions. Also, if the map query packet or its reply > are lost in their potentially very long paths across the globe, then > it may take the ITR two to four seconds to resend the query and > receive a mapping reply. > > > > Our patient is dying, in any moment. There's no way of saving him by > > surgery without causing pain, real severe pain. He won't voluntarily > > accept the pain. > > In which case the patient will die, or reach a point where the > surgery looks like the less painful option. > > But I think the patient is not going to die any time soon. The > number of routes in the IPv4 DFZ is growing inexorably, but not rapidly: > > http://bgp.potaroo.net > > The doubling time is about five years. > > Meanwhile, many smaller networks which want and need multihoming, > portability and inbound TE are not able to get it. So the situation > is bad, but the Internet still works. The cost of the growing number > of DFZ routes burdens all ISPs and multihomed end-user networks. It > also makes it somewhat harder for new ISPs to be established by > pushing up the price of the multihomed DFZ routers which every ISP > needs. The growing number of routes in the DFZ also contributes > somewhat to difficulties with the DFZ routers being slower in > converging on a new set of paths in the event of an outage. > > The Internet and its interdomain routing system is a growing system, > with plenty of money flowing into it. Lack of scalable routing won't > kill it - it just adds to costs, reduces the ability of end-user > networks to have multihoming etc. and makes it harder to establish > new ISPs (which reduces competition between ISPs). > > The surgery doesn't necessarily involve pain. If APT, Ivip and > perhaps some yet-to-be developed proposals meet these constraints, > then there isn't any "pain" to rule out widespread voluntary adoption. > > A successful proposal has to be highly attractive. One way of making > them attractive and generate revenue is to use them as part of a new > approach to mobility. Any of these core-edge separation schemes > (LISP-NERD/CONS/ALT, APT, Ivip or TRRP) could be used for a new kind > of mobility, for IPv4 or IPv6, using the TTR (Translating Tunnel > Router) approach: > > http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ > > I think this is so attractive, that you could sell this service, > complete with a system like APT or Ivip, irrespective of whether > there were IETF RFCs for the systems, and irrespective of whether you > wanted to solve the routing scaling problem. The mobile node gets > its own IP address (or prefix in IPv6) and can use it on any care-of > address, including behind one or more layers of NAT and including the > use of traditional MIP techniques. Path lengths are generally > optimal or nearly so, and the mobile hosts communicate fine with > ordinary hosts. > > I would be worried if all of the proposals failed to meet what appear > to be the real constraints imposed by voluntary adoption. However, > since I believe that two meet them well, then I am optimistic about > the problem being solved. > > Judging by the slow progress since the RAWS workshop in October 2006, > I think it may take another 5 or 10 years. I think it needs to be > done in a way that facilitates maximal usage of IPv4 address space - > since we are all dependent on IPv4 and I don't see this changing in > the foreseeable future. There's no tearing hurry about the IPv6 > routing scaling problem, but hopefully something similar to the IPv4 > solution will work well for IPv6 too. > > - Robin > > So, it pretty much seems that we're practically left with only two candidates alive by now. All others practically gone. Let alone any other new coming proposals, considering that most of those renowned old proposals even have not survived. I only have to read two proposals. Thank you for saving my time. -- Regards, DY http://cnu.kr/~dykim
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
