Subject: Re: [rrg] Mobility, Loc/ID Separation, ILNP, LISP-mn, TTR Mobility, IPv4 & IPv6

From: Robin Whittle <[email-masked]>
Date: Sat, 04 Dec 2010 18:17:09 +1100

Short version:  The number of routes in the IPv6 DFZ is about 1/90
                of number for IPv4, but has a faster doubling time
                of only ~1.5 years.

                Summary of why I think TTR Mobility is the only
                approach to global mobility which could work (with
                the possible exception of IRON).

                While Wes is right to expect running code and full
                documentation of any proposal he would consider
                seriously, unfortunately it looks like I won't have
                time in the foreseeable future to develop the Ivip and
                TTR Mobility documentation as well as I would like
                to, or to write detailed protocols or code.

                Growth in the DFZ routing table is not the primary
                routing and addressing scalability problem.  The more
                pressing problems are:

                  1 - The need for global mobility (IPv4 and IPv6)
                      for billions of hand-held devices.

                  2 - The need for millions, tens of millions or
                      whatever End User Networks (EUNs), including
                      many SOHO and some purely residential networks,
                      to have their address space portable and
                      multihomable, in a scalable manner.

Hi Wes,

Thanks for your message (msg07607) of 24 November.  Sorry about my
delay in replying.  You wrote:
	>> 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. 

Yes - I think the most important thing is not what is convenient for
cellphone network operators, but the fact that people want to be able
to do anything anywhere, to any host, and are prepared to pay for it
rather than stay in a single carrier's walled garden.

>> 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.

I agree.  I don't have time to implement Ivip and TTR Mobility on my
own.  I figure over time other people will take an interest in these
in the IETF and/or some company will want to develop a working system
for themselves, independent of the IETF.

It would be radical and probably inadvisable for a company such as
Sprint to take on the development of such a system, especially since
the principles are public and hopefully can't be locked up in patents.
 All I am saying is that these approaches are worthy of consideration
and that I argue they are the only ones which pass muster, given the
failings of other approaches to mobility:

  1 - I think Ivip with TTR Mobility can do what is needed: a scalable
      approach to global mobility, with the existing host protocols,
      for IPv4 and IPv6, with minimal activity by the mobile node or
      anything else every time the MN gets a new CoA - and with
      generally optimal path lengths.

  2 - Your hope of application and stack programmers adapting their
      work to any new host protocol has absolutely zero chance of
      coming to fruition.  The existing host protocols are perfectly
      good and are more efficient than Loc / ID Separation:

        http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

      Trying to write and debug apps which work with and without
      updated stacks, with other apps which may or may not be updated,
      would be a nightmare.

  3 - ILNP and other Loc / ID Separation architectures all involve
      changes to host stacks and applications - and are only
      potentially practical for IPv6.  They only provide genuine
      scalable routing benefits and benefits to adoptors once every
      other host uses the new architecture.  Until then, every host
      stack and application would have to work well in a mixed
      environment of current protocols and the new one - this would
      be such a headache that I can't imagine how it could be done.

  4 - The Loc/ID Separation approach to Mobility, and the LISP-mn
      approach, both involve correspondent hosts and the mapping
      system being sent secure updates, by the MN, every time the MN
      gets a new locator (or CoA for LISP-mn).  Since changes to CoA
      could happen every second or so, this is never going to be
      practical.  Only TTR Mobility solves this problem while still
      providing generally optimal path lengths - the MN makes a new
      tunnel to the currently used, typically nearby, TTR.  There's
      no change to mapping and the correspondent hosts don't need to
      know of the MN's new CoA at all.

  5 - TTR Mobility could be used with LISP, but Ivip would be a better
      choice.  (I haven't read the latest IRON drafts, but I
      understand it uses some TTR Mobility principles.)

>>    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.

OK - it is my impression that the IPv4 DFZ routing table is a
significant burden on routers, but far from the only one.  If there
was a situation where a large proportion of ISPs' routers would
suddenly be unable to handle every advertised route (of /24 and
shorter) in IPv4, when the number got to, for instance, 500,000
routes, then there would be a more unified sense of alarm amongst the
ISPs about this aspect of the routing scaling problem.

As far as I can tell, there's no sharp relationship between the number
of routes in the IPv4 DSP and significant increase in difficulties for
any one ISP or for all of them.  So its a "boiling the frog slowly"
scenario where the incremental short-term cost of accepting the
increasingly worse situation is generally less than taking radical
action to fix it globally.

>>    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."

   'Once the rockets go up, Who cares where they come down?
   That's not my department,' says Werner Von Braun!"

Still, my point is you would need a *lot* of EUNs to do this before
the problem got to the scale of the current IPv4 DFZ routing table.

  http://bgp.potaroo.net
     330k routes.  Doubling time ~5 years

  http://bgp.potaroo.net/v6/as2.0/index.html
     3.7k routes.  Doubling time ~1.5 years . . . Hmmm

I agree the IPv6 rate is a lot steeper.  If the doubling time gets to
1 year, that will take just over 6 years to get as bad as IPv4.  If it
stays at 1.5 years, it will take 11 years.  This is different from the
1k routes 4 year doubling time of three years ago.

> 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.

I agree - I guess you meant "PI".

>>    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.

OK - but that is a private matter for each ISP.  Its not a burden
forced on every ISP which wants to participate in the interdomain
routing system - and all ISPs must.

While this whole RRG project started largely on the basis of alarm
about the growth in the "DFZ routing table" size (number of routes in
the IPv4 and later IPv6 interdomain routing system, most of which are
from EUNs wanting portability and multihoming) I think the more
pressing concerns are:

  1 - The pressing and potentially very profitable need for global
      mobility, with a single stable IP address (or /64 for IPv6)
      for billions of hand-held devices.

  2 - The inability of many EUNs to get the portability and
      multihoming they want (at all, or in a scalable manner - since
      getting PI space and advertising it in the DFZ is not scalable).

      This extends to potentially tens or hundreds of millions
      of EUNs.  For instance, in Australia, a "National Broadband
      Network" is now being created.  It will be funded at vast
      expense by taxpayers and be an admirable PON network, operating
      as a wholesale carriage provider, with ISPs using it to deliver
      their retailed services.   The plan involves mandatory closing
      down of copper (DSL) and cable (HFC) Internet services wherever
      the NBN is installed. (!!!!)

      Let's say someone puts a backhoe through a bundle of fibres so
      my home-office network is dead for a few hours or days.  I want
      to be able to use a 3G cellphone service, with a dynamic and/or
      NATed address, for my network - so I want to be able to
      multihome my current single IPv4 address patch of space.  (Or
      maybe use a WiFi link to someone on the other side of the valley
      who still has fibre connectivity.)

In this context, the question of the number of routes in the IPv4 or
IPv6 DFZ is not the central scaling problem in routing and addressing.

>>> 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. 

I still have more work to do on it, but I don't have time to rewrite
everything as well as I would like.

> 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.

Ideally I would be able to do this.  Maybe in a few years' time.  In
the meantime, other people may take an interest in these ideas and
develop their own protocols and their own code.

 - Robin

---

From: Robin Whittle <[email-masked]>
Date: Sat, 04 Dec 2010 18:26:22 +1100

Hello DY,

I agree with your statement (msg07615):

> I don't think decoupling mobility from routing should be listed as a
> design requirement. I don't think we can eliminate the possibility of
> routing inherently providing mobility.

The term "routing" is not defined clearly in:

  http://tools.ietf.org/html/draft-irtf-rrg-design-goals-04

If it means "every active device between the hosts" then this would
mean all the existing routers and whatever new devices, or additional
router functionality, is provided as part of a Core-Edge Separation
architecture (LISP, Ivip or IRON).   Since these additional devices
and functions could be designed to handle mobility in a scalable
fashion, it seems a bad idea to mandate in the design goals that this
not be allowed.

No-one is suggesting that existing routers do a lot more work to
accommodate mobility.  If the goal was simply to protect existing
routers from such an extra burden, it might make more sense, if it
could be shown that this could never be done scalably.

Since the whole project is about scalability, and since some solutions
(in my view, the only ones which could work) involve devices other
than the hosts doing the extra work, all that is required is that the
new and existing devices do their work scalably.

  - Robin