WG charis: Pursuant to this email: From: Jari Arkko <jari.arkko at piuha.net> To: "Darrel Lewis (darlewis)" <darlewis at cisco.com> Cc: Robin Whittle <rw at firstpr.com.au>, lisp at ietf.org Subject: Re: [lisp] LISP Mobility Architecture Date: Tue, 01 Sep 2009 21:27:48 +0300 Then maybe I need to be clearer. Mobility and many other advanced features are out of scope. For now. When you complete the base specifications, we can talk about rechartering to add more features. Can we kill this tread? Thanks, Dave --- On Wed, Sep 02, 2009 at 02:43:54PM +1000, Robin Whittle wrote: > I am replying to Noel, Dino and Sam. > > Short version: If the purpose of the WG is to explore LISP on an > experimental basis, then that's fine - Mobility > can be ignored. > > However, since the purpose of this exploration is to > devise a lasting system for the Internet, then in > laying the experimental foundations of LISP-ALT, we > need to ensure this basis is correct for the long- > term task of solving the routing scaling problem. > > Mobility is a vital part of the future of the > Internet. Conventional mobility techniques don't > provide global mobility, in any access network, > with generally optimal path lengths and full > compatibility with existing non-mobile hosts. > The TTR Mobility approach solves these problems - > for IPv4 and IPv6. > > So I think the current work of the WG needs to at > least involve some plan for how LISP-ALT will > handle mobility. Without this, the work risks > being irrelevant to the final design of the > optimal routing scaling problem. > > > If there's no need for mobility, the total number > of EIDs is limited - so it is not so hard to > design a good system. Then, something simpler > like NERD would be preferable to ALT. > > Mobility in the form of the TTR approach will > definitely happen, because this is the only > mobility system (AFAIK) which provides global > mobility, in any access network (including behind > NAT), with generally optimal path lengths and with > session continuity - while remaining compatible with > existing apps and stacks. (Also, it will work fine > for IPv4 and IPv6.) Conventional mobile IP can't do > these things. > > TTR mobility will happen irrespective of the > routing scaling problem, so any solution to the > routing scaling problem needs to integrate it, > rather than let it run as a separate system. The > TTR approach should work fine for LISP. > > The current LISP-mobile approach has many problems: > > http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html > http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html > > not least that each IPv4 MN using this approach > would require not just its EID address, but a full > public RLOC address to for its CoA. It can't work > with the MN behind NAT, which is the typical > connectivity arrangement for IPv4. The TTR approach > works fine with the MN behind NAT. > > > > Noel wrote: > > > Actually, ALT is generally considered a short-medium term thing - > > for the long term, the concept is to replace it. > > Is this the consensus view? If so, then why bother with ALT at all? > The whole challenge is to devise an architecture which will work for > decades. Why not develop the proper solution, if ALT is not it? > > > Thanks Dino for the diagram. You wrote: > > > Robin, I just want to make one technical response with a few > > points: > > > > (1) LISP-ALT does not carry mappings. > > The entire scalable routing system needs to scale to some number of > EIDs. LISP-ALT's major - perhaps only - claim to superiority is that > it can, supposedly, scale to arbitrary numbers of EIDs since there is > no need to have any one device or communication path handle the total > mapping data for all EIDs, or updates to that. > > The LISP ALT network needs to convey a packet sent by an ITR, with a > destination address being the EID of the destination host, to either: > > 1 - The ETR (or one of multiple ETRs) which is currently > authoritative for the mapping for the EID prefix which the > destination host's EID address is part of, > > or: > > 2 - To some device which, while not being authoritative or an ETR, > does know the current mapping and can send the mapping back to > ITR via the Internet. > > Therefore, the ALT network needs to be able to handle these packets > from ITRs (whether they are map requests, or initial traffic packets > which also function as map requests) and have all its ALT routers > already set up, via the ALT BGP system, to forward those packets > correctly. > > > > (2) LISP-ALT carries EID-prefixes registered from sites to a > > specific aggregation boundary. > > > > (3) LISP-ALT also carries aggregated EID-prefixes into the core > > (the LISP-ALT core), upstream from the aggregation boundaries. > > I don't think the LISP-ALT network physically carries either mappings > or EID prefixes. It carries map-request packets from any ITR, > ideally via a short path, to a device such as an ETR which can > reliably answer the request and send mapping information directly to > the ITR. > > > > (4) When a mobile-node changes locations and gets a new locator, > > nothing in LISP-ALT changes. The mobile-node keeps > > Map-Registering to its Map-Server which is the same ALT > > topological point regardless where the mobile-node moves to > > or how often it moves. Mobile-node roaming causes no route > > injection or withdrawal in the BGP that runs on the ALT. > > Yes - I understand this. > > > > I have enclosed a picture of how the mapping database architecture > > is modular. So if you want to remove the center piece (labeled > > ALT), you can insert your favorite solution and the outer elements > > don't have to change (i.e. xTRs and CPE devices). > > I don't find the diagram very helpful. > > The problems with the current LISP-mobile approach do not result > directly from LISP-ALT - they are inherent in the core principle of > LISP-mobile which is to make the MN become its own ETR. > > The TTR approach works differently. The particular TTR which any one > MN is using as its ETR remains stable as the MN moves around, gaining > new and often multiple CoAs. If the MN moves far away (such as > 1000km or more) from that TTR, then it still has connectivity. > However, to reduce overall path lengths, the MN will find another TTR > which is closer to its new CoA. There is only a change to the the > mapping of the MN's EID when it starts to use a new TTR like this. > While the mapping change is propagating, the MN can receive packets > via the old and the new TTRs simultaneously, and via its 2-way tunnel > to each of them, use either one for its outgoing packets. > > With the TTR approach there are few mapping changes and there is > continual continuity via one or more CoAs to the current TTR, no > matter how rapidly CoAs are gained and lost. > > With the current conception of LISP-mobile, when the MN goes to > another address (which I call a Care of Address - CoA - meaning just > that the MN gets a new point of attachment to the Net) in order to > maintain connectivity it needs to change the mapping of its own > individual EID prefix: to this new CoA. Only when all ITRs which are > tunneling packets to the MN have this new RLOC can communication > continue. The MN would need to send (or cause something else to > send) a secure map update message to every ITR which is caching its > old mapping. Caching times need to be long in order to avoid > burdening the ALT network with too much map-query traffic. So the MN > (or whatever other devices help it) has a lot of work to do as soon > as it gets a new CoA. > > The longer the ITRs caching time and the more ITRs have been sending > packets to the MN during the caching time, the more updates need to > be sent and so the more management traffic and overall burden on ITRs > there will be. There are time delays, computational and > communication costs, reliability problems etc. involved in the MN > telling a potentially large number of ITRs about its new CoA. This > has to happen every time there is a new CoA. > > With the TTR approach, when the MN gets a new CoA the MN only needs > to establish a 2 way tunnel with its current TTR (or one of its > current TTRs) in order to maintain connectivity. The ITRs and the > mapping system are not affected by the new CoA. A mobile device > might gain and loose CoAs automatically and so, change them every few > seconds according to radio propagation changes while travelling in > urban environments. So the TTR gets a workout - but nothing else > needs to know about each new CoA. > > > > LISP was devised with the assumption that mappings would change > infrequently. LISP-mobile can only work if they change frequently > and instantly. LISP-ALT can't do either of these things. > > The TTR approach will work fine within these constraints - the > mappings do not change frequently and it doesn't matter so much if > the ITRs take a while to get the updated mapping. > > > My understanding of the purpose of this WG is that it is to do early > development work on a particular approach to the core-edge separation > scheme - LISP-ALT. You have chosen this over the alternatives > because you believe it is superior to them all, and to anything else > you can currently think of. > > Therefore, the WG's goal is to lay the foundation for the future of > the Internet - which will include Mobility. > > All I am saying is that in the current scenario where there is great > confusion about what LISP-ALT is supposed to do - how it is to be > deployed etc. > > http://www.ietf.org/mail-archive/web/lisp/current/msg01092.html > > you need to plan for mobility, because it will be part of the final > total system. > > I am also saying that the current LISP-mobile approach won't work and > the TTR approach will. > > > Hi Sam, you wrote: > > > I don't think there is a consensus that lisp-alt is superior. It's > > simply what we have to experiment with today and what this WG is > > chartered to specify. > > But few if any of the people in this WG would be putting any effort > into LISP-ALT if they did not think it was the best solution. > > There are other solutions - NERD, APT and Ivip at least. > > The fact that many people spend a huge amount of effort here working > on LISP-ALT, in preference to helping with or even publicly > critiquing APT or Ivip signifies to me that those people believe that > LISP-ALT is and will remain the best solution to the routing scaling > problem. > > > I think that the people I've talked to suspect that the mapping > > system is going to require a lot of work and that is probably one > > of the bits that may well be revised between experimental and > > standards track. > > > So, while working on alt, we're also working on requirements for a > > standards-track mapping system. > > APT, Ivip and LISP have all been around for more than two years. The > TTR mobility approach was first described with the initial Ivip > description in June 2007 - but it has always been a modular concept > which can work fine with LISP or APT. > > I observe a bunch of people devoting all their attention to LISP, not > even bothering to critique APT or Ivip. > > To me, this means that these people must believe that LISP-ALT is the > way forward. > > You are different, in that you were asked to participate in this WG - > and you have graciously devoted great efforts to the task. I > recognise you don't necessarily think that LISP-ALT is the best approach. > > I am different in that I think Ivip is the best approach, but I want > to keep an eye on LISP development and learn from it. I will > contribute to discussions when I see a problem with LISP-ALT which > seems not to be properly recognised. > > - Robin > > _______________________________________________ > lisp mailing list > lisp at ietf.org > https://www.ietf.org/mailman/listinfo/lisp
Attachment:
signature.asc
Description: Digital signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.