Re: Multihoming draft available

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

Thanks, Pekka, for your prompt comments.

> The draft implies only one EBR.  More often than not, it's customer's box
> that breaks, and at least some folks require enterprise to have two exit
> routers in order to get real high availibility.  Well, I guess EBR's could
> be easily duplicated and routes exchanged with e.g. route reflectors to
> keep databases in sync.

That  is correct; I did not explicitly describe how to make EBR highly
available, but this is one possible approach.

> Tunneling mechanism seems to be aiming to automate:
>
>              IPv6 multihoming support at site exit routers
>                    draft-ietf-ipngwg-ipv6-2260-02.txt
>
> (at pseudo wg last call)

Both automate and expand the set of failures that can be tolerated, in my
opinion. The main drawback of RFC2260 is that it only provides limited
redundancy. However, the goal is to show that tunneling, as a primitive,
is sufficiently powerful to provide resiliency even against provider-wide
failures.


> I have some doubts about Selective Announcements.  Has there been any
> research on how big 'set difference between the prefixes heard from the
> two providers' might be?  Somehow I have a gut feeling, this could vary a
> lot even though there is nothing special going on.

Unfortunately, I don't have any first-hand data. However, I have heard at
SIGCOMM two days ago that there have been a couple of internet drafts that
describe selective announcements, possibly in a different context. I am
trying to get the exact pointers to these drafts.

>
> Nonetheless, there's also a worry about the scalability of this -- if this
> was ever applied to IPv4, or a lot of prefixes.  That is, if a prominent
> transit breaks, it could be that 1,000 or 5,000 or even 10,000 prefixes
> would have to be readvertised _in a very fine-grained fashion to specific
> neighbours_ using this mechanism?  That is, a big load of advertisements
> would have to go "upstream" hop-by-hop checking AS-PATH list, modifying it
> and selectively advertising prefixes.  To me this at least _sounds_ like
> an awfully heavy task; current global advertisements are plain and simple.

Correct; under worst-case scenario (many backbone providers
simultaneously break), selective advertisement can be as bad
as polluting the DFZ with every multihomed prefix as today. However, the
average case is hopefully much better, both because of space-time scoping
of announcements, and because tunneling can always be used as the first
line of defense.

> If this method _could_ be heavy, it would also reflect on the convergence
> times, and if it takes too long, the whole might become moot if
> connections might practically break anyway.
>
> (naturally, this wouldn't be a big worry with very aggregated DFZ such as
> IPv6 currently is).

With IPv6, this should not be much of a problem, like you say.

-ramki

> --
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
>
>