> -----Original Message----- > From: Robin Whittle [mailto:[email protected]] > Sent: Tuesday, November 23, 2010 4:08 AM > To: George, Wes E [NTK]; RRG > Subject: Mobility, Loc/ID Separation, ILNP, LISP-mn, TTR Mobility, IPv4 > & IPv6 > > But giving every cell phone a global unicast IPv6 address, via any > means, including especially a mobility system which means the device's > applications use the same IP address no matter what access network > they are using, would enable each device to do direct VoIP to any > other IPv6 device. That would reduce the wireless networks to > providers of IP connectivity, since it would be trivial to have a VoIP > application on the cellphone which communicated directly with the > stable (portable and usable via all access networks) IPv6 address of > the correspondent device. (Phone numbers would be replaced by IPv6 > addresses - or by DNS entries for these addresses.) > > I am not sure there is an impetus for 3G operators to do this, since > it would enable many people to bypass their voice services, which are > presumably charged for at a higher rate than whatever they would > charge for the VoIP packets. [WES] Welcome to my nightmare and the resulting paradigm shift about to hit the mobile industry. IP bit carriage is already becoming a commodity on the wireline network, as services are primarily over the top. The ISP is becoming today's power company. We don't care where the power comes from, as long as you deliver it reliably and cheaply. The challenge is to make money in said commodity business, which means driving out costs. Mobile operators may protest and kick and scream, but given the bill of goods that they're selling - ubiquitous access to the "cloud" and high-bandwidth, always on applications (that are provided by a third party) on new fancy devices that go well beyond a telephone, the days of a walled garden are numbered, at least in my opinion. Never mind the fact that there are incentives to keep mobile to mobile traffic as local as possible, rather than carrying it back to some anchor point and back out to the same tower. Even if there are still gateway and setup functions provided by the mobile carrier, end to end connectivity has benefits.
> > To use TTR Mobility, you don't need new routers. You, or someone > else, needs to develop a bunch of protocols and software to implement > them. The ITRs, ETRs/TTRs and mapping system can all be done with > COTS servers. These functions don't need to be done by Cisco/Juniper > routers. You would also need to develop tunneling and management > software for each particular type of mobile device your customers use. > Assuming your routers, mobile networks and mobile devices can do > IPv6, it "just" needs a lot of software development. Competent > programmers could figure it out from reading the TTR Mobility and Ivip > stuff. You don't need to wait for the IETF. Hopefully my exposure of > this stuff means none of it can be patented - or that such patents > would not hold up in court. > [WES] Well, ultimately that's true of a lot of these proposals, that competent programmers could build an implementation and no one needs to wait for the IETF. However, I'm not a programmer, and I don't have a passel of them at my disposal nor the funds to bankroll them, so it ends up falling to those who came up with the idea to seek support among like-minded folks, either in the research or vendor development community to get an implementation stood up as a proof of concept. So much like many inventions, the key is now to convince some "investors" to help you implement so that you can show how good of an idea it is, instead of just being convinced of it yourself. > > There's no way the IPv6 DFZ routing table is going to become > too large for your routers in the foreseeable future - say in the > next 10 to 15 years. (Unless the limitation is the total number > of IPv4 and IPv6 routes - in which case the problems can't be > separated and my analysis would be different.) > [WES] Many modern routers no longer specify IPv4 vs IPv6 in their scale targets because they assume you'll be running both. They talk about the entire routing table, and if there are things like TCAM or memory slots, IPv4 takes one slot, IPv6 takes two, so it's dependent on how many of each you have together. Sure, running single stack will improve the scale of the one routing table considerably, but it's still a finite resource. Keep in mind that many edge routers are also holding huge L3VPN routing tables (as big as or bigger than the global table), so some may realistically be nipping at that magic 1M route threshold in a year or two. > The only scaling difficulty would arise if there were > lots of end-user networks (EUNs) wanting, getting and advertising > their own IPv6 PI prefixes AND if you really wanted or needed to > exchange packets with those EUNs. There would need to be a lot of > such EUNs doing this before the problem got to the 200k, 300k, 600k > or whatever level where I assume you begin to hit limits with the > routers. [WES] Unfortunately that's exactly what is happening. Every time I turn around, especially in the RIR community, the refrain is "renumbering sucks, we have plenty of IPv6 space, so give me PI space so that I don't have to ever do it again, even (especially) when I want to tell my upstream ISP to get stuffed." Further, in an attempt to make IPv6 deployment as attractive and easy as possible, RIRs are always toying with some new idea about how they might make it easier for people to get PI space, up to and including proactively assigning a block to every ASN in the table. Those who bring up concerns about routing table slot usage are usually handed the old chestnut "$RIR doesn't create routing policy, we just assign addresses, so that's not our concern." Even if we stay with PD, multihoming and TE mean that deaggregation is pretty much expected. I agree that the growth rate will be less than with IPv4, but it's still a consideration. If anything, it just gives us a more realistic timeframe to get a fix implemented, rather than resetting the clock for when we should start worrying about it. > > That growth in EUNs advertising PI prefixes has nothing to do with > mobile or DSL/fiber access networks, even with billions of > customers. You might have part of your 3G/4G network supporting > 50 million customers, each with one device. But it will only > involve one or a few prefixes in the IPv6 DFZ. So I can't see how > 3G/4G ISPs alone will ever cause the IPv6 DFZ routing table to > grow to a problematic size. > [WES] There's some truth to that. However, as I've mentioned here before, this scale issue does go beyond the DFZ, and when you start looking at the amount of routes you carry internally prior to being able to announce that aggregate to the rest of the DFZ, the design and how much aggregation you can do regionally becomes a concern. > > 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. > > > > Its counter-intuitive that valuable solutions might come for free from > some bloke in Australia you haven't met, rather than the Cisco or > Juniper folks who you have paid millions or billions of dollars to for > their essential and generally excellent routers. But until someone > shows that my proposals contain fatal flaws, this counter-intuitive > notion hasn't been disproven. > [WES] It's not counter-intuitive. Vendors didn't always rule the IETF, and many good ideas are the result of "some bloke." However at this point, running code is the method by which to prove or disprove any of these implementations, as I would hope that people far smarter than me have already looked at these in great detail over the last 2-3 years and identified the theoretical issues and corner cases and potential fatal flaws. Put simply, it's been debated to death now, and I expect that you've refined the basic design as much as you will be able to as a result of those conversations. Everyone on the list who maintains that an identified flaw in a given implementation isn't actually fatal and that critics just need to understand the implementation better can be vindicated by showing test results from a sample implementation, no matter how rudimentary. Wes George
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
