Re: [RAM] Tunnelling Route Reduction Protocol

["William Herrin" <[e-mail]>]

On 8/20/07, Robin Whittle <[e-mail]> wrote:
> 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

Hi Robin,

Thanks for your response.

> 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.

This is true for packets which will leave the local AS and cross the
Internet. This brings up three points:

1. 99.9% of the time, the originator of the packet has already had to
do a DNS lookup or some other lookup to map a name to an IP address.
Doing another lookup for that first connection attempt leaves us in
the same ballpark speed-wise.

2. This delay only occurs the -first- time the ITR sees a packet for a
particular destination. After that, it has a destination cached. Even
re-lookups are background tasks. The ITR is permitted to keep the
destination cached long after the TTL expires. The only requirement is
that it initiate a background relookup the first time it sees another
packet for the destination.

3. Traffic within the AS (or the local portion of the AS for
particularly large AS's) need not enter TRRP at all. Barring a
passthrough-mode ITR close to the source, It moves normally as
dictated by an interior routing protocol.

>  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.

As always, the key portions of the root of the DNS tree get
immediately cached by the resolver. TRRP has its own branch in the
system, so as you get down to the components that are heavily used
with a short timeout, the servers can be scaled to match. One of the
benefits of using DNS for this is that we already have software which
scales up to a massive level with little pain.


> 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.

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. Ideally this can be handled by allowing
the packet to drop into another ITR instead and be rerouted to an ETR
which does have a route to the destination.

Discovering the failure can be slow, taking up to the DNS TTL. The
destination unreachable stuff is intended to provide the ITR with a
shortcut to detect the failure sooner. The optional preemptive change
notification also helps speed the process up. When not available, the
regular timeout and relookup mechanism applies.

Also, where the ITR is operating in passthrough mode on an originating
host, TCP retransmits can be used to key a retry with an alternate
ETR. That's the primary point of having a passthrough mode. Doesn't
work through NAT though. That's unfortunate for IPv4. Should be a
non-issue for IPv6.


> 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.

ETRs can be as deep or shallow as the destination network operator
desires. They can sit just inside the AS if desired. Alternately, the
service provider could assign 2 addresses from globally routable space
to each customer and let the customer implement both the DNS server
and the ETR on customer's own network.



> You don't explain how an ETR can get packets to the intended
> destination.
>  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).

Correct, that's how it works during normal operations. Any place I
didn't specify otherwise, packets are intended to move via plain old
raw IP routing.

In the case where the ETR's link to the customer network has been
severed, the packet will ideally fall into another ITR and be rerouted
to an alternate ETR. This is not a protocol requirement but it would
shorten the recovery time after the loss of the link and before the
propagation of the new ETR information via DNS.


> Also, I understand the outer packet source address of TRRP's
> tunneled packets is that of the ITR.

Correct.

> 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:

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?

Thanks again,
Bill Herrin


-- 
William D. Herrin                  [e-mail]  [e-mail]
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

_______________________________________________
RAM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram