|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: multi-homing fixes
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
|