[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Re: TRRP Waypoint Routers



On Fri, Feb 22, 2008 at 9:58 AM, Robin Whittle <rw@firstpr.com.au> wrote:
>   http://bill.herrin.us/network/trrp-aapip.html
>
>  In both your system and this use of ALT, ITRs are not involved and
>  no mapping information is required.

Hi Robin,

Actually ITRs are involved for TRRP. The idea is that if an ETR for a
packet isn't yet known but a highly aggregated waypoint for that block
of address space (perhaps a /8) is already known then you can move the
packet closer to its destination immediately.

A waypoint is a combination ETR/ITR. It can accept packets with any
encapsulation that it advertises and will if necessary re-encapsulate
them in a manner that the next waypoint or final destination accepts.
Because there are perhaps a couple hundred top-level waypoints
(compared to millions of final destination ETRs) and because waypoint
maps have a long timeout it's highly probable that the ITR has already
cached a valid waypoint. If it hasn't, the ITR has a search algorithm
that guarantees it quickly will.


>  Can you give a more concrete example of how these Waypoint Routers
>  would be structured?

Sure. Lets say we have a source IP at 126.0.0.1 and he want's to talk
to me in the swamp at 199.33.224.1. So, he sends the packet out. Call
it packet A. There is no BGP route that covers 199.33.224.1, so packet
A follows 0.0.0.0/0 to the nearest TRRP ITR.

The ITR doesn't yet have a map for 199.33.224.1. However, he does have
a waypoint map for 199.0.0.0/8: apparently the US Government has
decided to be nice and offer an "initial" mode GRE waypoint as a
public service at 148.129.75.8, which is within globally routable (BGP
routed) space.

So, the ITR immediately encapsulates packet A in GRE and sends it to
148.129.75.8. Then it initiates a lookup for 1.224.33.199.v4.trrp.arpa
so that it'll be able to send subsequent packets directly.

148.129.75.8 doesn't have a MAP for 199.33.224.1 either. However, I
have a private waypoint set up for all of 199.33.224.0/23 in
"generous" mode at 71.246.241.146 (which is also within globally
routeable space). It accepts GRE as one if its formats. I have made
arrangements with 148.129.75.8 to keep this knowledge in his cache.
Essentially, I push this knowledge to him.

So, 148.129.75.8 keeps packet A in GRE and sends it on to my waypoint
at 71.246.241.146. He doesn't bother trying to look up
1.224.33.199.v4.trrp.arpa because I've told him that my waypoint
operates in "generous" mode.

My waypoint at 71.246.241.146 receives packet A. He's directly
attached to an authoritative DNS server that knows the current TRRP
map for 1.224.33.199.v4.trrp.arpa and probably already has it in his
cache. In this case, it happens to be directly available (the waypoint
was also a final ETR) so 71.246.241.146 decapsulates packet A and
delivers it to 199.33.224.1.

Around the same time, the DNS request for 1.224.33.199.v4.trrp.arpa
from the original ITR reaches the authoritative DNS server and the
reply starts making its way back.



Note that US Government could have been replaced with Money Grubbing
Company and "initial" mode could have been replaced with "limited"
mode. The differences would have been:

1. The first ITR would have held a copy of packet A and would have
sent a second copy once the map lookup for 1.224.33.199.v4.trrp.arpa
succeeded.

2. If I didn't pay MGC to pass my packets to me, he would have dropped
packet A instead of sending it on to my waypoint. I'd have had to wait
for the ITR's second copy.


Note also that 148.129.75.8 would likely announce 199.0.0.0/8 into the
BGP table so that networks without TRRP ITRs could find their way to
my TRRP ETR. How exactly we do this is an open issue, one of the
unfinished things about the document... Any network which -does- have
a TRRP ITR shouldn't insert that route into its FIB, or should locally
override it from the ITR. How does it know to do so? It's my "holey
routes" problem wrought large.


>  To what extent does your system resemble ALT, and to what extent
>  does my critique of ALT apply to your system?

Without having reviewed ALT in any detail, my best guess is that it
doesn't share much besides the notion of a highly aggregated alternate
path.

ALT sounds like it might work with static tunnels or private lines
using something close to standard BGP. On the down side, it would
require a complex dance between thousands of operators to get it
going. With Waypoints, the complex dance is at the RIR public policy
level getting authorization to announce for that supernet. Once
authority is obtained, they hook up at any old place and announce the
prefix.



>  By your own description, the Waypoint Router path is "long" -
>  compared to going direct in a tunnel to the ETR (the address of
>  which is not known at this time).  Presumably this "long" path will
>  be faster than waiting for the mapping information to arrive.
>
>  Do you have estimates for the delay times?

My SWAG is that the initial round trip will be 1.5 to 2 times the
normal round trip with some single-digit percentage taking long enough
to recognize no gain versus bare TRRP.

Regards,
Bill Herrin




-- 
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg