Re: [RAM] Tunnelling Route Reduction Protocol
Robin Whittle <rw@firstpr.com.au> Tue, 21 August 2007 02:42 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 1INJhF-0005Ga-MX; Mon, 20 Aug 2007 22:42:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INJhF-0005Fu-9P for ram@iab.org; Mon, 20 Aug 2007 22:42:21 -0400
Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INJhA-0001c6-Vg for ram@iab.org; Mon, 20 Aug 2007 22:42:21 -0400
Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 485D859DA1; Tue, 21 Aug 2007 12:42:14 +1000 (EST)
Message-ID: <46CA50F0.2040001@firstpr.com.au>
Date: Tue, 21 Aug 2007 12:41:52 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: ram@iab.org
Subject: Re: [RAM] Tunnelling Route Reduction Protocol
References: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com>
In-Reply-To: <3c3e3fca0708200646j391fd621n568f2b791c93a36f@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc:
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
Hi Bill, Here are some thoughts after I had a quick read of: http://bill.herrin.us/network/trrp.html http://bill.herrin.us/network/trrp-implementation.html Very roughly, I think TRRP is like LISP 2, with a transitional arrangement for continued reachability during introduction, with longer-term administrative arrangements for removing prefixes of mapped addresses from the global BGP routing table. I think the biggest problem TRRP faces is that when a packet arrives at an ITR which has no mapping information, that the ITR must hold the packet until it gets that information. Via DNS, I guess that could take a second or two or more. Generally, I think this is an unacceptable delay, since the application which sent the packet will assume the packet or its response is lost, and will send another one. I think this is one major reason why no-one is seriously proposing LISP 2 as a solution to the routing and addressing problems. Another concern might be about overloading the DNS system with more tasks. Your multihoming service restoration system seems to rely on the ITR getting a "destination unreachable" response when it sends a data packet. Without this, the ITR assumes that the packet is received by the ETR and that the ETR can send the packet to the final destination. I think this would be a poor way of ensuring that the packets really do reach their destination. "Destination unreachable" packets could get dropped, and you would need to ensure there was no filtering of such packets between all ITRs and ETRs. Yet some networks like to drop "destination unreachable" packets to reduce the ability of an attacker to probe the existence of hosts in their network. This might limit how deep the ETRs are located. Yet having a deeper placement of ETRs helps with scaling - spreading the load among more of them. Deeper, closer, ETRs also reduces the path length to the destination host. So like LISP and eFIT-APT, TRRP's multihoming service restoration functions are hard-coded into the protocol and are implemented independently by each ITR. In contrast, Ivip has no built-in multihoming service restoration functions. It is up to the end user to choose and supply their own monitoring system, which can be arbitrarily flexible, complex and costly as they choose. This system is then given the power to control the mapping of their addresses. The Ivip system simply follows these instructions. The ITRs do not attempt to determine reachability or decide on alternative ETRs to tunnel packets to. This makes the Ivip system a relatively simple component, to be used with other user-supplied components, to achieve a variety of benefits - multihoming, TE, portability and mobility with generally highly optimal path length. You don't explain how an ETR can get packets to the intended destination. Presumably they could do so via a tunnel, in which case each host requires special software to decapsulate the packet. Otherwise, the ETR needs a direct link to each destination host, or the local routing system needs to be able to route the packets with their raw addresses (the IP address of the destination host). You would need to ensure that all packets addressed to the hosts with TRRP mapped addresses were sent via an ITR (apart from those emanating from an ETR). This is because only the ITR can have the latest information on where the packets should be sent to. The local routing system can't be expected to change so rapidly, or to make multihoming service restoration decisions. I think this is a common problem for LISP and Ivip (eFIT-APT too?). Also, I understand the outer packet source address of TRRP's tunneled packets is that of the ITR. This makes it very difficult for ETRs to protect against spoofed local source addresses when they decapsulate packets. Ivip uses the source address of the sending host as the source address of the outer IP header of the encapsulated packet. This enables the ETR to perform some simple tests when decapsulating the packet, which extends the reach of the network's border router's filtering of source address of incoming packets, to solve this problem: http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-arch-00.html#anchor67 - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- Re: [RAM] Tunnelling Route Reduction Protocol Noel Chiappa
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol Robin Whittle
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol Robin Whittle
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol Brian E Carpenter
- Re: [RAM] Tunnelling Route Reduction Protocol Noel Chiappa
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin
- Re: [RAM] Tunnelling Route Reduction Protocol William Herrin