multi-homing fixes

Fri Aug 24 23:28:44 UTC 2001

Been following this discussion closely, as multihoming has always 
been an interest of mine, going back to my first NANOG presentation 
in San Francisco.  I am working on a couple of things in this area, 
which were presented at the last IETF: 
http://www.ietf.org/internet-drafts/draft-berkowitz-multireq-02.txt 
and 
http://www.ietf.org/internet-drafts/draft-berkowitz-tblgrow-00.txt 
The first deals with a broad framework for multihoming and related 
topics, but from the user requirements standpoint.  The second 
proposes heuristics for trying to get a better understanding why the 
table is growing -- multihoming, lack of clue, traffic engineering, 
etc.

Part of the problem is that user perceptions and desires may or may 
not result in picking the right tool to get what they really want, 
which typically is high availability and load distribution. Honest, I 
had a customer that insisted their Internet connection never go down. 
I arranged BGP multihoming to two ISPs, and had one of the 
connections engineered so that it came directly off a major 
provider's dual SONET that entered their office park.

Some time later, I was in their computer room, and found -- count 'em 
-- ONE application server.  I inquired what they planned to do if it 
went down, and they assured me that they were OK because they backed 
up on tape.  Horrible shocked expressions when I inquired to what 
they expected to restore the tape.

I started the multihoming framework paper when I was consulting on 
pre-sales design to a major carrier, that would get weird customer 
perceptions but have no independent references to educate them. I've 
also written books in this area -- not intended as a plug, but 
another resource.

What I sense that we, as operators, vendors to operators, etc., need 
is some common vocabulary and methodology to understand what the 
customer is trying to do, and help them see the correct picture and 
the correct tools.  The tools might be server clustering, redundant 
and diverse local loops to the same provider, contractual 
requirements for upstream route diversity, DNS redirection, etc.

My increasing feeling is that we lack a focal point for such 
information. I've variously presented drafts to IDR, MULTI6, and 
PTOMAINE, but the fit is never quite right.  My inclination is to 
suggest BOF-level activities both at the operational forums and IETF, 
and try to replicate some of what we did in the PIER working group on 
renumbering -- not invent tools, but provide operational guidance.

I'm thinking of requesting a BOF on this both at NANOG in Oakland, 
and then the IETF in Salt Lake City. Tentative name: "Multihoming 
User Requirements at All Layers (MURAL)".

Might this help the situation?

Howard Berkowitz
Nortel Networks