Re: LIN6 and multihoming (+sec)

["Howard C. Berkowitz" <hcb@clark.net>]

>On Sat, 18 Aug 2001, Howard C. Berkowitz wrote:
>>  >I don't think people generally want to multihome every node, rather
>>  >multihome a router and provide multihomed connection that way.
>>
>>  This is where I partially disagree. Yes, I can understand that it is
>>  generally not required to multihome cellular mobile hosts.  I hope I
>>  may be forgiven for loose terminology if I call them "clients."


And just to disagree with myself, there might be unusual and critical 
applications where a mobile "end user" might need high availability, 
such
as a telepresence application in field emergency medicine.  In such 
cases, the question becomes, is "multihomed routing" enough? 
Certainly multihomed routing protects against certain failures. It 
wouldn't protect against a failure of the base station for a cell, if 
both "homings" are to it.  It wouldn't protect against a hardware or 
system software failure of the host.

I feel it's important that the requirements make very clear that 
multihomed routing only protects against certain failure modes. 
http://www.ietf.org/internet-drafts/draft-berkowitz-multireq-02.txt, 
which I wrote with Dima Krioukov, and hope to merge with current 
multi6 requirements, provides pointers to "multihoming" at other 
layers.

>
>This isn't a point, but there might be some justification for it so...
>
>Multihoming cellular clients might be feasible if the underlaying
>structure is made so that the address would change if they changed their
>radio base station.  Then, when you move to some direction, it might be
>prudent to start to "prepare way for the handoff" by multihoming with
>current and the next cell you're moving towards when you're close enough
>to the edge.

Especially if the client has GPS and knows its direction, it might be 
interesting (although annoying to the cellular protocol folk) to 
introduce a query message that asks "hey, current base station...what 
cell(s) is northwest of you?"

>
>>  "Server" hosts, in contrast, very reasonably will be multihomed to
>>  routers. Indeed, there may be complex relationships of multiple
>>  servers and multiple routers.
>>
>>  The mechanism of server to router multihoming will vary with the
>>  application. When the multiple routers are on the same subnet as the
>>  server, a mechanism as simple as VRRP may suffice, perhaps with
>>  multiple VRRP groups for a degree of load-sharing.  As the servers
>>  and routers become more distributed, some NAT or transport based
>>  mechanism may be needed, or the servers may need some awareness of
>>  routing.
>
>(I'm assuming here that multihoming is done to ensure redundancy.  There
>are other reasons too, of course, but I'll skip them here.)
>
>I agree.  This depends heavily on how important and costly multihoming is
>(ie. do you want to also multihome systems that strictly speaking might
>not need it so much, e.g. workstations vs. critical web-servers).

Depends on the industry and application.  There's no question that a 
CT or MRI scanner workstation is critical, but if the scanner/server 
itself fails, workstation redundancy doesn't help much.  As a matter 
of fact, I was in an MRI scanner at a research hospital last year, 
and the UNIX server kept crashing.  I kept volunteering to help 
debug, but that merely resulted in red faces on the part of the staff.

I think we need to distinguish, in the non-mobile space, between 
workstations and multiple interface workstations.  Someone like a 
money trader has a critical application, and, while they might not 
have a wholly separate workstation, it's quite common for their 
stations to have an active and a backup NIC, connected to separate 
LANs going to high-availability server clusters.

>
>If we can't find a good way to multihome entire sites, it just _might_
>(for an intermediate approach, if not else) be sufficient to be able to
>multihome certain critical systems.
>
>The amount of critical systems and how they're located in the site's
>network topology defines whether "server-based" or "network-based"
>multihoming is a better alternative (if you actually could do it either
>way).
>
>--
>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