It appears that the RRG mail daemon doesn't like the way that outlook attaches my digital signature, so I disabled that for now...
> -----Original Message----- > From: Robin Whittle [mailto:[email protected]] > Sent: Monday, November 22, 2010 1:52 PM > To: George, Wes E [NTK]; RRG > Subject: Re: [rrg] rrg-design-goals-04 - we should write something much > better > > Do you really support the goal that the solution be either Loc / ID > Separation (ILNP etc. not LISP, Ivip or IRON) or be compatible with > Loc/ID Separation? [WES] Yes, I do, hence my vote in favor of publishing the design goals. I run a mobile network, so I know a thing or two about mobility schemes that use tunneled traffic and anchor points to maintain connectivity while the end host moves around without routing table updates. It works... However, the gear and encapsulation required and the scale tradeoffs to make it work are not optimal, and extending it and trying to make it scale to the rest of the Internet is exactly the wrong direction in my opinion. > > If so, can you or anyone else think of a way any Loc/ID Separation > architecture could work on IPv4? [WES] Well, based on what I read I believe that ILNP can, but I understand that you don't, nor do you buy the explanation to the contrary. I don't wish to re-debate that with you because I doubt it'll change either of our minds. However, let me be absolutely clear: I. don't. care. whether it will work on IPv4. It's too little, too late. We're out of address space for IPv4. I can't number my 50 million mobile customers with IPv4, most emerging economies can't number their entire populace out of IPv4 the way that the current first-world countries have done, and we can't number the smart grid out of IPv4, to say nothing about the other machine-to-machine and internet of things applications that are poised to dramatically increase the steepness of the routing table growth curve. I'll concede that some of the route-scale solutions proposed here might be able to extend IPv4's useful life by allowing for segmentation and reuse of the space, but with IPv4 exhaustion likely happening in the next 3-6 months, they're not going to be implemented in time. Further, for them to be better than a NAT44(4) in that regard, they have to restore seamless end to end connectivity (and as far as you're concerned, do it with out application or CPE changes). Like it or not, IPv6 (and specifically IPv6-only) is going to be a reality. 5+ years ago it might have made sense to have a solution for IPv4, but at this point I'd rather focus on IPv6. If we get a solution for IPv4 for little incremental work, great, but I don't want to delay the work to force that issue to get resolved if we have a workable solution for IPv6. In the normative language of the draft, I view an IPv6 solution as REQUIRED, an IPv4 solution as somewhere between DESIRED and OPTIONAL. > Can you or anyone else think of a way it could work even on IPv6 > without requiring a major rewrite of application code, and in some > cases changes to application protocols themselves? Ran claims ... but ... > I decided it probably > couldn't be. Ran didn't even attempt to show how it could be done. > Tony tried (msg07111) and gave up ... [WES] As you say, you've been over this, and I'm not going to be any more successful at debating it with you than the author of the draft. You obviously believe that host changes are less possible than expecting providers like me to swallow hard and implement another round of costly infrastructure to solve this problem, and I'm not going to be able to convince you otherwise, but I'll still make my opinion known since you asked. A very significant part of the reason why IPv6 has taken so long to deploy and there is resistance to things like ILNP is that the Internet infrastructure has gotten very sclerotic and resistant to change. I'd rather not reinforce that by enabling people to continue assuming that host changes are off limits and the network providers should be solely responsible for keeping the internet working (and all the while racing each other to the bottom on prices for services). > > There's no tearing hurry about scalable routing. [WES] Hi, my name's Wes, and I'm an [token] operator. You don't know me, but I work for a large-ish US-based ISP in the DFZ, and we happen to be very much interested in scalable routing... RIGHT ZARKING NOW, so that something might be implemented before we have to spend another XX million USD in a few years to buy $router_vendor's next generation linecard and memory to hold the routing table. This is especially true if we do that upgrade once or twice more only to then have to spend the same or more when someone finally gets around to implementing a route scale solution, especially if implementing the proposed solution requires the network to change instead of hosts. So I trust you'll forgive me for not trusting your unsupported assertion on how much time we do or don't have to solve this problem. Hopefully that explains why a number of my messages to this list have been to try to move things forward, not prolong (or worse, recycle) debate. I'd like to see some of this stuff move towards implementation phase independent of whatever politics have destabilized this group, because running code will expose all sorts of design flaws much faster than debate on an email list ever will. Having to evaluate running code and make a choice between multiple different options that exist in the output of this group is a problem that I would very much like to have, and I see no way that revisiting arguments that you've apparently been having with this group since 2007 gets us anywhere closer to that goal. Thanks Wes George ________________________________ This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
