Re: A tunneling proposal

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

Thanks, Itojun. I think the difference between the proposals described in
these rfc/drafts and my outline is that the tunnel is created
(statically or dynamically) directly between the ISPs, without requiring
multiple physical links from each of the site's border routers
to each of the ISPs.
That is, upon receiving a request from the site's border router peering
with ISPA, ISPA sets up a traffic tunnel from itself to ISPB for carrying
ISPB's traffic at an appropriate peering point.

 Apart from saving on the extra physical links, this can
potentially
provide more robustness because one can overcome more failure modes: for
example, what happens when the (single, say) ISPB's border router peering
with each of the site's border routers (albeit across multiple
physical links) goes down? In my outline, because
ISPA and ISPB potentially peer at multiple points, these kind of failures
can be tolerated. Also, there is a possibility of performance optimization
for ISPA (after all, he is carrying extra traffic) because ISPA can choose
the optimal exit point (from its perspective) into ISPB.

This may complicate things, but I guess there is a possibility that the
benefits may well make the complexity worthwhile.

thanks,
ramki

On Mon, 16 Jul 2001 itojun@iijlab.net wrote:

>
> >Hi all,
> >I have been thinking about the following approach that might be useful
> >towards solving the multihoming problem. It does not require changes
> >to end hosts, and can be used together with provider independent
> >addressing.
>
> 	I guess your idea is very similar to RFC2260 as well as
> 	draft-ietf-ipngwg-ipv6-2260-02.txt.  these RFC/draft do not have
> 	any "dynamic" tunnel establishment, but the end goal is very similar.
>
> itojun
>
>