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

[Robin Whittle <[e-mail]>]

Hi Wes,

Thanks for your reply.  In "Re: [rrg] rrg-design-goals-04 - we should
write something much better", (msg07574 in the archives, with each of
your paragraphs as one hard-to-read line) you wrote:

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

OK - I recognise there are problems with tunneling due to its
overhead, Path MTU Discovery problems and the potential for one
traffic packet to be split over two or more tunnel packets, raising
the risk of data loss due to a given rate of packet loss.

Loc/ID Separation involves no tunneling.  However, as far as I know,
there's no Loc/Id Separation approach to mobility which avoids these
fundamental problems:

  1 - The MN (mobile node) can't be behind NAT.  It needs a global
      unicast address (Locator) so any other host can send it
      packets directly, and without any preliminaries.

  2 - Every time the MN (mobile node/host) changes its CoA (current
      "Care of Address" in the current system, in Loc/ID Sep.:
      "Locator") it has to do several things:

        a - Securely tell all its CHs (correspondent hosts) of its
            one or more new Locators and about which ever ones it
            has just relinquished.

        b - Securely update the centralised ID->Loc mapping system
            with the new Locator information so other hosts can
            initiate contact with it.  Depending on the design
            of the Loc/ID Sep. architecture, this may be the same
            thing as DNS or the DNS server also needs to be updated.
            (With Loc/ID Separation, every host needs a DNS entry
            as well as an entry in a potentially separate ID->Loc
            mapping system.)

Similar problems apply to the current LISP approach to mobility:

  http://tools.ietf.org/html/draft-meyer-lisp-mn-04

   (This v04 version from 2010-10-25 is a month old and contains
    the first substantial changes since v00 of 2009-07-01.
    I haven't read these changes, but a quick scan of the DIFF2
    gives me the impression that it hasn't changed in ways which
    affect my critique of LISP Mobile:

     http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html )

In the Loc/ID Separation world, maybe there will be no NATs - this is
an updated version of the IPv6 Internet, not something based on the
IPv4 Internet - since no Loc/ID Separation system can work on IPv4 for
reasons including inefficient use of address space and there being no
method of conveying Loc and ID in existing packet headers.

Point 2 is more fundamental.  I argue it can't be solved and that it
is therefore better to adopt TTR Mobility, where there is a 2-way
tunnels, established from the MN to a (typically) nearby TTR, which
acts as an ETR in the Core-Edge Separation scheme (LISP or Ivip,
though I think IRON uses TTR Mobility principles already) and handles
outgoing packets too.  With TTR Mobility:

  http://www.firstpr.com.au/ip/ivip/#mobile

the MN can be behind NAT and/or on a TTR Mobile address, in any
combination and depth of recursion.

If you stick with Loc/ID Separation, or LISP-mn, then there's no way
the MN is going to be able to securely update the Locator information
in multiple CHs all round the world in a timely or efficient fashion.
 (You could offload the work to a separate server to fan out the
updates, but this raises delay and scaling problems, since only the MN
has the nonces for each session with another CH.)

Each such update needs to involve strong crypto or a nonce or similar,
since it will come to the CH from an IP address or Locator which the
MN has no previous association with or knowledge of.  Assuming the MN
has just lost one CoA (AKA Locator)and instantly gained another, user
packets from the CHs to the MN will be sent to the old CoA/Locator
until the update is completed.  Only then will traffic, such as VoIP,
be received again by the MN.

If the CH is mobile too and it changes its CoA/Locator at about the
same time, they will both have to detect this and wait for the other
host to update its DNS or ID->Loc mapping in the global mapping
system.  Then they can use this (with this mapping system, with the
likely delays and risk of query or response packet loss which is
inherent in in any global query server network) to re-establish
communications.

So, every time the MN gets a new CoA, it needs to send out a flurry of
packets to its various CHs - however this is determined.  I guess a 5
minute cache time or similar would reduce the number of CHs to
contact, but this would force all CHs to revert back to DNS or ID->Loc
global lookup to continue or start a new session if there was more
than a 5 minute break between packet exchanges.

It would be bad enough doing this from a DSL or fiber-connected
service.  Doing it via potentially slow, potentially high latency,
potentially costly and potentially unreliable 3G or GPRS radio links,
with a compact battery operated device, would be much worse.

Also, the global DNS and ID->Loc lookup systems (which may both be
done via DNS or similar) will have to update their central
authoritative server information every time the CH gets a new CoA.

These rapid changes mean that all DNS and ID->Loc queries need to go
to the one or more authoritative servers - they can't be cached at
all.  To cache them for even 10 seconds would result in a 10 second
delay in the ability of two MNs to reconnect after they both get new CoAs.

So the entire DNS and ID->Loc lookup system is global and uncachable.

The global infrastructure and the central servers get a hammering.
You can make multiple authoritative servers to spread the load and
generally shorten the delay, if the query somehow automatically goes
to the closest server.  But then you increase the workload for the
update every time the MN gets a new CoA/Locator.

I think its much better to have the MN tunnel from its one or more
CoAs to a typically nearby TTR (Translating Tunnel Router).  The MN's
address or address range is mapped in the CES system (such as Ivip or
perhaps LISP) to use that TTR as an ETR.  So only the MN->TTR tunnel
establishment, from the new CoA to the existing TTR, is required to
continue communications from the new CoA.

There's no impact on CHs at all, or on DNS, or on the CES system's
mapping database each time a MN gets a new CoA.  Only if the new CoA
is far from the current TTR - such as 1000km or more - would it make
sense for the MN (under the guidance of the TTR system) to find a new
TTR (which can be done while the old TTR is still being used) and then
to switch the mapping to the new TTR.  So mapping changes would be
very infrequent and there would be minimal effort in establishing a
tunnel to the current TTR, from the new CoA, every time the CoA changes.

This leaves us with the burden of tunneling, but typically it will be
to a TTR which is nearby.

Changes to CoA can happen very frequently, even without the MN moving.
 The 3G network might bump it to a different base-station which uses a
different IP gateway.  Base station capacity limitations or RF
propagation and interference changes might end the session.  A new,
cheaper, faster WiFi link might become available, and the MN gets a
CoA on that, including behind NAT.  Just driving past an open-access
WiFi system of a cafe could cause this.  Likewise boarding a train, or
aircraft - or driving through a tunnel, or entering a building.

There shouldn't be a flurry of updates to CHs and the mapping system
ever time a cell-phone connects automatically to a WiFi system or
whatever.  But that is what would happen with Loc/Id Separation or
LISP-mn.

I think the difficulties with tunneling are not prohibitive, but that
the problems I mentioned with Loc/ID Separation mobility and LISP-mn are.


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

ILNP can only work on IPv4 with some new kind of header information.
It seems that some, many or all routers in general - or DFZ routers in
particular - are not able to handle packets with new header options
with their normal efficiency.  So unless you factor in upgrading all
these routers, ILNP can't work with IPv4.  If you have a magic wand to
upgrade all the IPv4 DFZ routers, such as to recognise new packet
formats, then there's lots more things we could do regarding scalable
routing.   Loc/ID Separation would not, in my opinion, be the best
approach to take.


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

I agree that expansion of mobile IP to encompass the billions of
people who want and need it must involve IPv6.  (This is on the
assumption that it won't do to give all these devices simply a behind
NAT IPv4 form of connectivity.  Maybe this assumption is not true - in
which case IPv6 won't be needed.)

I guess this will enable the devices to access the IPv4 world via a
NAT box and tunneling through the IPv6 access network and mobility
system.  This rules out direct VoIP with the IPv4 world, but it would
work via an intermediate server which the MN established a tunnel to
from behind its IPv4 NAT box.

So I expect (if the above assumption is true) that IPv6 will be used
to a significant degree for mobile networks in the next 5 to 10 years.
 That would drive the service industry for mobile users to get native
IPv6 servers.  It may also drive non-commercial users to get native
IPv6 connectivity at home so they can send packets straight back and
forth between their and their cellphone (music player, PC etc.)

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.

The impetus for global mobility is directly for the end-user's
benefit.  So I expect global mobility companies to provide such
services by TTR Mobility, even when the 3G operator doesn't want its
customers to have this.  Then again, if one 3G network prevents global
mobility and the other allows or provides it, many customers would
those the other.

I think the choice for mobility will be between:

 1 - Existing MIPv6 arrangements, which either require updated stacks
     (I think) in CHs to minimize path length problems via the one
     Home Agent, or reliance on existing stacks in CHs and the Home
     Agent, which involves potentially very long paths when the MN is
     on the other side of the world.

 2 - LISP and its current LISP-mn approach, which has the problems
     listed above, plus the fundamental problems with LISP such as
     the difficulty or impossibility of ITRs scalably determining
     which ETRs can actually get packets to the destination network.

 3 - Loc/ID Separation, such as ILNP or Name Based Sockets.  This
     will only work with CHs which have suitably upgraded stacks and
     applications.  So this is a non-starter.  Even if this hurdle was
     overcome, the recipient host will typically need to delay
     replying to the initial packet while it does an ID->Loc lookup,
     since it can't take on trust the ID and Loc values which are in
     the source fields of the initiating packet.

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

     Then, there are the fundamental delay and scaling problems
     mentioned above every time the MN gets a new CoA - and the
     MN not being able to use a CoA behind NAT.

 4 - TTR Mobility, with either Ivip or LISP as the CES system.
     (Or perhaps IRON, which apparently incorporates some principles
     of TTR Mobility - I haven't read the latest drafts.)

     If you choose to build or use something like Ivip, then you can
     use what I am calling ZOTv6 - Zero Overhead Tunneling for IPv6.
     This is Sampo Syreeni's suggestion and I will probably write up
     a quickie version of it for the RRG list sooner rather than
     later.  It can't work with LISP, since it doesn't carry the ITR's
     address with the tunneled packet - and LISP's protocols involve
     this and other information being sent along with the tunneled
     packet.  But it is good for Ivip since Ivip doesn't require the
     ETR to know the address of the ITR which is tunneling packets to
     it.

     ZOTv6 is for the ITR -> ETR tunnel.  You still need to use one
     of a variety of (typically encrypted) two-way encapsulation-based
     tunnel techniques for the MN <--> TTR tunnel, which the MN always
     establishes, including from behind NAT or from a TTR Mobility
     provided address.

     ZOTv6 requires an elaboration for the management of the ETR and
     more complex mapping data.  But for Ivip, the ITRs are not
     having to choose between multiple ETRs, so the ITR's job is still
     quite simple, compared to what a LISP ITR would have to do.

     ZOTv6 and the quite different ZOTv4 I have developed, inspired by
     Sampo's most insightful suggestion, both involve some Path MTU
     Discovery gotchas.  For packets below a certain globally agreed
     length, there's no extra work to be done.  For packets which are
     longer than this - say longer than 149x bytes - the ITR must
     initiate a brief two-way protocol with each ETR it is sending
     packets to - when a packet is being sent which is longer than
     the already established minimum MTU to that ETR, but not above
     any maximum which has been established so far.  This is a PITA,
     but I can see a way of doing it.  The ITR and ETR occasionally
     communicate to manage the ITR's estimate of PMTU to the ETR.
     This enables the whole system to handle jumboframes (~9k byte
     packets) across the DFZ if and when this becomes possible.


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

I don't recall Ran debating it.  Nonetheless, the claim that ILNP
works with existing IPv6 apps was accepted by most people, myself
included, until I tried in July this year.  The claim persists,
despite my objections, in the soon to be RRG Report:

http://tools.ietf.org/html/draft-irtf-rrg-recommendation-15#section-12.1.2

    ILNP can be implemented such that existing applications (e.g.
    applications using the BSD Sockets API) do NOT need any changes
    or modifications to use ILNP.


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

Yes - its the world's most entrenched IT system and its big feature is
the ability to communicate between any hosts.  This has taken a hit
with NAT, with behind-NAT hosts being second-class citizens which are
not able to communicate directly with each other - but they can still
communicate with any server on the IPv4 Internet.

Trying to introduce changes to the existing system, including using
the IPv6 Internet instead, leads to all sorts of difficulties which
mean most users won't bother and will soldier on with IPv4 as it is today.


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

In an ideal world *perhaps*, we could convince all the people who
write software for PCs, cellphones etc. to write new versions of their
programs to handle a new stack API and a new set of basic Internet
protocols.  This would be a very tall order indeed, since they would
need to test and maintain their code to work with and without a new
kind of stack, operating with their own code and other programs in
remote machines which both did and didn't have the new features and
which did and didn't run on a host with the new stack.  This would be
a complete nightmare.

"*perhaps*" means if we somehow were convinced that the initial delays
and other overheads inherent in Loc/ID Separation were a price worth
paying for its benefits (msg07017).

It also means deciding the generally longer delays and less efficient
operations required by Loc/ID Separation when the MN changes its
Locator are acceptable.

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.


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

Sprint - indeed a large operator!

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

OK.  Let me write something better:

   With the current pace of RRG official recommendations, LISP
   development and the likely impossibility of testing and developing
   ILNP or any other Loc/ID Separation architecture to the point where
   anyone might make a serious investment in deploying it, I would
   say there's no urgency this month or the next, and probably not
   next year or to 2013 or so, to actually come up with a detailed
   set of protocols and operating code which genuinely solves the
   scalable routing problem, for IPv4 or IPv6, including especially
   providing proper global mobility with generally VoIP-compatible
   response times and typically short path lengths.

   This is because there's no way LISP, ILNP or whatever will actually
   be seriously invested in or committed to in a way which will
   impose costs on users.

   In that time, the IPv4 DFZ will grow, and perhaps grow more rapidly
   than in the last 5 years, despite the imminent 2nd Great
   Depression.

   I am not sure how close your routers are to hitting a wall with
   the IPv4 DFZ's 330k routes:

       http://bgp.potaroo.net/

   but as long as they can cope with 600k routes, then I guess you
   should be fine for another 4 or 5 years.

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

   As long as you and a bunch of other operators are running mobile
   and DSL/fiber access networks, there's no significant problem with
   the number of IPv6 DFZ routes growing beyond 50k or 100k or
   whatever.  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.

   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.

   The only reason in the foreseeable future (to 2020) I can see for
   large numbers of EUNs wanting IPv6 connectivity is to serve the
   growing millions of mobile users on the necessarily IPv6 mobile
   networks Sprint and other such companies will presumably be
   deploying.   (This is on the assumption that you can't sell a
   mobility service with purely behind NAT IPv4 connectivity - and
   that you really must have a global unicast IPv6 address for each
   MN.  I am not convinced this assumption is true or will become
   true in the foreseeable future.)

   So my sense of there being "no tearing hurry" is this:

      It doesn't matter much whether I devote my life to developing
      Ivip drafts and software in the next year or two, since there's
      no chance that ILNP (or any other Loc/ID Separation architecture
      or LISP will be developed to the stage where some networks or
      users might make a big investment in them.

      So when the time is right, people will discover, or re-invent,
      TTR Mobility and Ivip.

      If I thought the IETF could mandate a change to LISP, or to
      ILNP etc. and that this mistaken (IMHO) decision would be
      binding on all Net users and so disastrously wrong and costly,
      then I would say there is a big hurry right now to raise
      awareness of what is wrong with these approaches, in part by
      fully developing something better (Ivip & TTR Mobility, in my
      view, or IRON, or whatever it is which someone thinks is
      better.)

   However, this statement in general about there being no tearing
   hurry about scalable routing, including mobility, is just for my
   vision of architecture developers in the next year or two.

   Companies such as Sprint need to plan now what they will be doing
   in 2016 to 2020.  So there is a hurry for them.

   Likewise anyone who wants to develop a commercial TTR-style
   global mobility service.  There's no standards or technical
   impediment to creating such a service today, for IPv4 or IPv6.
   The customers would pay a TTR company for a TTR service and use
   any access network at all, including one or more 3G providers,
   free WiFi services and their own WiFi extensions of home DSL /
   fiber / HFC for their Internet access.

   There could be multiple TTR companies, each with their own global
   network of TTRs, their own tunneling software for different types
   of MNs, their own DITRs at the globally dispersed TTR sites.
   Each such network could operate with its own private protocols,
   without any reference to IETF standards for scalable routing.

   For a number of reasons it would be better if they used common
   protocols - but a bunch of such services could co-exist
   perfectly well, even if they all used their own code and their
   own unique protocols.  Any customer of such a company could have
   their stable IP address wherever they go, and there would be
   generally optimal paths to all other hosts, including those on the
   same and on other TTR systems.


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

OK - I apologise for writing something which implies that you and
companies such as yours shouldn't be concerned about scalable routing
any time soon.

I think the best approach is TTR Mobility with Ivip.  While perhaps it
would make sense to have existing or future Cisco/Juniper routers
doing some of the work, I think that in the initial stages and
probably in the long-term future, COTS servers, including blade
servers, will be a much better set of devices to perform the ITR, ETR,
TTR and mapping server functions.

So I think you don't need to spend a cent on upgrading your routers to
achieve what I have in mind.


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

I agree.  I would be really happy if you and other people with your
expertise and responsibilities took a close look at TTR Mobility and
Ivip and let me know, privately or in a list such as this, what you think.

I have outlined what I regard as show-stopping problems with LISP,
LISP-mn and Loc/ID Separation of all kinds, including ILNP - and I
don't think these critiques have been refuted.   As far as I know, TTR
Mobility is the only way of doing global mobility, for IPv4 or IPv6,
with lightweight VoIP-friendly fast responses to new CoAs, and with
generally optimal path lengths.

TTR Mobility could work quite well with LISP, even if its mapping
system was quite slow to update all the ITRs.  It would work better
with Ivip, and I will soon write up ZOT - how Ivip can work with
ordinary packets, using ordinary routers, no longer than the original
traffic packet, in the ITR -> ETR tunnels.  ZOT can't work with LISP -
and LISP ITR->ETR/TTR tunneling for IPv6 involves a complete outer
IPv6 header, a UDP header and a LISP header.  This is a lot of
encapsulation overhead, especially for a VoIP packet which only
carries 20 bytes or so.


> 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

I would welcome your feedback on TTR Mobility and Ivip.

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.

  - Robin