multi-homing fixes
Howard C. Berkowitz
hcb at clark.net
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
More information about the NANOG
mailing list