Re: [RAM] Ivip (was ViP ...)
Robin Whittle <rw@firstpr.com.au> Sun, 17 June 2007 11:49 UTC
Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HztGG-0003p5-PY; Sun, 17 Jun 2007 07:49:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HztGF-0003p0-Bv for ram@iab.org; Sun, 17 Jun 2007 07:49:39 -0400
Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HztGA-0000Px-1S for ram@iab.org; Sun, 17 Jun 2007 07:49:39 -0400
Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 921BF59E4F; Sun, 17 Jun 2007 21:49:31 +1000 (EST)
Message-ID: <46751FC2.30804@firstpr.com.au>
Date: Sun, 17 Jun 2007 21:49:22 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: ram@iab.org
Subject: Re: [RAM] Ivip (was ViP ...)
References: <4673CF77.5040800@firstpr.com.au> <4673D180.3070903@firstpr.com.au>
In-Reply-To: <4673D180.3070903@firstpr.com.au>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5c4dbf5b8b26864121f8d3a6e6be1ee0
Cc: Christian Vogt <christian.vogt@nomadiclab.com>, Ved Kafle <kafle@nict.go.jp>
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org
I am replying to Ved's and Christian's comments in "Re: ViP: Anycast ITRs in the DFZ & mobile tunnels", with "ViP" changed to "Ivip" (eye-vip). I apologise for the length again. It would probably not be so hard to describe Ivip to one person, face-to-face, with conversation and hand-drawn diagrams. Trying to do it for a bunch of people via email takes more words. VK> To me, the Ivip approach looks similar to the network mobility VK> (nemo) support approach being discussed in the IETF nemo WG. VK> In nemo, the mobile router's home agent advertises the mobile VK> network prefix such that the packets sent by a correspondent node VK> to an address belonging to the nemo prefix go to the home network VK> of the mobile network, where the home agent tunnels them to the VK> current location of the mobile router. The mobile router VK> decapsulates and forwards the packets to the addressed node. I threw this proposal together quickly without checking other protocols - and I don't claim it is highly original. There are two aspects to the proposal at present: "Ivip-basic" and "Ivip-mobile". Ivip-basic ---------- H1---(ITR1)---\ / \ H2-/ \ (ETR1)----RH / H3---(ITR2)----/ (ITR3) (ETR2) Sending hosts H1, H2 and H3 are assumed to have ordinary IP addresses, reachable via BGP. The ITR function is generally performed in border routers or transit routers, but can be performed in interior routers of the edge network. Packets from the Receiving Host RH flow by ordinary BGP routers back to the sending hosts. If a sending host is also using an Ivip-mapped IP address, then the same process occurs in reverse, with the packet sent by RH finding their way to the first ITR, probably at or near the border router of its edge network, and being encapsulated and sent to the ETR for the host on the left side. None of this is shown in the above diagram. ETRs are provided by ISPs, or the AS-end-users who run the edge networks. They only serve receiving hosts in those edge networks. How does the edge network know that the decapsulated packets emerging from the ETR must be sent to a particular host in its network? The ETR and the routers nearby need to be configured to look out for this IP address, or the Ivip-mapped subnet, and route it internally to the receiving host. With Ivip, these packets are addressed to a prefix (a large subnet I call the "master-subnet") which is advertised in BGP. With LISP, they are not. To support either LISP-mapped or Ivip-mapped IP addresses, the edge network needs not only an ETR to decapsulate the packets, but it needs a routing rule specific for that IP address or subnet which directs packets addressed to that address or subnet to wherever the particular host is located. This is probably a non-trivial task for an edge network, but the are being paid by their customer with the host which uses LISP-mapped or Ivip-mapped addresses. Assuming a single global Ivip system, the ITRs may be provided by various operators, but work as a single system, without any constraints on whose packets they will encapsulate. What may be unique about Ivip is that these ITRs are numerous and located (usually) at border or transit routers where any sender's packets will eventually be sent to one. What may also be unique is the idea that all these ITRs advertise the same set of prefixes: whatever "master prefixes" the Ivip system handles. Generally, these "master prefixes" are split into many smaller sections, each with a different mapping to an ETR. This works fine down to individual IP addresses. There needs to be a single central system for controlling the mapping - and every ITR has an up-to-date copy of this database. Ivip-basic is a one-way, public, system. Ideally it would be provided for free, but there probably needs to be some fees for running the ITRs and administering the database. These could be paid for by the Ivip "customers" - those individuals and organisations etc. who pay for one or more IP addresses in the system. As shown above, the ETRs are in the edge network in which RHs are located or connected to. Each RH in this depiction has a single link to its ETR, but an RH could easily have links to two ETRs, especially in two edge networks, to achieve multihoming. Ivip-mobile ----------- Ivip-mobile is an extension of the above, but would probably always be a commercial service. There could be any number of Ivip-mobile operators. Each would have a set of special ETRs called TTRs (Translating Tunnel Routers). These TTRs are in general either at border routers or more likely amongst the transit routers. TTRs could also be in edge networks. H1---(ITR1)---\ / \ H2-/ \ (TTR1)~~~~~~~~MH / / H3---(ITR2)----/ / / (ITR3) (TTR2)~~~~/ The Mobile Host (MH) could be behind NAT and always establishes an encrypted 2-way tunnel to at least one TTR. (I am assuming an encrypted and compressed 2-way VPN-like tunnel, but I guess it could also be done by simple two-way IP-in-IP tunnelling.) The Mobile Host may establish tunnels to multiple TTRs, including using completely different links, such as ADSL and GPRS radio. The Ivip system maps the MH's IP address (or prefix) to one of the TTRs, so all the encapsulated packets from the world's ITRs arrive at that TTR. Some central monitoring system could detect that one TTR is dead, or that its link to the MH is dead, and then the mapping could be changed to the other active TTR. To the Ivip system, which is really the ITRs and their controlling database, there is probably no way of telling whether the currently mapped-to IP address points to an ETR which is for Ivip-basic (meaning the RH is in an edge network and the ETR is a border or internal router of that edge network, with packets flowing back independently of these arrangements) or whether the mapped-to IP address points to a TTR. A TTR is simply an ETR which the MH tunnels to, and which therefore also acts like the MH because this TTR is where the MH's outgoing packets are first let loose on the Net. With mobile-IPv6 (as I understand it), there is exactly one router which the MH tunnels to - it is the router which runs the LAN in which the MH's home address is located. Mobile-IPv6 can also cause corresponding hosts (H1 to H3 etc.) to send packets to and from the MH directly, rather than using the home router. This is more efficient, but requires the corresponding host to have special mobile-IPv6 capabilities. Ivip-mobile is very different from mobile-IPv6 in that the MH can choose one or more TTRs to tunnel to. Ideally it will choose the ones which are closest to its current location. Also, there is no "home IP address" on a LAN, as there must be with mobile-IPv6. As far as I know, mobile-IPv4: http://www.mip4.org relies on a "home-router" and home IP address too. Likewise, as far as I know, NEMO does as well: http://tools.ietf.org/html/rfc3963 http://tools.ietf.org/wg/nemo/ Also, like LISP, Ivip works with single IP addresses or any number of IP addresses. I am not sure whether mobile-IPv6, mobile-IPv4 support subnets, but I guess they could do it as individual arrangements for multiple IP addresses. NEMO supports subnets. The reason a figment of our imagination like Ivip can boldly invoke a worldwide network of ITRs while mobile-IPv6/4 cannot is that now we are desperate. If we don't do something on a grand scale such as this, we will all be doomed to paying for endless upgrades to all the Internet's transit and multihomed border routers as the BGP routing table grows to 500,000, 1,000,000, 2,000,000 etc. LISP boldly invokes at least one ITR in every edge network which has a host which needs to communicate with a host or network whose IP address or subnet is handled by LISP. In practice, for LISP-mapped IP addresses to be attractive to anyone, this means most edge networks must have one or more ITRs. Ivip less boldly invokes ITR functions broadly distributed in the border routers and transit routers. I can get away with this, as can the LISP authors, because we are desperate. Both LISP and Ivip require the relatively modest ETRs to be installed in the edge network of any host which has its address or subnet handled by LISP or Ivip. Ivip could also exist as multiple independent networks of ITRs, each with its own "master-subnets" and its own central database. Since Ivip involves a bunch of souped-up routers at border router and transit router locations, it is not much more of a step to have some of these, or perhaps separate networks of routers, performing TTR functions. Each TTR system could be entirely independent of other TTR systems, and of the one or more ITR systems (provided the TTR did not also implement ITR functions). The multiple TTR systems could compete and provide commercial services to the customers who they provide Ivip-mapped address space for. Please see my previous long message where I write about my conception of Ivip or LISP, which I think is different of Dino's "BYO address space" vision for LISP. If there was a single Ivip system of ITRs, presumably the system would not be allowed to fail, so any address space it hands out via its mapping functions would be essentially "Provider Independent". If there were competing Ivip systems, then all of them, apart from perhaps one "universal public" one, would be dependent on some company, ISP etc. and be for-profit - so the IP address still depends on that company. However, in both cases, where the customer whose address is mapped by these systems chooses to attach to the Net (their choice of ISPs) is completely unrelated to the Ivip system(s). Any TTR systems could be independent of the Ivip systems. A customer could choose to use any number of competing TTR systems. They have nothing to do with IP addresses, since their TTRs are only of value to the customer if the ITRs tunnel packets to the TTRs, and since the customer pays for, or has control of, the mapping of their IP address, the customer only depends on the ITR system for the security of "tenure" of this address - and not at all on any TTR systems it uses. Each TTR could also act as an ITR for that system's "master-subnets". If there was a single, global, system of ITRs, it would be good if the privately run TTRs also acted as ITRs within the global Ivip system. Otherwise, packets would have to first find an ITR and be tunnelled to the TTR when they are going to an Ivip-mobile host. For simplicity, the following assumes there is a single set of "master-subnets" (AKA "master-prefixes") which are handled by a single Ivip system which includes an Ivip-mobile function as well. It is likely that a router which performs TTR functions will also act as an ITR. H1------(TR)------------(ETR1)------RH1 \ MH2~~~~~~(TTR1)~~~~~~~~MH1 / \ H2----(ITR1) \ / (TR) H3----/ \ \ MH3~~~~~~~~~~~(TTR2) H1 and H2 have ordinary BGP routed IP addresses. Packets sent from H1 to MH1 are received by TTR1 which acts like an ITR. Ordinarily, an ITR encapsulates the packet and tunnels it to the ETR to which the destination (MH1) IP address is mapped to. In this case, TTR1 is the destination ETR, so there is no need to encapsulate the packet. It is simply placed on the VPN 2-way tunnel ~~~~~~~~ and sent to MH1. Packets from MH1 to H1 follow the reverse path - they come out of the VPN tunnel at TTR1 and are forwarded via normal BGP routing back to H1. The same would be true between H1 and MH2. Packets from H2 to MH1 (or MH2) would be encapsulated by ITR1 and tunnelled (one way, IP-in-IP) to MH1's ETR, which is TTR1. TTR1 decapsulates them and sends them on the VPN tunnel to MH1. Packets from MH1 to H2 pop out of the VPN tunnel at TTR1 and use ordinary BGP forwarding to get to H2. RH1 has an Ivip-mapped IP address. It is not using Ivip-mobile - just Ivip-basic. In this diagram, the nearest ITR to H1 is TTR1. When H1 sends a packet to RH1, it is forwarded by the TR transit router to TTR1, and encapsulated. TTR1 sends the packet in a 1-way IP-in-IP tunnel to ETR1 (at the border of, or within an edge network), which forwards it within the edge network to RH1. Packets from RH1 must be accepted by the border router of its edge network (which could be ETR1 or some other router not shown) and are sent via ordinary BGP forwarding to H1. A packet from MH3 to MH1 goes via 2-way VPN tunnel to TTR2 where it is encapsulated and sent on a 1-way IP-in-IP tunnel to MH1's ETR, which is TTR1. This decapsulates it and sends the packet along its 2-way VPN tunnel to MH1. Packets going from MH1 to MH2 follow exactly the opposite path, with a 1-way encapsulated IP-in-IP tunnel from TTR1 to TTR2. Mobile-IPv6 doesn't assume anything about routers, except its home router. It doesn't assume anything about corresponding hosts, since ordinary hosts can simply communicate with the mobile host as if it was at its home location, with the home router tunnelling to and from the mobile host, wherever it is. Ivip doesn't assume anything about corresponding hosts, or the host whose IP address or subnet is mapped by Ivip. Ivip does assume there is a system of ITRs - ideally all around the Net at border routers and transit routers. Ivip requires the receiving host have at least one ETR. For Ivip-basic, there will be one ETR in the edge network where the receiving host is currently connected. This mapping can be switched to another ETR, for instance for multihoming. There could also be load balancing between multiple ETRs, as LISP proposes. VK> Analogy: VK> (1) Ivip routers are similar to the mobile network home agents, VK> except that the home agents are confined to home networks VK> where as Ivip routers may be distributed in the Internet. Yes, but the TTRs are similar to the home-agent. With Ivip-mobile the mobile host's IP address doesn't have a home anywhere. Packets from ordinary IP addresses are tunnelled by ITRs to the currently chosen ETR, and that ETR (in the case of a mobile host) is a TTR which the mobile host has a tunnel to. This means that wherever the mobile host is and wherever the corresponding hosts are, assuming there are plenty of ITRs and TTRs, the total path length will be the same as, or not much longer, than without Ivip. VK> If we suppose that home agents can be distributed like Ivip VK> routers, then these two approaches are exactly the same. In my perhaps faulty understanding of mobile-IPv4, mobile-IPv6 and NEMO, this could not occur, because the home-agent router needs to be connected to an edge network whose border router advertises the address range the router handles. It can't be moved somewhere else, assuming that router only handles a part of the subnet its edge network advertises, because to do so would create two or three BGP advertisements instead of one. VK> (2) Ivip's ETRs are similar to nemo mobile routers, which update VK> Ivip routers (home agent) with the tunnel-end addresses. I read the first ten pages of NEMO's RFC3963. NEMO extends mobile-IPv6 with a "mobile router". This is somewhat like a mobile-IPv6 mobile node, except it is a router which has links to the multiple mobile hosts. Also, there is no "route optimization" as in mobile-IPv6 where capable correspondent nodes can send packets directly to and from whatever IP address the mobile host (or NEMO mobile router) is currently located at. So with NEMO, all traffic to the multiple mobile nodes goes through the fixed location (I assume) home agent router, and then via a two-way tunnel to the mobile router - which can flit from one IP address to another, taking its flock of mobile nodes with it. I don't think there is much resemblance between any of these pre-existing mobile systems and either Ivip-basic or its Ivip-mobile extension. Ivip's notion of large numbers of public ITRs and TTRs (by paid-for access I guess) with the mobile host choosing which TTR to use at any time, does not seem to have a parallel in these pre-existing mobile systems, which assume a fixed home-agent router. Ivip-mobile will only be possible because there will be a global system of ITRs which tunnel packets to any BGP-reachable IP address is currently selected to act as the ETR for the mobile-host's Ivip-mapped IP address. Without that global ITR system, steering packets anywhere on the NET, the pre-existing technologies mobile-IPv4/6-NEMO must rely on all packets going to a home-agent router, except for mobile-IPv6 which can use "route-optimization" and set up smart-enough correspondent nodes to send packets directly to and from the mobile node. LISP could just as easily be extended as I suggest with Ivip-mobile. Ivip is similar to or identical to LISP, or at least some type of LISP, except that it should be easy to incrementally deploy and except that it does require all its "master-subnets" (hopefully few and large) to be advertised in BGP. VK> (3) In nemo, a bidirectional tunnel is set up to avoid packet VK> filtering at border routers. Whereas in Ivip, it is assumed VK> that the BRs forward packets with Ivip-mapped addresses. In Ivip-basic, with the receiving host semi-permanently in an edge network, I assume that the edge network's routers are programmed to allow packets from its IP address to be sent to the global BGP system. If not, then the receiving host would need to use Ivip-mobile with a TTR outside this edge network. I tend to think of the TTR function being implemented within routers which are already transit routers, or in routers which are located at peering points and are primarily connected to transit and border routers. However a TTR could be a border router or inside an edge network, as long as that border router or edge network allowed egress of the outgoing packets (which could have almost any source address) to the BGP routing system. VK> There are some well known problems associated with such anchor VK> point-based approaches, such as increased packet delivery VK> delay, non-optimal routing, tunnelling overhead, possibilities VK> of single point of failure, etc. To avoid these problems, VK> route optimization mechanisms are being investigated in the VK> nemo WG. Shouldn't we look for the ID-loc split solutions that VK> avoid such problems as much as possible? Ivip-basic isn't at all like these pre-existing mobile protocols. The Ivip-mobile extension only loosely resembles them, because there is no one fixed home agent. Altogether, Ivip-basic and Ivip-mobile should enable packets to flow without much extra distance or hops. There is still a tunnelling overhead, and perhaps problems with MTU limits. Christian Vogt quoted Ved Kafle and responded: VK> To me, the Ivip approach looks similar to the network mobility VK> (nemo) support approach being discussed in the IETF nemo WG. ... CV> CV> Absolutely. This is what I was saying. I think Ivip is very different from NEMO etc. VK> Analogy: VK> (1) Ivip routers are similar to the mobile network home agents, VK> except that the home agents are confined to home networks VK> where as Ivip routers may be distributed in the Internet. CV> CV> Actually, Ivip routers are confined in the same way as home CV> agents in that both can only support "home" prefixes that CV> correspond to their topological location in the Internet. As I explained above, and in a long message which started this thread, this is not the case. There are lots of TTRs to choose from, so ideally the mobile node will choose one close to it. This is only possible because there is a global network of ITRs, acting like a coordinated bunch of mirrors, tunnelling all the mobile node's traffic to this TTR, another TTR or wherever the mobile node (or some other control system) tells the ITRs to tunnel the packets to. CV> After all, the idea of Ivip routers is to have them advertise CV> sub-prefixes from their ISP's global routing prefix so that CV> the sub-prefixes can be aggregated with the global routing CV> prefix and do not require a separate slot in the DFZ routing CV> table. An Ivip ITR is one of many which advertises one or more "master prefixes". Each ITR attracts packets addressed to these prefixes and tunnels them off to potentially millions of different ETRs. A TTR acts like an ETR as far as the ITR system is concerned. Its just that a TTR is probably not in an edge network - and it connects to the host which has the Ivip-mapped IP address via a two-way tunnel. VK> There are some well known problems associated with such anchor VK> point-based approaches, such as increased packet delivery VK> delay, non-optimal routing, tunnelling overhead, possibilities VK> of single point of failure, etc. ... CV> CV> Right. And things don't get better if we do the indirection CV> for all hosts, not just mobile hosts or hosts moving with CV> mobile networks. Other than the central database, I don't think there is a central point of failure for Ivip-basic or its Ivip-mobile extension. Assuming the mobile host has a BGP reachable IP address, or is behind a NAT firewall which has such an address, it can set up a two-way tunnel to one or more TTRs. If one goes down, it can use another. Ideally it would use nearby ones. Ivip-basic, like LISP, relies on the receiving host having a connection to a particular ETR. LISP, Ivip-basic and Ivip-mobile all enable the receiving host to set up links to multiple ETRs and then (directly, or by some automatic system, since the receiving node could be out of contact after the failure of its active link) the ITRs can all be told to tunnel packets to whichever ETR is currently used. This is genuine multihoming, including for Ivip-mobile - if the two links to the two TTRs are by physically different networks. VK> To avoid these problems, VK> route optimization mechanisms are being investigated in the VK> nemo WG. Shouldn't we look for the ID-loc split solutions that VK> avoid such problems as much as possible? CV> Without an intention to prefer either mechanism, I just want CV> to note that the advantage of Ivip is a better transition path, CV> whereas LISP performs better from the perspective of packet CV> propagation latencies and fault tolerance. Thanks for agreeing with what I think is the most important difference - that Ivip looks like it would be easier to introduce. CV> As a matter of fact, LISP is nothing else but route CV> optimization (in Mobile IPv6 terms) for Ivip. LISP has the ITR function inside or at the border of the edge network. Ivip typically has the ITR function at the border router or amongst the transit routers. With LISP, if the ITR function is at the border router or in an internal router which is on the shortest path between the sending host and the border router, then the total path likely to be the same as for a direct packet (other than a potentially longer path in the destination edge network if the ETR isn't exactly on the shortest path to the receiving host). With Ivip, the same is true if either of the following typical conditions is true: 1 - The ITR function is at the border router of the sending edge network. 2 - The ITR function is in a transit router which is on the shortest path towards the destination edge network's border router. So Ivip's total path length would only be longer than LISP's if the ITR function was not in the sending edge network's border router but in a transit router (or perhaps another border router of another edge network) which is off the shortest path to the destination network's border router. If Ivip or some similar system is adopted, before long, any ISP or AS-end-user network with any substance would want to install the ITR function at its border routers and/or at internal routers - to reduce the processing load on the border routers. They would want to do this so their outgoing Ivip-mapped packets do not depend on anyone else's external ITRs. A fully hardware optimised ITR, with its big database and need for constant updates from the central Ivip database, could be quite expensive. But it has to be provided either by the edge network, or by some ISP or transit provider the edge-network uses for its upstream links. I am not sure how the economics would work best. Maybe for smaller ISPs and AS-end-user edge networks it would be better to pay their upstream provider to handle the ITR function. Over time, as ITR-capable hardware costs reduced, more and more smaller ISPs and AS-end-user networks would probably find it better to run their own ITR rather than pay to use their upstream provider's ITR. I think only those smaller edge-networks would not run ITRs in the long-run. The most important thing is that Ivip could start running with just a handful of ITRs somewhere in the Net. Ideally there would be multiple ITRs for each country. The only significant path-length increases with Ivip would occur when the sending edge network is nowhere near an ITR. This would occur in the early days of introduction. But once Ivip became established and a significant amount of traffic was reliant on ITRs, competition between upstream providers would cause them to ensure there were ITRs in upstream paths, rather than off to one side somewhere. There are two other situations of practical interest, in which Ivip would also produce no increase in total path length. Firstly, it is perfectly possible to install Ivip ITRs inside edge networks. Then, the situation would be identical to LISP: assuming the ITR was on the path from the sending host to the border router, there would be no extra path length. Edge networks could install internal ITRs to take the load off their border routers. However, this would slightly add to the traffic load inside the network, due to the IP-in-IP overhead. The second scenario is most likely to occur when the destination edge networks are very close or their routers are peers. If the sending edge network has no ITR, the packets are forwarded to the closest ITR, which is the border router of the destination edge network. This would work fine. That border router could encapsulate the packet and forward it to the ETR inside the edge network. There are a few variations on this . . . Firstly, maybe the border router is an ITR and the ETR is a separate router inside the network - but the border router has a route for the destination host's IP address already programmed into it, as part of the whole destination edge network being set up to send packets from the ETR to the destination host. Then, there would be no actual involvement of Ivip, other than this border router was advertising the whole "master-subnet" of which this destination IP address was a part. The fact that this border router received the packet means that it forwards it towards the destination host in its network. The ETR wouldn't be involved and there would be no encapsulation. This would be the case if the border router's FIB applied the local routing rules before the ITR function's rules - which it should. Secondly, if the border router's FIB applied the ITR functions first, then it would tunnel the packet to the ETR and all would be well. (Unless the ETR was itself, in which case it should just forward the packet on the internal routing system.) In either case, there would be no increase in path length - above any detour inside the destination network to reach the ETR. If the sending host and receiving host are in the same edge network, and if the whole edge network has its routers programmed to handle the IP address of the receiving host, then Ivip is not involved at all. If the sending host was in some other part of the edge network where the routers didn't know about how to route to the receiving host, then the packet would be forwarded towards the border router. En-route, if it encountered an ITR, all would be well. If the edge network had no ITR, then the packet would be forwarded out the border router and would find its way to the nearest ITR. Then it would be tunnelled back to the same edge network's ETR. This would definitely add to the path length! Here is a potential gotcha. Lets say a host has two links to ETRs in two edge networks A and B, and it is currently using the link to A. This means the global Ivip system's ITRs are tunnelling packets to A's ETR. Both edge networks must have their routing systems set up to forward packets for the recipient host's Ivip-mapped address (or subnet) to the link which leads to the receiving host. (For instance a router or a host computer with two fibre links to two ISPs.) Let's say there is a sending host in edge-network B. That sending host's packets will flow directly along the link from B to the recipient host, even though the recipient host is currently using the link to ISP for its connection to the Net. For absolutely full connectivity, either: 1 - The receiving host needs to accept packets from both links at once. or 2 - The network B needs to not forward the packets to the link to the recipient host until it somehow knows that the recipient host has switched to using network B's ETR. Option 1 sounds best. I apologise for the length of my messages. I hope that if you read them fully, you will understand Ivip and my idea of what LISP can be used for in a way which is independent of NEMO, mobile-IPv4/6 etc. I think the differences are more important than any similarities. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- [RAM] Ivip (was ViP ...) Robin Whittle
- Re: [RAM] Ivip (was ViP ...) Robin Whittle
- Re: [RAM] Ivip (was ViP ...) Robin Whittle
- Re: [RAM] Ivip (was ViP ...) Markus Stenberg
- Re: [RAM] Ivip (was ViP ...) Robin Whittle
- RE: [RAM] Ivip (was ViP ...) Ved Kafle
- Re: [RAM] Ivip (was ViP ...) Robin Whittle
- RE: [RAM] Ivip (was ViP ...) placement Joel M. Halpern
- Re: [RAM] Ivip (was ViP ...) placement Robin Whittle
- Re: [RAM] Ivip (was ViP ...) Robin Whittle
- Re: [RAM] Ivip (was ViP ...) Brian E Carpenter
- Re: [RAM] Ivip (was ViP ...) Noel Chiappa
- Re: [RAM] Ivip (was ViP ...) Robin Whittle
- [RAM] Re: Ivip (was ViP ...) diagram Robin Whittle
- OK, shim6, if we must [Re: [RAM] Ivip (was ViP ..… Brian E Carpenter
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Eliot Lear
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Robin Whittle
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… william(at)elan.net
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Olivier Bonaventure
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Eliot Lear
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… william(at)elan.net
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Jari Arkko
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Olivier Bonaventure
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Christian Vogt
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Christian Vogt
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Brian E Carpenter
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Brian E Carpenter
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Christian Vogt
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Brian E Carpenter
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Robin Whittle
- Re: OK, shim6, if we must [Re: [RAM] Ivip (was Vi… Gert Doering