Subject: Multihoming draft available

From: Ramakrishna Gummadi <[email-masked]>
Date: Fri, 31 Aug 2001 08:34:46 -0700 (PDT)

Hi all,
I finished a draft that describes one way of doing scalable multihoming.

http://www.cs.berkeley.edu/~ramki/draft-ramki-multi6-nlmp-00.txt

Comments are highly appreciated. I plan to submit this as an internet
draft soon. The abstract is below:

This document proposes two extensions to BGP4+ to provide scalable
multihoming in IPv6.
The first is a new well-known and mandatory "TunneL (TL)" BGP path
attribute that
allows a multihomed enterprise to maintain global connectivity in the
presence of
network outages within a direct provider Autonomous System (AS) without
adding any
global forwarding overhead. The second is a new well-known and mandatory
"Selective
Announcement (SA)" BGP community attribute that allows the multihomed
enterprise to
recover from failures in distant AS's by explicitly specifying the list of
AS's to
which the site's reachability must be advertised. These two extensions
form the core
of the "Network Layer Multihoming Protocol (NLMP)" described in this
draft. NLMP is
designed to be used by both multihomed providers and multihomed
enterprises.

thanks,
ramki

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Aug 2001 22:46:16 +0300 (EEST)

> draft soon. The abstract is below:

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.

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)

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.

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.

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

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

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Fri, 31 Aug 2001 13:02:39 -0700 (PDT)

Thanks, Pekka, for your prompt comments.

> be easily duplicated and routes exchanged with e.g. route reflectors to

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

>                    draft-ietf-ipngwg-ipv6-2260-02.txt

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.

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

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

> (naturally, this wouldn't be a big worry with very aggregated DFZ such as

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

-ramki