Re: [RAM] Tunnelling Route Reduction Protocol

Robin Whittle <rw@firstpr.com.au> Tue, 21 August 2007 14:43 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 1INUwx-0002ld-Sd; Tue, 21 Aug 2007 10:43:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INUww-0002lY-Rx for ram@iab.org; Tue, 21 Aug 2007 10:43:18 -0400
Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INUwu-00048O-Hn for ram@iab.org; Tue, 21 Aug 2007 10:43:18 -0400
Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id F1EFE5A674; Wed, 22 Aug 2007 00:43:12 +1000 (EST)
Message-ID: <46CAF9EB.1010406@firstpr.com.au>
Date: Wed, 22 Aug 2007 00:42:51 +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> <46CA50F0.2040001@firstpr.com.au> <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@mail.gmail.com>
In-Reply-To: <3c3e3fca0708210630r7d559c6fk94bc38c1aaa68df7@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,

Thanks for clarifying some things.

I understand - as I should have earlier - that your proposal
involves a separate set of nameservers, which can be scaled to deal
with the load of queries, including I guess by using anycast servers
in multiple locations, as with the root nameservers.

>> Your multihoming service restoration system seems to rely on the ITR
>> getting a "destination unreachable" response when it sends a data
>> packet.
>> 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.
> 
> Actually, no. TRRP relies on the operator of the authoritative DNS
> server performing some sort of monitoring to determine when a
> particular ETR is no longer a reasonable target and then updating the
> DNS records. When the records expire at the ITR (which is intended to
> happen quickly) the relookup reveals a new destination.
> 
> This monitoring is not defined by the protocol. It can be as simple
> (and slow) as "change by hand when there is a problem" or arbitrarily
> complex.

OK - I understand from this that TRRP and Ivip are both relatively
simple "components" of the complete multihoming solution, with the
end-user supplying their own monitoring system to update the mapping
database.  That is my view of how your system would work, since
although you wrote:

> TRRP relies on the operator of the authoritative DNS
> server performing some sort of monitoring to determine when a
> particular ETR is no longer a reasonable target and then updating
> the DNS records.

I figure that either the operator of the DNS server covers address
space for many end-user networks, and that each end-user might want
to choose some monitoring system which is different from whatever
the DNS operator has available - and so would pay someone else to
run that monitoring service and tell the DNS operator what changes
to make to the mapping of their address space . . .  Or that the
authoritative controller of the DNS information (a subset of what a
whole server controls) is the end-user organisation themselves.

With Ivip, I aim to get those changes to ITRs within a few seconds.
 Your TRRP arrangement relies on cache time expiration, so the
response speed for multihoming service restoration needs to be
traded off against the amount of query traffic to the nameservers.

Ivip is pretty ambitious in this attempt to transmit mapping changes
to all the ITRs which need it so quickly.  If this can be done, then
it would support a mobility arrangement which I think can't be done
by any of the other proposals including with the slower arrangements
which I think your reliance on cache expiration require.


> Note that that the ITR has no other mechanism for detecting a failure
> downstream from the ETR. If the ETR is reachable but it can't reach
> the end-user network, the destination unreachable goes back to the
> sender, not the ITR itself. 

OK - so the ITR is not involved in this.  Some separate monitoring
system is required to find out which is the best ETR to use,
irrespective of whether traffic packets are being sent to the
destination host or not.


I don't clearly understand quite a few of the next paragraphs - but
it is late in the evening ....  I will read them again in the next
day or two.


> Hmm. Would you jimmie up an example of aberrant behavior you feel
> couldn't be adequately addressed within the ETR or ITR, or via
> existing mechanisms for protecting against spoofed addresses?

Sections 14.1 to 14.1.2.5 cover this:

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