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

Robin, can you please synthesize a short version of this?

2010.11.23 вт 11:08:10 Robin Whittle:
> 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
> 
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg
> 